The biggest mistake we see in agent strategy work is starting with the platform. "Which builder should we use? Flowise or Microsoft Copilot Studio or Workday's tooling?" Teams that lead with the tool question end up with a tool decision and no strategy. The platform is the last question, not the first. The five conversations in order, with the questions we ask under each, and the failure mode for each one.
First — Ambitions and outcomes
Start with one sentence on why you are doing this. "We want to leverage AI" means nothing. "We want agents to remove the manual admin from our top three HR processes so our HRBPs can focus on advice instead of transactions" is specific, anchored to a change you want to see, and short enough to remember.
Then the personas who interact with the agents. Employees. Managers. HRBPs. Recruiters. Three is usually enough. Each one has a different relationship with agents and a different bar for trust.
Then the problems the strategy is meant to solve, written as actual pains rather than themes. "Recruiters spend six hours a week screening resumes that do not match the role." "Managers cannot get a clean answer on which of their direct reports is owed a promotion review." "HRBPs are still cutting and pasting policy text into emails." If you cannot name three problems at this level of detail, you do not need an agent strategy yet. You need a process review.
Close with three to five KPIs. Cycle time. Hours saved. Error rate. Adoption. The ones a CFO would believe. Avoid composite scores, and avoid ambitions written in marketing language. If the sentence ("transform HR", "empower employees") could appear in a vendor pitch deck without changes, it is not yours.
Second — Governance and guardrails
Most strategies skim this. Your legal team, works council, and AI governance board will read it first. Get it wrong and the rest stalls.
What is your risk appetite? "Balanced overall, conservative for HR core data" is a sentence that works in most steering committees. Where are your data boundaries, specifically: what cannot leave Workday under any circumstances? Which use cases need a human in the loop, and at which step? Performance review writing usually needs review before the draft reaches the employee. Pay decisions need it before any action. Hire and no-hire calls almost always need it. Who approves new agent use cases? Mature setups have a small board with HRIS, IT, Legal, and a works council representative.
If you operate in the EU, several common HR agent categories sit in the high-risk classification under the AI Act. Recruitment screening. Performance evaluation. Termination-related decisions. All need documented assessments, human oversight, and transparency to employees. Build this in from the start, not at go-live.
Governance bolted on after the first pilot lands is the most expensive thing on this list. Two months in, Legal sees the agent's draft of a termination letter and the rollout pauses. The retrofit costs more than starting clean, every time.
Third — Build versus buy, per use case
Workday ships its own agents now. Partners ship more through the marketplace. You can build on top of Workday's platform. The strategy needs a stance on which path is the default.
The pattern that holds up across most clients: native first, partner where it fills a clear gap that native does not, custom only where the use case is specific to your operating model or runs across systems no packaged agent covers. Native first means that whenever Workday or a partner ships a serviceable agent for the use case, you use it and accept the limitations rather than rebuilding. The cost of building and maintaining a custom agent for a problem someone else has already solved is rarely worth the marginal feature gain.
Custom belongs in a smaller set of cases. When the workflow cuts across Workday and other systems in ways a packaged agent cannot. When the user experience needs to feel specific to your operating model. When the data the agent needs is your own and not in any vendor's training set. Or when the use case is genuinely your competitive edge.
Write the criteria down. The default. The conditions under which you go custom. Who owns each type of agent across its life. Your view on vendor lock-in across native, partner, and custom routes. The lock-in question is more important than people admit. Five years from now, the vendors you depend on will look different. The agents you built yourself will not.
“Some teams default to building everything out of pride. Others default to buying everything out of risk aversion. Both produce bad portfolios. Make the call per use case, in writing, signed by someone with skin in the game.”
Fourth — Experience
Where the user actually meets the agent. Inside Workday. In Microsoft Teams or Slack. Through email. Through the company intranet. For most HR use cases, the agent should appear in the place the user already works. An employee asking a policy question is usually in a chat client. A manager running a review is usually in Workday itself. Agents that require users to go somewhere new tend to die from low adoption regardless of how clever they are.
Three operating principles that consistently matter. Fast, because nobody waits more than five seconds for an agent to answer. Trusted, because if the agent gets the first answer wrong the user does not come back. Simple, because the moment the agent asks a question the user does not know how to answer, the conversation dies. None of these are visible in a demo. All of them are visible in week three of real use.
The classic mis-step here is building the agent in the channel that is easiest for engineering instead of the channel where users already work. The team picks Teams because the IT stack is Microsoft, but the workforce lives in the intranet portal. Adoption stalls. Everyone blames the agent. The agent was fine. The channel was wrong.
Fifth — Roadmap
The last conversation, the one that turns the strategy into something people will actually do. Three horizons on one page. Now to 90 days. 90 days to 12 months. 12 months onwards.
Now to 90 days. One or two pilots. Native or partner agents from the marketplace, because custom builds rarely fit a 90-day window. Tight scope. Real KPIs. A user group that has agreed to be measured. A clear stop, scale, or adjust decision at the end.
90 days to 12 months. Scale what worked. Add the first one or two custom agents if you have proven a use case that demands them. Formalise the operating model with a small cross-functional squad (HRIS, HR, IT, data) and named roles. Embed your governance checklist in project intake so every new initiative is classified before it ships, not after.
Beyond 12 months. Agents as a portfolio, not a project. A curated set of strategic partners, a small set of in-house custom agents, and a centre that prioritises, governs, and retires. Some of your year-one agents will be turned off in year two. That is healthy. Apps without sponsors fade, and the discipline of retiring them keeps the portfolio honest.
The one-page output
The five conversations collapse onto one page in five blocks: the vision sentence, the risk stance and high-risk use cases, the build-versus-buy default and the criteria for going custom, the experience principles and the channel decisions, and the 90-day plan with the cadence for revisiting it. Anyone in the steering committee should be able to read it in two minutes. If the strategy is longer than a page, it is probably still a list of opinions rather than a set of decisions. Compressing it forces the real arguments to surface, and the page that fits is the one that gets carried into the room and used.
