An AI agent registry is a governed catalog that records which agents, tools, skills, and MCP servers exist across an organization, who owns each one, and whether it’s approved to run. In 2026, AWS, Microsoft, Google, and MuleSoft each shipped a competing version of this catalog for their own platform, and Atlan sits underneath all four as the layer that carries meaning between them. AWS Agent Registry alone reached general availability on August 31, 2026, the same year Gartner projected the average Fortune 500 will run more than 150,000 AI agents by 2028.
A registry answers a narrow question well: does this agent exist, who’s accountable for it, and has it passed review. It typically records four kinds of things: the agent itself, the tools and skills it calls, the MCP servers it connects through, and the approval metadata attached to each. What it doesn’t record is whether the business definitions those agents depend on are still accurate, or whether two approved agents on two different clouds agree on what a shared term means.
| What it is | A governed catalog of agents, tools, skills, and MCP servers with ownership and approval status |
|---|---|
| Key stat | 150,000+ agents per average Fortune 500 by 2028, per Gartner, up from fewer than 15 in 2025 |
| Who ships one (2026) | AWS, Microsoft, Google, and MuleSoft, each scoped to its own platform |
| Root category confusion | Different from an AI registry: a regulatory inventory of models and use cases |
| Structural fix | A registry for identity and approval, plus a shared context layer for meaning, both required |
| 2026 milestone | AWS Agent Registry’s general availability, August 31, 2026 |
What does an AI agent registry actually record?
Permalink to “What does an AI agent registry actually record?”Every major agent registry shares the same recordable pattern, even though each vendor brands it differently. According to AWS (2026), AWS Agent Registry supports four record types: an MCP server with its tools, resources, and prompts; an agent defined by an Agent2Agent (A2A) card; a skill written as a markdown file with its supporting code; and a custom JSON descriptor for anything else. Records move through an approval workflow: Draft, then Pending Approval, then Approved or Rejected, then Deprecated once retired.
| Record type | What it captures | AWS Agent Registry example |
|---|---|---|
| Agent | Identity, owner, capabilities | An A2A agent card defining the agent and its skills |
| Tool or skill | Instructions and code loaded at runtime | A skill’s markdown definition and associated package |
| MCP server | Tools, resources, and prompts it can reach | An MCP server record with its exposed tools |
| Policy and approval metadata | Owner, status, and usage permissions | Draft, Pending, Approved, or Deprecated |
Southwest Airlines describes exactly the problem this structure solves. Lauren Woods, CIO and EVP at Southwest Airlines, said the airline “went from dozens of agents and tools scattered across multiple technology teams with no shared record of what existed to a single, governed catalog that the entire organization trusts,” adding that the registry “cut duplicative development effort significantly and became the backbone of how we govern agentic AI” (AWS, 2026). Syngenta reports the same pattern from the builder’s side: Sandeep Rayasa, Enterprise Architect for Data and AI at Syngenta, said teams now “publish once, then discover and reuse what already works, instead of rebuilding agents, connectors, and business procedures from scratch” (same source).
That’s real, measurable value, and it’s also a specific, bounded kind of value. A registry entry proves an agent’s identity, its owner, and its review status, for anything from a simple reflex bot to a complex multi-agent system. It doesn’t audit whether the logic inside it still reflects how the business actually works.
Why did every major cloud platform ship its own agent registry in 2026?
Permalink to “Why did every major cloud platform ship its own agent registry in 2026?”Four separate agent registries launched within about a year of each other, which is the direct cause of the one-registry-per-cloud reality enterprises now live with. MuleSoft’s Agent Fabric, part of Salesforce, shipped its own Agent Registry in October 2025, then added “Agent Scanners” in January 2026 to auto-discover agents on AWS Bedrock, Google Vertex AI, and Microsoft Copilot Studio. AWS Agent Registry moved from preview to general availability on August 31, 2026. Microsoft’s Agent 365 followed on May 1, 2026, giving admins “a single, centralized registry” for every agent. Google announced its own Agent Registry at Google Cloud Next on April 23, indexing “every internal agent, tool, and skill” so “only governed, approved assets are available to your users.”
| Platform | Registry | 2026 milestone | What’s distinctive |
|---|---|---|---|
| AWS | AWS Agent Registry | GA August 31 | Native Bedrock AgentCore integration; semantic and keyword search |
| Microsoft | Agent 365 registry | GA May 1 | Agents as identities inside Microsoft Entra |
| Gemini Enterprise Agent Platform’s Agent Registry | Announced April 23, at Google Cloud Next | Agent, tool, and skill indexing built into the wider platform | |
| MuleSoft | Agent Fabric’s Agent Registry | GA October 2025, extended January 2026 | Cross-platform agent auto-discovery via Agent Scanners |
None of this happened because one vendor solved the problem and the others copied a working template. According to Gartner (2026), building a centralized agent inventory is step two of a six-step framework for managing agent sprawl, and every platform vendor read that step as a reason to ship its own inventory tool rather than wait for a shared one. Janakiram MSV, writing in Forbes, put the resulting reality plainly: “For most large enterprises, the realistic answer is that they will eventually need more than one approach,” because “none of these registries interoperate with each other” (Forbes, 2026).
MuleSoft’s Agent Scanners deserve naming honestly as a genuine, partial answer to that gap: they can spot an agent running on a second or third cloud and pull it into MuleSoft’s own inventory. That’s real cross-platform visibility, not vaporware. But it operates at the same layer as the problem it’s solving. Knowing an agent exists on another cloud, whichever graph store, Amazon Neptune or otherwise, tracks that relationship, isn’t the same as knowing it means the same thing by “active customer” as the agent next to it. Registry-per-platform is the default outcome of running AI on more than one cloud, and a multi-cloud context layer is a different, complementary investment that runs underneath the registries already in place.
What can an AI agent registry verify, and what can’t it?
Permalink to “What can an AI agent registry verify, and what can’t it?”A registry entry is a claim about an artifact: it exists, someone owns it, and it passed a review. That’s a narrower claim than “this agent gives correct answers,” and enterprises running multiple registries feel the gap first.
What a registry verifies
Permalink to “What a registry verifies”Existence, ownership, version history, approval status, and who’s allowed to invoke it. These are the fields every registry we’ve covered shares, whatever the vendor calls them.
What it can’t verify
Permalink to “What it can’t verify”Whether a business definition an agent depends on, like “recognized revenue” or “active customer,” is still current. Whether two registry-approved agents on two different clouds resolve a shared term the same way. Whether a skill that passed a security scan is also reasoning from accurate business context. None of that shows up in registry metrics; it’s the separate territory of AI agent accuracy and context observability, which catch an agent drifting from a certified definition well after approval.
Large enterprises running agents across four or five different platforms describe the same pattern: dozens to hundreds of agents built on different stacks by different teams, each fully registered and approved on its own platform, with no way to check whether any two of them agree on a shared business term. The gap isn’t a missing registry. It’s a missing way to know whether the registries’ approved agents agree with each other. An approved artifact is not the same claim as an accurate one, and trust in what ran and trust in what it knew turn out to be two different audits, not one.
AI agent registry vs AI registry vs agent skills registry: how are they different?
Permalink to “AI agent registry vs AI registry vs agent skills registry: how are they different?”Vendor marketing blurs three adjacent terms together, and untangling them is most of what this page is for. An AI agent registry, the subject of this page, catalogs agents, tools, skills, and MCP servers together as one operational inventory. An AI registry is a different, older category: a regulatory inventory of every AI system a company runs, built for EU AI Act, NIST AI RMF, and ISO/IEC 42001 audits, not developer discovery. An agent skills registry is narrower still, scoped only to skill packages, distinct from the tools an agent calls directly or from MCP itself, with its own discipline for how skills are engineered and versioned and for keeping a skill’s business logic current after it ships.
| Registry type | Primary question it answers | Example |
|---|---|---|
| AI agent registry | Which agents, tools, skills, and MCP servers exist, and who owns them | AWS Agent Registry, Microsoft’s Agent 365, Google’s registry, MuleSoft’s Agent Fabric |
| AI registry | Which AI systems does the company run, and what’s their regulatory risk tier | Atlan’s AI registry guide |
| Agent skills registry | Is this skill package published, versioned, and scanned | Atlan’s agent skills registry guide |
If you’re comparing an agent registry against an adjacent infrastructure category rather than a naming problem, two sibling breakdowns go deeper: agent registry vs model registry covers the model-lifecycle side, and agent registry vs MCP registry covers the protocol side.
Common mistakes when a registry gets treated as the whole answer
Permalink to “Common mistakes when a registry gets treated as the whole answer”Teams that stop at “we have a registry” run into the same small set of predictable failure patterns.
The first is treating approval as proof of accuracy. A skill that cleared a security scan and got marked Approved can still reason from a stale metric definition, because nothing in that workflow checked the definition itself. The second is standing up a registry per team instead of per platform, multiplying the exact agent sprawl the registry was meant to fix. The third is assuming a registry built for one cloud scales to a multicloud estate without a second investment, an assumption Azure AI Foundry users discover once they add a Bedrock or Vertex deployment. The fourth is treating “who owns the registry” and who owns AI governance as the same question; that debate usually stalls a rollout longer than any integration does, and it’s separate from who signs off on model choices through a model council.
None of these are reasons to skip a registry. Securing a multi-agent system or standardizing an agent development lifecycle both depend on one. They’re reasons not to stop there. The mistake isn’t choosing the wrong registry. It’s expecting a registry to answer a question it was never built to answer, the same way a decision trace tells you what an agent did without telling you whether what it knew was true.
How Atlan complements an AI agent registry
Permalink to “How Atlan complements an AI agent registry”Atlan is the context layer that registry-approved agents reason from once they’re running, on whichever cloud approved them. AWS Agent Registry, Microsoft’s Agent 365, Google’s registry, and MuleSoft’s Agent Fabric handle identity and approval on their own platforms; Atlan supplies the shared business meaning underneath all four.
The gap those registries leave open is the same one large multicloud enterprises keep hitting: two agents can each be fully registered, owned, and approved, and still give conflicting answers because they were never told to agree on what “revenue” or “active customer” means. Atlan’s Enterprise Data Graph holds those definitions once, with lineage back to their source, and delivers them to any registry-approved agent through a native MCP server, regardless of which cloud’s registry approved that agent. Context Repos let a team version and certify a piece of business context once and reuse it across frameworks, instead of rebuilding the same definition inside every registry entry that touches it.
Workday’s experience shows what the gap looks like before it’s closed. Joe DosSantos, VP of Enterprise Data and Analytics at Workday, has described how the company’s revenue-analysis agent initially “couldn’t answer one question” because it lacked a translation layer between human language and the structure of the underlying data, before Atlan’s MCP server made Workday’s own shared vocabulary something AI could use directly. At DigiKey, Chief Data and Analytics Officer Sridher Arumugham put the distinction between a catalog entry and governed context this way: Atlan is “much more than a catalog of catalogs. It’s more of a context operating system,” one that activates metadata for everything from marketplace discovery to an MCP server delivering context to AI models, a scope no single registry entry would capture. In Atlan’s AI Labs testing, grounding agents in governed context instead of raw schema produced a 38% improvement in text-to-SQL accuracy, across 174 queries and 522 evaluations.
Why the registry question and the meaning question need separate answers
Permalink to “Why the registry question and the meaning question need separate answers”“Which agent registry should we use” is the wrong single question for any enterprise running more than one cloud, because the honest answer is more than one, and that isn’t a failure to fix with better vendor selection. AWS, Microsoft, Google, and MuleSoft each answer “what agents exist here, and can this one run” for their own platform, and a multicloud estate needs all four answers, not a universal fifth one. The question a registry was never built to answer, “does this approved agent still know what’s true,” needs a layer that travels with the agent across whichever registry approved it. That’s the practical shape of building AI agent governance for a real, multicloud estate: keep the registry for identity and approval, and add a shared context layer underneath it so registry-approved agents on different clouds reason from the same certified answers. The next two pages in this series work through the mechanics: how to govern AI agents across multiple clouds and whether agent registries need a context layer.
FAQs about AI agent registries
Permalink to “FAQs about AI agent registries”1. What is an AI agent registry?
Permalink to “1. What is an AI agent registry?”An AI agent registry is a governed catalog that records which agents, tools, skills, and MCP servers exist in an organization, along with each one’s owner, version, and approval status. AWS Agent Registry, Microsoft’s Agent 365, Google’s Gemini Enterprise Agent Platform registry, and MuleSoft’s Agent Fabric are the four major examples that reached general availability in 2026.
2. What is the difference between an agent registry and an AI registry?
Permalink to “2. What is the difference between an agent registry and an AI registry?”An agent registry is an operational catalog for discovering and approving agents, tools, and MCP servers. An AI registry is a regulatory inventory covering every AI system a company runs, including purchased models and vendor features, built to satisfy EU AI Act, NIST AI RMF, and ISO/IEC 42001 audit requirements rather than developer discovery.
3. What is the difference between an agent registry and an agent skills registry?
Permalink to “3. What is the difference between an agent registry and an agent skills registry?”An agent skills registry only catalogs skill packages, covering how they’re published, versioned, and scanned for trust. An agent registry is broader: it catalogs agents, tools, skills, and MCP servers together as one operational inventory, of which the skills registry is one narrower slice.
4. Do I need an agent registry if I only use one cloud platform?
Permalink to “4. Do I need an agent registry if I only use one cloud platform?”Yes, if you’re running more than a handful of agents. A single-cloud registry still solves the core discovery and approval problem: without one, teams rebuild agents and tools that already exist elsewhere in the organization, the exact pattern Southwest Airlines and Syngenta both cite as their reason for adopting AWS Agent Registry.
5. Does an agent registry stop agent sprawl?
Permalink to “5. Does an agent registry stop agent sprawl?”It stops the identity half of agent sprawl: ungoverned, undiscovered, or duplicated agents. It doesn’t stop the context half, where registered and approved agents still build isolated, conflicting understandings of the business, because a registry entry doesn’t audit the business logic inside the artifact it approves.
6. Can one agent registry cover a multicloud enterprise?
Permalink to “6. Can one agent registry cover a multicloud enterprise?”Not currently, based on evidence from actual deployments rather than vendor roadmaps. AWS, Microsoft, Google, and MuleSoft each ship a registry scoped to their own platform, and none of the four registries fully interoperate with the others, so a multicloud enterprise ends up managing more than one registry rather than choosing a single universal one.
Sources
Permalink to “Sources”- Manage Agents, Tools, and Skills at Scale With AWS Agent Registry. AWS. https://aws.amazon.com/blogs/machine-learning/manage-agents-tools-and-skills-at-scale-with-aws-agent-registry/
- Gartner Identifies Six Steps to Manage Artificial Intelligence Agent Sprawl. Gartner. https://www.gartner.com/en/newsroom/press-releases/2026-04-28-gartner-identifies-six-steps-to-manage-artificial-intelligence-agent-sprawl
- Agent Registries Become the New Battleground for Cloud Giants. Forbes, Janakiram MSV. https://www.forbes.com/sites/janakirammsv/2026/04/10/agent-registries-become-the-new-battleground-for-cloud-giants/
- AWS Launches Agent Registry in Preview to Govern AI Agent Sprawl Across Enterprises. InfoQ, Steef-Jan Wiggers. https://www.infoq.com/news/2026/04/aws-agent-registry-preview/
- Microsoft Agent 365 Overview. Microsoft Learn. https://learn.microsoft.com/microsoft-agent-365/overview
- MuleSoft Launches Agent Fabric to Tackle Agent Sprawl and Unify Enterprise AI Workflows. CIO. https://www.cio.com/article/4063090/mulesoft-launches-agent-fabric-to-tackle-agent-sprawl-and-unify-enterprise-ai-workflows.html
- Introducing Gemini Enterprise Agent Platform. Google Cloud Blog. https://cloud.google.com/blog/products/ai-machine-learning/introducing-gemini-enterprise-agent-platform
- Why AI Agents Need an Enterprise Context Layer. Atlan. https://atlan.com/know/why-ai-agents-need-an-enterprise-context-layer/
- EU AI Act: First Regulation on Artificial Intelligence. European Parliament. https://www.europarl.europa.eu/topics/en/article/20230601STO93804/eu-ai-act-first-regulation-on-artificial-intelligence
- AI Risk Management Framework. NIST. https://www.nist.gov/itl/ai-risk-management-framework
