Adoption Playbook — Deploying GA Agents
A repeatable path from "agent is available in the tenant" to "agent is delivering value in the business."
Welcome
Turning an agent on is the easy bit. Getting people to use it, trust it, and let it change how the work gets done — that's the job this module is about.
This is the Kainos deployment playbook for GA Workday agents. It assumes the agent exists, the licence is in place, and the customer has said yes. From there, you need a repeatable motion: de-risk the launch, prove value on a small population, then scale with confidence. Treat every agent deployment as a mini product launch, not an integration cutover.
If you take one idea away: adoption is the deliverable, not activation. An agent that's switched on but unused is a line item on an invoice, not a result.
Learning objectives
Pre-requisites checklist
Do not start deploying an agent until all four of these are green. Every failed deployment we have seen skipped at least one.
1 · Data readiness
The Workday objects the agent reads are clean, current, and populated at the volume the agent needs. Garbage-in still applies — an agent recommending candidates on a half-maintained job architecture will fail in public.
2 · Security posture
Tenant security groups are correct, and the customer has confirmed who the agent may run on behalf of. Agents inherit security; they do not fix it.
3 · Stakeholder alignment
A named business sponsor, a named Workday owner, and a named change lead. If any one of those is vacant, pause — go-live without a sponsor is a known failure mode.
4 · Success criteria agreed
Written down, signed off, and measurable inside 90 days. "Adoption" is not a success criterion. "70% of recruiters use the agent at least weekly by day 60" is.
If the customer cannot tell you how they'll know it worked, they are not ready to deploy. Go back to scoping. This is the single highest-leverage conversation in the deployment.
Pilot → scale pattern
Start small. Prove it. Then scale. This isn't caution — it's the fastest way to a tenant-wide rollout that sticks.
Start small
One population, one process, one sponsor. Small enough to fix in a week if something breaks.
Measurable population
Pick a group you can actually measure — usage, time saved, quality — against a clear baseline captured before switch-on.
Explicit exit criteria
Write down what the pilot must prove before you scale. If it doesn't hit the bar, don't scale — adapt or stop.
Anatomy of a good pilot
- Population: 30–150 users, one function, one region where possible.
- Duration: 4–8 weeks. Long enough to get past the novelty curve, short enough to decide.
- Baseline: captured in the two weeks before the agent is live. No baseline, no story.
- Exit criteria: adoption rate, quality signal, and sponsor sign-off — all three, not any one.
A pilot without exit criteria is just an extended trial. Customers will drift for quarters. Agree the scale/stop decision date up front and put it in the statement of work.
Configuration decisions
Three decisions, taken early, shape everything else. Take them with the customer — don't decide for them, and don't let them decide without you.
Defaults vs custom
Start with Workday defaults unless there is a hard reason to deviate. Every custom configuration is a future upgrade cost. Use the defaults, then adapt only where value justifies the lifecycle.
Who can invoke the agent?
A subset of users, not "everyone, day one". Map the invoke permission to the pilot population first. Widen it as you scale — not before.
Human-in-the-loop thresholds
For anything the agent drafts, recommends, or actions — agree where a human must approve and where the agent may proceed. Biased toward human-in-the-loop on day one; relax thresholds as confidence grows.
Logging & feedback loop
Decide up front how the customer will see what the agent did, and how users flag when it got something wrong. No feedback loop means no improvement.
"Use, Adapt, or Build" applied to configuration
Use: take the GA agent with default configuration. This should be the starting position in 80% of cases.
Adapt: tune thresholds, prompts, scope, or who can invoke it. Adapt when a specific customer context warrants it — and document why.
Build: only if a genuine gap exists that a GA agent cannot cover. Build is covered in Module 11, not here.
Training approach
One training deck does not work. Different audiences need different content at different cadences. Build three tracks, not one.
End users
Short, task-based, in-the-flow-of-work. "Here's the one thing you do differently." 10 minutes, not 60. Repeat at 30 and 60 days.
Managers
Focus on how the agent changes what their team does and what they now see. Include the "so what" for performance conversations. Bias toward confidence, not click-paths.
Power users
Deeper mechanics, edge cases, escalation paths. These people will answer colleagues' questions — invest in them and they multiply adoption for free.
Cadence
- Pre-launch: power users first, managers second, end users last — in that order.
- Launch week: end-user micro-training, delivered in context, not classroom-style.
- Day 30 & Day 60: re-engagement content for end users, plus a refresher for managers on what the usage data is telling them.
Training is the visible edge of change management. The behavioural change — trusting the agent, changing the team's operating rhythm — is the bigger job. Module 9 · Change management for AI picks up where this section ends.
Go-live & hypercare
The first 30 days decide whether the agent lands or stalls. Treat hypercare as a product discipline, not a support rota.
What to watch
Usage, not activation
Daily active users, weekly active users, invocations per user. "Logged in once" is not adoption.
Quality signal
Thumbs up/down where available, sampled manual review where not. Aim for a representative sample, not a cherry-picked one.
Escalations
Every "the agent got it wrong" ticket is data. Track the category, not just the count.
Flex credit burn
Actual usage against the forecast from Module 7. Variance > 25% means the forecast needs reworking, not the agent switching off.
What to tune
- Human-in-the-loop thresholds — tighten if quality dips, loosen once confidence is earned.
- Invocation scope — widen or narrow based on where the agent performs well.
- Training gaps — if 30% of escalations are "I didn't know it could do that", that's a training fix, not an agent fix.
Who's on call
Hypercare is a standing rota, not ad-hoc. Kainos provides a named deployment lead, a Workday SME, and escalation into the CoE AI. Customer provides the business sponsor and a power user per function. Daily stand-up for week one, twice-weekly for weeks two to four.
Handover to Customer Success
Day 30 is not the end. It's the transition from "project" to "service". Be explicit about what hands over and what stays with Kainos as an ongoing capability.
What hands over to the customer
Day-to-day usage, line-manager reinforcement, first-line user questions, and ownership of the success metrics. The customer owns the business outcome.
What sticks as Kainos ongoing service
Tenant-wide agent strategy, configuration changes, release impact assessments, flex credit forecasting, and the sequencing plan across the agent portfolio. The CoE AI is the long-term partner, not a project team that disbands.
The 90-day review
Scheduled at go-live, not after. Kainos-led, sponsor-attended, outcomes-against-criteria. This is the conversation that unlocks the next agent.
The ongoing scorecard
Adoption, quality, and value — tracked monthly, reported quarterly. Handover without a scorecard is abandonment.
A clean handover is also the highest-signal moment to position the next agent. A customer who has just watched one agent deliver is ten times more receptive than one who has just been pitched the portfolio.
Common deployment anti-patterns
If you catch yourself in any of these, stop and re-plan. Every one of them has cost a customer outcome somewhere.
Turning everything on at once
Full population, all regions, no pilot. Feels decisive; is actually the slowest way to value because there is nowhere to learn. You cannot tune what you cannot isolate.
No success metric
The project lives or dies on vibes. Six months in, nobody can prove it's working, so the next agent can't be funded. The absence of a metric is the metric.
Treating it like an integration project
Requirements, build, test, cutover, done. Agents are behavioural, not transactional. There is no "go-live and walk away" — the work after cutover is where the value is.
Training as a one-off event
One webinar, one deck, one attempt. Adoption curves are measured in months, not days. Plan cadence in from the start.
Configuration sprawl in week one
Every stakeholder's preference gets built in before the defaults have been tested. You now own a bespoke configuration you cannot cleanly upgrade. Use the defaults first; adapt only once data justifies it.
Check your understanding
Three questions. Each explains why every answer is right or wrong — the reasoning matters more than the score.
Next steps
- Module 9 · Change management for AI — the behavioural side of what this module starts. Training lands; behaviour change is harder.
- Module 10 · Adoption, not activation — the metrics layer. How the CoE AI tracks adoption across the customer base and what "good" looks like at portfolio scale.
- Module 7 · Flex credits & credit forecasting — revisit if the hypercare credit-burn signal surprised you. Forecast accuracy improves with deployment reps.