Workday Builds a Shared Data Layer for Its Enterprise AI Agents

The Databricks-based design is meant to prevent every agent from creating its own data connections and permissions. The test will be whether centralized controls can keep pace as agents begin coordinating across business functions.

By 3 min read
Workday Builds a Shared Data Layer for Its Enterprise AI Agents
Workday Builds a Shared Data Layer for Its Enterprise AI Agents

Listen to this story

The audio brief

About 1:33
0:001:33
Read transcript
Workday says it has built a shared data layer with Databricks for enterprise AI agents, so each new agent does not need its own web of data connections and permissions. The design uses Apache Iceberg for storage and Unity Catalog for governance. The problem Workday is addressing is what it calls an M-by-N connectivity problem: with many agents and many business systems, connecting every agent directly to every system creates a fast-growing tangle. A shared layer is meant to make that closer to an M-plus-N model—add an agent or a data source to the common foundation, rather than another set of point-to-point links. Iceberg provides ACID transactions and snapshot isolation, intended to give agents a consistent view while datasets are being used. Unity Catalog controls fine-grained access, policy enforcement, lineage, audits, and monitoring. That matters when an answer crosses organizational boundaries. Workday’s example is a sales employee asking about an account outside their territory; the agent should withhold information the employee is not entitled to see. Short-term session memory stays in vector stores, while long-term memory and reasoning traces remain in Iceberg, allowing operators to investigate how an answer was produced. Workday says the architecture now supports coordinated agents across finance, human resources, procurement, supply chain, marketing, and sales, though those deployment and impact claims have not been independently verified. The next constraint is interoperability: broader data support, agent registries, MCP servers, and more automated governance still need to work across the shared layer.

Story brief

3 key points

Workday is standardizing enterprise-agent data access around a shared layer built with Databricks, rather than replicating data across agent-specific stores. Apache Iceberg provides transactional consistency, while Unity Catalog handles permissions, lineage, auditing, and monitoring. Workday says the architecture now supports multi-agent deployments across finance, HR, procurement, supply chain, marketing, and...

  1. 01

    The design targets an M×N connectivity problem by shifting toward an additive M+N model for agents and data systems.

  2. 02

    Iceberg supplies ACID transactions and snapshot isolation; Unity Catalog governs fine-grained access, policy enforcement, lineage, and audits.

  3. 03

    Workday says short-term memory stays in vector stores, while long-term memory and reasoning traces remain in Iceberg.

Workday says it has partnered with Databricks to build a universal data layer for enterprise AI agents, using Apache Iceberg for data storage and Unity Catalog for governance. The aim is to have agents query a shared foundation instead of copying data into separate stores—a design Workday says is necessary to avoid an explosion of hard-to-monitor connections as agents spread through the business.

The architectural problem is simple, even if the implementation is not. An organization with many agents and many data systems can give each agent its own direct connections. Workday describes that as a multiplicative M×N problem. Its alternative is an additive M+N model: add a data system or an agent to the common layer, rather than build another set of point-to-point links.

Apache Iceberg supplies the transactional properties beneath that setup, including ACID compliance and snapshot isolation. In plain terms, those are intended to give agents a consistent view of data while multiple agents may be reading the same datasets. Unity Catalog sits above it as the control layer for permissions, lineage and audit records.

That governance boundary matters most when an agent answers a request that crosses organizational lines. Workday says Unity Catalog provides fine-grained access controls, policy enforcement, observability and monitoring alongside lineage and auditing. Its example is a sales employee asking for account information outside their assigned territory: the agent should recognize the employee’s entitlement and withhold data they are not authorized to see.

The company is also treating memory and explanations as part of the data architecture. Workday says it keeps short-term session memory in vector stores, while preserving long-term memory in Iceberg and retaining reasoning traces. That approach is meant to let operators reconstruct why an agent produced an answer when its output is questioned.

  • Accelerating finance close cycles and identifying attrition risk earlier.
  • Improving supply-chain management and procurement negotiations.
  • Supporting retention modeling and sales planning.

Workday says it has moved from single-agent pilots to coordinated multi-agent deployments across functions including finance, HR, procurement, supply chain, marketing and sales. It says that progression has not required replicated data stores because agents consume the shared layer. The deployment progress is a company account, not an independently published measure of accuracy or business impact.

The next challenge is interoperability. Workday says it plans to expand support for increasingly complex and varied organizational data, develop agent registries and communication protocols including MCP servers, and automate more governance and observability. Its bet is that agents will need shared rules and shared records before they can work coherently with one another at enterprise scale.

Sources

  1. docs.databricks.comdocs.databricks.com
  2. databricks.comBringing Agents to Data

Loading discussion...

YOUR READING SPACE

Notifications