AWS Agent Registry, Databricks, Google, and Microsoft have each shipped their own catalog for approving which agents are allowed to run, and an enterprise using all four gets four separate answers to that one question. None of those catalogs answer a different one: is what the approved agent knows still true, which is the question Atlan’s context layer exists to answer instead. A registry and a context layer do separate, complementary work: the registry keeps deciding who runs, and Atlan keeps that decision grounded in accurate context.
Atlan’s Enterprise Data Graph and Context Repos package business definitions, lineage, and ownership into versioned units an agent calls over MCP the moment it needs them, regardless of which registry approved it. That’s a genuinely different job than checking identity, approval, or version, which is what a registry does well and isn’t built to do beyond. The short version: the registry manages the agents, Atlan governs what they know.
- What answers “which agent may run”: the registry, identity checks, approval workflow, version control
- What answers “is this still true”: the context layer, business definitions, lineage, ownership, freshness
- Where they meet: an approved agent calling out over MCP for governed context at the moment it needs it
- The failure mode neither alone catches: an agent that passed every approval gate, six months ago, still reasoning from a metric definition nobody updated
| Agent registries and the context layer: quick facts | |
|---|---|
| What it is | Registry: which agents may run. Context layer: what those agents know |
| Key distinction | Registry: identity, approval, version. Context layer: meaning, lineage, ownership, freshness |
| Best for | Registries: discovery and approval at scale. Context layers: accurate definitions from 15 to 150,000 agents |
| Where they connect | Governed context delivered into a registry-approved agent through MCP |
| Who ships registries | AWS Agent Registry (GA August 31, 2026), Databricks, Google, Microsoft, MuleSoft |
| Core risk if skipped | An approved agent reasoning from a stale or wrong definition |
What does an agent registry actually govern?
Permalink to “What does an agent registry actually govern?”An agent registry is a catalog that tracks which agents, tools, skills, and MCP servers exist across an organization, who owns them, which version is deployed, and whether they’re approved to run. According to AWS, AWS Agent Registry reached general availability on August 31, 2026, built inside Amazon Bedrock AgentCore as a private, governed catalog spanning an entire AWS Organization.
Worth separating out early: this isn’t the same object as a general-purpose AI registry built for regulatory inventory under the EU AI Act, and it’s broader than an agent skills registry, which tracks skill packages specifically. It’s closer in spirit to an agent registry compared against a model registry: one versions the model artifact, the other versions the agent that calls it, and neither versions the business definitions either is reasoning over.
The mechanics show exactly where the registry’s job ends. AgentCore Gateway sits in front of agentic traffic as a single entry point, aggregating AWS Lambda functions, APIs, and MCP servers behind one interface, and the registry itself is exposed as an MCP server so a client can query it directly. That’s a narrower relationship than an agent registry compared against an MCP registry makes it sound: the registry catalogs approved agents, MCP is the protocol that lets a client query that catalog, and conflating “cataloged” with “delivered” is the confusion this pairing invites. It’s real, useful agent interoperability infrastructure, and it’s entirely about discovery, approval, and version, not about the accuracy of anything the approved agent goes on to say.
Southwest Airlines is AWS’s named reference deployment. According to AWS’s own customer reference (2026), CIO Lauren Woods said the registry “cut duplicative development effort significantly,” and VP of AI Justin Bundick called it the foundation for “scaling thousands of agents with enterprise-grade governance from day one.” Both quotes describe reuse and approval at scale, not whether the agents pulling from the registry are working from current business definitions, which is a separate audit a registry was never built to run.
The registry answers which agent may run. It doesn’t ask whether the agent, once running, is reasoning from something that’s still true.
Registry vs. context layer: two different audits
Permalink to “Registry vs. context layer: two different audits”The clean way to state the difference: a registry checks execution identity, a context layer checks knowledge accuracy, and an enterprise needs both running at once. Registry-per-platform is also not a temporary phase enterprises will architect their way out of. It’s the default outcome of running more than one cloud, and most enterprises already do.
According to Forbes, AWS, Google, and Microsoft were already racing to ship competing agent-governance layers by April 2026, and Salesforce’s MuleSoft expanded its own Agent Registry into the broader Agent Fabric the same year. That’s not hypothetical fragmentation. Inside real enterprises it already looks like Medtronic running 400 custom agents, 300 Cortex agents, 150 Databricks agents, and 40 Teneo agents with no reconciliation between them, or HP carrying 250 ungoverned Databricks Genie Spaces while GM carries thousands, per Glean’s synthesis of Gong calls behind agent sprawl research. Four registries mean four separate approval answers for the same organization, and none of the four talk to each other.
According to InfoWorld’s coverage of the launch, AWS markets its own registry as indexing agents regardless of where they run, including other clouds and on-premises, which reads like it already solves the fragmentation above. It doesn’t: that’s AWS’s own catalog extending its visibility outward, not a neutral layer that also reads from a Databricks Unity Catalog agent list or a Google Vertex AI registry. An enterprise still chooses per platform which registry is the system of record, and whether those approved agents work from accurate business context stays open regardless of which registry claims the widest reach.
What the registry-and-context split actually means
Permalink to “What the registry-and-context split actually means”The registry manages the agents; the context layer governs what they know. That line is deliberately narrow. Registration, discovery, routing, deployment, and cross-cloud approval stay each registry’s own job: AWS Agent Registry runs that job for its platform, and Databricks or Google run it for theirs, each on its own catalog. The context layer’s job is to keep the enterprise data graph of business definitions, lineage, and ownership current and deliverable to whichever agent asks, through Context Repos and one MCP server, no matter which registry cleared that agent to run.
An enterprise with four registries needs one knowledge layer underneath all four, keeping their shared context from drifting, a structurally different fix than another catalog.
Can an agent pass registry approval and still act on bad information?
Permalink to “Can an agent pass registry approval and still act on bad information?”Yes, and the mechanism is straightforward: a registry checks identity, version, and approval status at deploy time, and it has no built-in way to notice that the business definition an approved agent queries has quietly gone stale six months later. Passing registry approval is a one-time or periodic gate. Context accuracy is a continuous condition, and those are not the same clock.
The scale problem makes manual checking impossible before it makes it merely inconvenient. Gartner projects that the average Fortune 500 company will run more than 150,000 agents by 2028, up from fewer than 15 in 2025. No governance team is manually re-verifying the metric definitions behind 150,000 agents’ worth of queries, on any cadence, across four separate cloud registries. The failure mode isn’t a rogue, unapproved agent, the risk AI agent governance programs and efforts to secure multi-agent systems are built to catch. It’s a fully compliant one, correctly identified, correctly versioned, correctly approved, still reasoning from a definition of “active customer” or “recognized revenue” that changed upstream without anyone telling it.
This is also why who owns AI governance is the wrong first question. The answer changes depending on which audit is being asked about, and a single owner for agent approval doesn’t automatically own business-definition accuracy too. Registry integrity and context accuracy are different audits, and a passed registry check tells you nothing about the second one.
How does a context layer work underneath an agent registry?
Permalink to “How does a context layer work underneath an agent registry?”A context layer sits underneath the registry rather than beside it, feeding the same governed answer to any agent the registry has already approved, regardless of which cloud or catalog did the approving. That’s a different claim than a data catalog governing what a context layer needs: a catalog inventories assets, a full context layer keeps that inventory’s meaning current and serves it at runtime.
Four capabilities do that work. The Enterprise Data Graph supplies what a registry never tracks: what “revenue” means in a given business unit, which transformations back a metric, and who owns or approved a definition. Context Repos package that knowledge into bounded, versioned units many agents can share at once, including agents coordinating with each other on the same task, which is the direct counterpart to a registry entry that identifies just one. The Context Lakehouse holds it in open, Iceberg-native storage instead of a proprietary vault, keeping it queryable across any multi-cloud estate. And an MCP server is the delivery interface into all of it: the registry or runtime decides which agent runs, and that agent calls in through MCP the moment it needs governed context.
The same logic extends to the skills a registry catalogs alongside agents: a skill can clear every enterprise-safety review and still execute against a stale assumption, which is why governed context for skills travels alongside the skill’s MCP call rather than getting baked into the skill file once at review time.
What this does is bounded, and the boundary is worth stating plainly. Governed context reduces the odds of acting on stale information, a claim about data accuracy that stays separate from hallucination-free or compliant behavior, which stay the model’s job and the compliance program’s job. An agent’s own working memory of a task holds its in-session state; governed context holds the enterprise’s certified definitions, delivered fresh each time an agent asks. Observability and tracing stay with the registry or runtime that already run them; governed context adds the accuracy layer on top. Context Agents that bootstrap definitions from SQL, BI dashboards, and lineage still hand edge cases to a human for certification before anything reaches production: automation drafts the definition, a person confirms it. That same agent context management control plane keeps the certified version in front of every agent that asks.
Portable, open context, not federation, is the property that lets the same governed answer reach an agent whether it’s cataloged in AWS Agent Registry, running inside a Databricks Genie Space, or sitting behind a custom harness nobody’s put a name on yet.
Why does the same context need to travel across every registry?
Permalink to “Why does the same context need to travel across every registry?”Because the registry answer changes by platform and the context answer shouldn’t. An enterprise running AWS, Databricks, and a custom stack doesn’t get to pick one registry and call the multicloud problem solved; it gets three separate approval systems whether it wants them or not. What it can control is whether the business definitions those three systems’ agents are reasoning from are the same definitions, kept current in one place rather than drifting separately inside each platform.
The practical version of this argument, with the buyer-facing steps for actually running it, lives in how to govern AI agents across multiple clouds. The architectural mechanics behind it, including why open storage formats and bring-your-own-compute matter more than picking a single cloud, are covered in multi-cloud context layer. Both assume the same premise this page argues for: one context layer traveling with the agent, not one registry trying to replace the other three.
Real stories from real customers: context delivered where the registry approved the agent
Permalink to “Real stories from real customers: context delivered where the registry approved the agent”"Atlan captures Workday's shared language to be leveraged by AI via its MCP server. As part of Atlan's AI labs, we're co-building the semantic layer that AI needs."
— Joe DosSantos, VP Enterprise Data & Analytics, Workday
"Atlan is much more than a catalog of catalogs. It's more of a context operating system…Atlan enabled us to easily activate metadata for everything from discovery in the marketplace to AI governance to data quality to an MCP server delivering context to AI models."
— Sridher Arumugham, Chief Data & Analytics Officer, DigiKey
What separates registry approval from context you can trust?
Permalink to “What separates registry approval from context you can trust?”An agent registry and a context layer will keep looking like competing purchases for as long as buyers describe both of them as “governance,” when they’re actually two separate audits stacked on top of each other. The registry audit asks whether an agent is who it claims to be, on the version it claims to be, cleared to run. The context audit asks whether what that agent knows is still accurate, and it has to run continuously, because business definitions drift on their own schedule, not on the registry’s approval cycle.
Enterprises running hundreds of agents across four separate cloud platforms with no reconciliation between them aren’t failing the first audit. They’re passing it, repeatedly, per platform, while the second audit goes unrun entirely. A context layer is the piece that makes the second job possible at 150,000-agent scale, delivered into whichever registry already said yes.
FAQs about agent registries and the context layer
Permalink to “FAQs about agent registries and the context layer”1. Does AWS Agent Registry replace a data catalog or context layer?
Permalink to “1. Does AWS Agent Registry replace a data catalog or context layer?”No. AWS Agent Registry catalogs agents, tools, skills, and MCP servers so an organization can discover and approve what’s running. It doesn’t track business definitions, lineage, or data freshness, which is what a data catalog or context layer governs. The two solve different problems and are typically used together.
2. What is Amazon Bedrock AgentCore?
Permalink to “2. What is Amazon Bedrock AgentCore?”Amazon Bedrock AgentCore is the platform AWS built for running, connecting, and managing agentic workflows at scale. AWS Agent Registry is one component inside it, handling discovery and approval, alongside AgentCore Gateway, which aggregates agentic traffic from Lambda functions, APIs, and MCP servers behind a single entry point.
3. How does AgentCore Gateway relate to MCP?
Permalink to “3. How does AgentCore Gateway relate to MCP?”AgentCore Gateway acts as an MCP aggregator, presenting multiple backend tools and services as one unified MCP endpoint for an agent to call. AWS also exposes the Agent Registry itself as an MCP server, so a developer can query the approved-agent catalog directly from an MCP-compatible client like an IDE.
4. Is agent governance the same as data governance?
Permalink to “4. Is agent governance the same as data governance?”No, and conflating them is the mistake this page argues against. Agent governance, the domain a registry covers, manages agent identity, permissions, and lifecycle. Data governance, the domain a context layer covers, manages whether the business definitions and lineage an agent relies on are accurate and current. Both run together: the registry keeps agent identity and lifecycle straight, and data governance keeps the definitions those agents rely on accurate.
5. Do I need a context layer if I already have an agent registry?
Permalink to “5. Do I need a context layer if I already have an agent registry?”Yes, if any of your registry-approved agents reason over live business data. A registry confirms an agent is identified, versioned, and cleared to run. It has no mechanism for verifying that the metric definitions or lineage that agent queries are still accurate months after approval.
6. How do multiple cloud registries stay in sync?
Permalink to “6. How do multiple cloud registries stay in sync?”They generally don’t, and that’s the practical reality rather than a solved problem. AWS, Databricks, Google, and Microsoft each maintain their own registry scoped to their own platform, and none currently federate with the others. What can stay consistent across all of them is the underlying business context, delivered through open protocols like MCP into whichever registry approved the calling agent.
Sources
Permalink to “Sources”- Manage agents, tools, and skills at scale with AWS Agent Registry, AWS Machine Learning Blog, 2026. https://aws.amazon.com/blogs/machine-learning/manage-agents-tools-and-skills-at-scale-with-aws-agent-registry/
- AWS Agent Registry for centralized agent discovery and governance is now available in Preview, AWS What’s New, April 2026. https://aws.amazon.com/about-aws/whats-new/2026/04/aws-agent-registry-in-agentcore-preview
- Agent Registries Become The New Battleground For Cloud Giants, Forbes, April 2026. https://www.forbes.com/sites/janakirammsv/2026/04/10/agent-registries-become-the-new-battleground-for-cloud-giants/
- AWS targets AI agent sprawl with new Bedrock Agent Registry, InfoWorld, 2026. https://www.infoworld.com/article/4157183/aws-targets-ai-agent-sprawl-with-new-bedrock-agent-registry.html
- AWS previews a cloud-agnostic registry for managing agentic fleets at scale, SiliconANGLE, April 2026. https://siliconangle.com/2026/04/09/aws-previews-cloud-agnostic-registry-managing-agentic-fleets-scale/
- Gartner Identifies Six Steps to Manage Artificial Intelligence Agent Sprawl, Gartner, April 2026. https://www.gartner.com/en/newsroom/press-releases/2026-04-28-gartner-identifies-six-steps-to-manage-artificial-intelligence-agent-sprawl
- AI Agents Are the New Control Plane: Governing Identity, Tool Access, and Observability Across Azure, AWS, Google Cloud, and VCF, Digital Thought Disruption, July 2026. https://digitalthoughtdisruption.com/2026/07/06/ai-agent-control-plane-governance-azure-aws-google-vcf/
- Salesforce Launches MuleSoft Agent Fabric to Orchestrate and Govern Any AI Agent Across the Agentic Enterprise, Salesforce, 2026. https://www.salesforce.com/news/stories/mulesoft-agent-fabric-announcement/
