First, the basics. Claude Cowork is Anthropic's desktop agent: Claude that runs on a Mac or Windows machine, reads your files, executes multi-step tasks, and produces actual documents instead of just chat responses. The HR plugin is one of ten plugins Anthropic released, and it gives Claude structured HR capabilities through slash commands.

What the plugin actually does

Four slash commands give a fair picture of the scope. /hr:offer-letter takes a role, level, location, and comp details and produces a complete offer letter with equity breakdown and benefits summary. /hr:onboarding-plan takes a name, role, team, and start date and produces a first-week calendar, tool access list, and buddy assignment template. /hr:performance-review takes goals and feedback and produces a structured review summary. /hr:comp-analysis benchmarks roles against market data.

Underneath the slash commands are skills that fire automatically. Claude knows enough about HR terminology and compliance context that you do not need to write detailed prompts for every task. The output is decent on its own. The plugin is open source on GitHub, so the prompts and skill definitions are inspectable, forkable, and improvable by your team.

The catch

The plugin works standalone. You paste data in. Claude generates documents locally. There is no live connection to your HRIS, no pulling data from Workday, no writing back. It is useful for ad-hoc drafts. It is not useful for anything that requires your real employee data, at scale, on a schedule.

The real power unlocks when the plugin connects to your systems. That is where MCP comes in.

The bridge: MCP

Anthropic built Claude on MCP, the Model Context Protocol. It is an open standard for connecting AI to external data and tools. Think of MCP as a universal adapter: it lets Claude talk to Slack, Google Workspace, DocuSign, Gmail, and dozens of other systems through a single interface.

Third-party MCP servers for Workday already exist. Composio, StackOne, CData, and Zapier all offer Workday MCP integrations. Workday itself has committed to MCP. Their Agent Gateway uses MCP and A2A protocols and is currently in Early Access with general availability not far behind.

Translation: the architecture is in place to wire Claude into your Workday tenant. The question is no longer 'can this be done' but 'should this be done, by whom, and under what controls'.

What it looks like to connect today

Today, the most common way to connect Claude to Workday is via an Integration System User. That works. The problem is that an ISU has unconstrained data access. It does not respect the calling user's security model. If the ISU has access to compensation data, it has access to everyone's compensation. Claude will happily return all of it on request.

That is why we do not recommend connecting Claude to any Workday tenant that contains real employee data. If you want to experiment, use a GMS tenant or a sandbox with synthetic data. Constrained data access for agents (where the agent inherits the security profile of the calling user) is technically possible today, and Workday's Agent System of Record is the path to making it standard. That work is in progress.

“The architecture to connect Claude to Workday is in place. The production-grade governance is not. The gap is closing fast, and the teams that prepare now will be the ones who control the conversation when the connection is real.”

What it could look like in six months

A few scenarios that sit inside the realistic envelope of what becomes possible when constrained MCP access lands.

  • Draft the performance review for John. Pull goals from Workday, feedback from Slack and the calibration notes in our shared drive.
  • Which managers have the highest team attrition in the last six months? Summarise it and flag anyone above 20 percent.
  • Build an onboarding plan for the 12 new hires starting in April. Pull their roles and teams from Workday.
  • Draft offer letters for the three open R&D roles using the approved comp band, the location adjustments, and our standard equity grid.

Each of these is a workflow that an HRIS team or HRBP does today, slowly, by hand. Each becomes a 60-second task with Claude plus a Workday MCP connector, plus the right governance to make it safe.

What HRIS teams should do now

This is not plug-and-play, and it should not be treated as such. Connecting Claude to Workday requires deliberate configuration work (ISU, security setup, API client, OAuth) and deliberate decisions about scope (read-only versus write access, which workflows are in, which are out). Five questions are worth answering before any HRIS leader signs up to a connected pilot.

  • Data governance: what employee data is Claude allowed to see, and how do we enforce that at the system level rather than relying on prompts?
  • Validation: who checks Claude's output before it reaches a candidate, an employee, or a manager?
  • Audit trail: how do we know what Claude generated versus what a human wrote, six months later, in a compliance review?
  • Compliance: does our AI use policy actually cover desktop agents that connect to enterprise systems? Most do not, yet.
  • Security: where does our data flow? Cowork runs locally, but MCP connections route through external servers. Map the path.

Alongside those five questions sit two practical moves that put HRIS teams in front of the curve. Get hands-on in a safe environment: install the plugin, run the slash commands against your GMS tenant, and judge the output quality with your own team. The strategy conversation goes better when the people having it have actually used the thing. Then decide your future architecture posture: Workday's Agent Gateway when it goes GA, or a third-party or middleware solution. The answer determines what you build now and what you defer.

The honest next step is to draft the AI use policy that covers desktop agents connecting to enterprise systems before the production-grade connection is real. Most existing policies do not cover this case, and updating them takes longer than people expect.