Workday goes headless for AI agents. Its bet is that the business rules travel with every request
Workday opened HR and finance to outside agents through MCP tools and live SQL, and is taking Sana into Claude, Copilot and Slack. The interface becomes optional; permissions and audit do not.
Listen to this article · 6 min
AI-generated narration of the full article.
“Headless can’t mean lawless.” Gabe Monroy, Workday’s chief technology officer, put the whole announcement in one line at Workday Rising on October 13.
Headless software exposes its functions without its own screens, so other applications can drive it. For a system of record that holds pay, positions, approvals and the general ledger, going headless for AI agents is a significant step. Workday took it in two directions at once.
Agents coming in
Workday’s Trusted Agent Platform is now generally available in its core parts:
- Agent Harness, which runs every agent built by Workday, customers or partners, supplies the requester’s role, reporting line, permissions and policies, governs each action and routes work to models by cost and performance;
- Agent-Ready Tools, Workday’s MCP tools, generally available in Workday Extend AI, which let any MCP-capable agent read Workday data and take actions;
- Workday Data Cloud, including Live Data Query, which lets users and agents run SQL against live Workday data instead of custom reports or stale copies;
- Developer Agent and Custom Agents in Extend AI, for building agents that run on the harness.
Models offered include Claude, Gemini, Llama, Mistral, GPT and NVIDIA Nemotron. LangChain support is GA; Google ADK support is still taking design partners. Two harness services are not here yet: Agent Context Service is planned for early access in late 2026 and Grounded Reasoning for early access in early 2027.
Workday going out
The second announcement runs the other way. Sana, Workday’s agent experience and orchestration engine, is going into Claude, Gemini Enterprise, Microsoft Copilot, Teams and Slack. Self-service with Sana is GA in Gemini Enterprise, Copilot, Teams and Slack today; the full Sana experience there is planned for late 2026. Sana in Claude Cowork is in early access, and a Sana MCP for Microsoft Copilot is expected in early access in late 2026. Anthropic and Workday also announced a partnership around this connection.
Workday’s line on the outward direction is direct: “Third-party AI tools and platforms never get raw access to Workday data.” An employee can start a request in Copilot or Claude; Sana routes it to Workday agents, checks policies and approvals, and “saves the chosen plan to Workday with a full audit trail.”
Where each decision sits in Workday's design
Interface
- Claude
- Copilot
- Teams
- Slack
- Customer agents
Interchangeable entry points
Reasoning and orchestration
- Any supported model
- Sana
- Agent Harness
Plans the work, routes to models
Authorization
- Requester identity
- Workday permissions
- Approval chains
Decided in Workday, per request
Execution and record
- Business transaction
- Audit trail
Never leaves the system of record
Why the architecture matters more than the features
Enterprise teams have built HR and finance assistants mostly by copying data out: reports into a warehouse, extracts into a vector index, a service account with broad read rights. Each copy needs its own access model, and the service account sees more than any single employee should. We described the cost of that pattern in HR agents without a second copy of Workday.
Workday’s design inverts it. The agent comes to the data under the requester’s identity, and authorization is decided where the business rules already live. That is the same principle SAP applies when it keeps Joule’s agents inside the transaction system: controls that already work are inherited, not rebuilt. The difference is that Workday now offers it to agents it did not build and interfaces it does not own.
What the release does not settle
“Every agent, whether it’s built by Workday, a customer, or partner, works under the same Workday permissions, approvals, and audit trails,” according to the release. That holds when the agent goes through Agent-Ready Tools or Live Data Query with the requester’s identity. It does not automatically cover what happens on the other side of the call:
- What leaves. Results returned to an outside agent are now in that agent’s context, logs and possibly memory, governed by the other platform’s retention, not Workday’s.
- Whose identity. An agent that calls Workday with a broad integration identity instead of the employee’s gets the integration’s permissions. The platform supports the right pattern; the integration has to use it.
- Two audit trails. Workday records the transaction; the assistant where the request started records the conversation. Reconstructing an incident needs both, joined by something both sides log.
- Licensing. Agent-Ready Tools, Custom Agents and Developer Agent are GA in Workday Extend AI. Check what your tenant has before designing around them.
What to do with it
For teams planning HR or finance agents, the practical choice has changed. Before building another extract, ask whether the agent can call Workday’s tools under the employee’s identity instead. Write down which entry points are allowed to start which transactions. And treat the outside assistant’s logs and memory as part of the HR data estate, because after the first call, they are.