Workday Says AI Agents Belong Closer to the Systems They Could Break

Workday AI agents enterprise governance system of record architecture

Key Takeaways

Workday's position is that AI agents executing HR, payroll, and finance workflows must run inside the system of record to maintain governance controls, audit trails, and business rules.

Workday is taking a controlled openness approach: opening its platform to external developer tools via APIs and MCP while keeping its governance layer proprietary, positioning context and business logic as its core competitive moat against neutral AI orchestration platforms.

For ERP and HCM leaders, the agent architecture debate is not purely technical—it is a strategic governance decision about where accountability, permissions, and audit trails live when AI agents make decisions in sensitive enterprise processes.

ERP Today recently examined how Workday is redrawing the build-versus-buy line for AI agents by opening its platform to external developer tools while keeping governance inside Workday.

A new interview with Workday CTO Gabe Monroy, published by The New Stack on June 28, adds a sharper architectural argument to that strategy: When AI agents act on HR, payroll, and finance data, the safest place for critical orchestration may be close to the system of record itself.

Partner With Us

Why Inference Location Matters

Monroy argued that enterprise AI cannot rely on “good enough” performance when agents interact with people and money. Payroll, benefits, workforce data, budgets, and ledgers leave little room for probabilistic errors that might be acceptable in lower-risk productivity workflows.

His core argument is that enterprise guardrails should be embedded closer to the inference engine rather than wrapped around the model after the fact.

That is a technical point with ERP implications. If an agent is asked to approve a benefit change, check budget authority, update a worker record, or trigger a finance workflow, the system needs to know more than the prompt. It needs to understand who the user is, what authority they have, which business process applies, what data they can see, and how the action should be logged.

Workday’s position is that those controls are stronger when inference and orchestration happen near the underlying HR and finance system. External tools can still connect through APIs, Model Context Protocol (MCP) servers, and Workday Data Cloud, but the most sensitive parts of the agent loop may need to run inside Workday’s trusted environment.

Attend Our Next Event

Open Tools, Closed Control Points

This does not mean Workday wants to own every developer tool. The company’s DevCon strategy actually points in the opposite direction.

Workday is letting developers build from the tools they already use, while Agent-Ready Tools expose Workday business logic through standards such as MCP. Agent Passport is intended to test, verify, and monitor agents before and after deployment.

That combination creates a controlled openness model. Developers can build outside Workday, agents can connect across systems, and third-party tools can participate. But when agents need to act on Workday data or business processes, Workday wants the governance layer to remain close to its platform.

The company’s acquisition of Pipedream also fits that strategy. It gives agents a way to reach third-party systems, such as documents in Google Drive or other external applications, while still checking whether the agent has the right access to perform the action.

Get Our Free Weekly Newsletter

The Agent Platform Debate Is Still Open

Workday is not alone in making the proximity-and-context argument. Every major system-of-record vendor has an incentive to argue that agents work best near its own data, workflows, and permissions. ERP, HCM, CRM, procurement, and IT service management providers all see context as a moat.

At the same time, neutral orchestration platforms and AI tool vendors are trying to make the opposite case that enterprises need a common agent layer across systems rather than one agent platform per application vendor.

That tension will matter for customers. Few enterprises want to manage a separate agent runtime, governance model, and orchestration approach for every major application. But putting all orchestration outside the system of record may weaken the very controls that make AI safe enough for high-risk workflows.

Workday’s answer is to let general-purpose tools handle general-purpose work while keeping the highest-risk agent actions close to Workday. That may be practical in the short term, but it leaves open a larger enterprise architecture question: how much AI control should sit inside application platforms, and how much should sit in a cross-enterprise agent layer?

Sponsor Industry‑Grade Research

What This Means for ERP Insiders

Agent architecture is becoming an ERP control issue. Workday’s argument shifts the discussion from what agents can build to where high-risk agent decisions should run. ERP leaders should evaluate whether agent orchestration happens close enough to the systems that understand permissions, approvals, audit trails, and business rules.

System-of-record vendors are turning context into a moat. Workday is opening up to external developer tools while keeping the most valuable control points near HR and finance data. Customers should expect ERP and HCM vendors to compete less on coding surfaces and more on trusted execution, governed access, and business-context enforcement.

The enterprise agent stack will not settle quickly. Workday’s model favors governed proximity for sensitive workflows, while neutral platforms will argue for cross-system orchestration. Technology leaders should avoid locking agent strategy into one layer too early and instead define which workflows require system-level controls, which can run externally, and how evidence, revocation, and accountability will work across both.