AI Agent Registry: Catalog Before You Scale

An AI agent registry is a catalog of the AI agents your company runs: one entry per agent saying what it does, who owns it, what data and tools it can reach, and whether anyone else is supposed to use it. It is the old idea of a service catalog or an asset inventory, applied to the one thing your team is now producing faster than anything else.

Nobody builds a registry on the day they build their first agent, and nobody should. The problem is that the cost of not having one does not arrive gradually. It arrives the week someone rebuilds an agent that already existed, and nobody can prove which of the two is correct.

Arvind Jain, co-founder and CEO of Glean, described the shape of this at a Greylock Change Agents session. His starting observation is that "every software company has also become an agent company". Your CRM ships agents. Your HR system ships agents. Your own engineers ship agents in an afternoon. They come from different vendors, get built in different frameworks, and no single system knows they exist. The short clip cut from that session, on agent discovery, names the consequence directly: once that proliferation happens, "now you have this job of figuring out how to organize."

One clarification before going further, because the term is doing double duty right now. Search for an agent registry today and most of the first page is a cloud vendor's feature: a place inside Google Cloud, AWS or Azure where you register an agent so that platform can host it and route to it. That is a real thing and it is not what this article is about. This is about the organizational artifact: the catalog of every agent your company runs, whoever built it and wherever it runs. No vendor registry will keep that list for you, because none of them can see the others.

That job has a name and a shape, and it is smaller than it sounds.

What an AI agent registry actually does

A registry does three things, and it is worth separating them because most teams only feel the pain of one and then build for all three by accident.

Discovery. Somebody needs an agent that summarizes a customer call. Either they find yours in one search, or they build a second one. The failure mode here is not confusion, it is duplication, and duplication is expensive in a way that compounds: every copy needs its own maintenance, its own evals, and its own security review that it will not get.

Governance. Every agent in the list has a named human owner and a date it was last looked at. This sounds bureaucratic until the first time an agent does something wrong and nobody can say whose it is.

Lifecycle. Agents get built for a launch, a migration, a quarter. Without a registry they do not get turned off, they get forgotten, which is a different and worse state because they are still running with credentials.

Those three jobs are why a registry is not just documentation. Documentation describes what exists. A registry is the system of record for what is allowed to exist.

An agent registry is not a tool registry

This distinction causes more confusion than anything else in this topic, because both are lists, both live in the same part of your stack, and people use the words interchangeably.

A tool registry is a library of functions an agent can call: run a report, post a journal entry, schedule the office hours. It answers the question of what an agent is able to do here. That is a real and separate build, and I covered it in internal AI infrastructure for startups, where Y Combinator's own internal tool registry grew past 350 tools and stayed usable only because the team kept it deliberately non-overlapping.

An agent registry lists the agents. It answers a different question: which agents exist, who owns each one, and which is the right one to use.

You want both, and they connect in one direction: an agent's registry entry names the tools that agent is allowed to call. That link is what turns two lists into a permissions model. When they fail, they fail differently. A messy tool registry gives your agents ten overlapping ways to do one thing. A missing agent registry gives you ten agents with no owner.

When a startup actually needs one

Not at one agent. Usually around five, and the trigger is a moment rather than a number: the first time someone on your team builds an agent that already existed, or asks in Slack whether one exists and gets no answer.

The ceiling on the other end is closer than founders expect. Jain describes companies already running agents in the thousands, with around eight near-identical ones competing for a single task, and his conclusion is that the right strategy will require a good amount of curation. What that sprawl costs on the discovery side is covered in agent experience, and the context version of the same argument, why ten thinly-fed agents lose to two well-fed ones, is in context engineering for AI agents. The registry is the mechanical half of that fix.

For a startup the useful reframe is this: you are not building a registry because you have a lot of agents. You are building it because agents are now cheap enough that you will, and the list is much easier to start at five entries than at fifty.

What goes in one entry

Here is the entry format worth copying. It is deliberately short, because a registry that takes twenty minutes to fill in is a registry that goes stale.

• Name and one-line purpose. Written for the person searching, not the person who built it. Summarizes support calls into a ticket note beats support-agent-v2.
• Owner. A named person, not a team. Teams do not answer pages.
• Status. Draft, approved, or deprecated. Only approved agents show up in the default search.
• Trigger. Who or what invokes it: a person, a schedule, another agent, a webhook.
• Inputs and outputs. What it expects and what it returns, in one line each.
• Tools and scopes. The specific tools it may call, and with what permission level.
• Data it can read, and data it can write. Keep these as two fields. The read list is a privacy question and the write list is a blast-radius question.
• Model and framework. So that when a model is deprecated you can find everything affected with one query.
• Human in the loop. Yes or no, and at which step.
• Evals. A link to its test set and the last score, with a date.
• Last reviewed. A date. Empty for six months is itself a finding.
• Retirement condition. The circumstance under which this agent should be switched off.

The two fields teams skip are owner and retirement condition, and they are the two that decide whether the registry is still true a year from now. An entry without an owner is a rumor. An entry without a retirement condition is permanent by default, which is how you end up with an agent running against a data source that was decommissioned last spring.

If you want the evals field to mean something rather than being a link nobody clicks, the discipline behind it is in LLM evals for founders.

The open protocols already wrote your schema

You do not have to invent the format. Two open standards have already solved the public version of this problem, and both are now governed under the Linux Foundation's Agentic AI Foundation, announced in December 2025 with founding contributions from Anthropic, Block, and OpenAI, and which Google's A2A protocol joined in August 2026.

The A2A Agent Card is the closest thing to a finished answer. The A2A specification defines it as a JSON document that works as an agent's digital business card, carrying its identity (name, description, provider), its service endpoint URL, its capabilities, the authentication schemes it requires, and a list of skills, each with an id, a description, input and output modes, and examples. Agents publish it at a standard path on their own domain, /.well-known/agent-card.json, so a client can fetch it before deciding whether to send work.

Read that field list again next to the entry format above. It is nearly the same list, which is a good sign: two groups solving the same problem independently landed in the same place.

More useful still, the same specification describes exactly the thing this article is about. Alongside the well-known URI, it names curated registries, or catalog-based discovery, as the pattern for enterprise environments: a central service holds a collection of agent cards, agents publish to it, and clients query it by skill or tag rather than guessing at domains.

The official MCP Registry is the other half of the picture. Launched in preview in September 2025, it is an open catalog and API at registry.modelcontextprotocol.io that acts as a single source of truth for publicly available MCP servers, with an open OpenAPI specification so anyone can build a compatible sub-registry. The detail that matters for a startup is in the announcement itself: organizations can run private sub-registries. The pattern is explicitly meant to be copied inside a company, not just consumed from outside.

So the practical move is not to design a schema. It is to borrow the agent card's fields, add the three your internal registry needs that a public card does not have (owner, status, retirement condition), and move on.

Who gets to publish an agent to the registry

A registry with no editorial policy becomes a junk drawer within a quarter. The approach Jain sees enterprises taking is deliberately lightweight: anyone may build, and a small group decides what gets promoted into the shared, company-wide library. Why that curation step matters more than the building is argued in context engineering for AI agents. What follows is how to actually run it.

That is two tiers rather than a committee. Personal and experimental agents live in the sandbox tier with no approval required and no promise to anyone. The published tier has a bar. A workable bar for a startup is four questions:

1. Does this duplicate something already in the registry? If yes, improve that one instead.
2. Does it have an owner who will still be here next quarter?
3. Has it been run against a real eval set, with the score written down?
4. Does its tool and data access match what its job actually needs, and nothing more?

Two people can run this in fifteen minutes a week. The value is not the gate itself, it is that question one gets asked at all, because nobody building the duplicate agent ever thinks to ask it.

There is a second-order benefit that came up in that same conversation and is easy to miss. Left alone, someone handed the job of building an agent will most likely just replicate the work as it is done today, which means you automate the current process instead of improving it. A review step is the natural place to catch that, because the reviewer is not the person attached to the existing workflow.

Your registry is a security inventory

As a CISSP, this is the part I would build first, and it is the argument that usually gets a registry funded when the discovery argument does not.

Every security framework starts in the same place: you cannot protect what you have not inventoried. Agents are the fastest-growing category of privileged non-human identity most companies have ever had, and in most companies the list of them does not exist in any system. That is the definition of shadow IT, with the difference that these particular shadows hold credentials and take actions.

What the registry buys you, concretely:

• One identity per agent. No agent borrows a human's session and no two agents share a service account, so the audit log can name which agent did a thing. Identity providers have started shipping this as a first-class object, including Microsoft Entra Agent ID, which gives agents their own identities under the same lifecycle and access governance as everything else in the directory.
• Least privilege you can audit. The tools-and-scopes field is not documentation, it is the intended state. Once a quarter, diff it against what those credentials can actually reach. The gap is your finding.
• A reconciliation loop. Pull the list of non-human identities from your identity provider and diff it against the registry. Anything in the directory but not in the registry is an unapproved agent. This single query is the highest-value thing on this page.
• Deprovisioning that happens. Retirement condition plus owner means an agent can actually be switched off, and its credentials revoked, by someone who knows why it existed.
• A blast-radius answer. When a model, a vendor, or a tool turns out to have a problem, finding which of your agents touch it should be a filter, not an investigation.

The human-in-the-loop field earns its place here too. Where to set that dial per agent, and why the operators on that Greylock panel keep a human in front of anything that mutates real state, is argued in context engineering for AI agents. The registry's contribution is narrower and easy to underrate: it turns that decision into a recorded, checkable property of each agent instead of a habit that quietly erodes as the team grows. Where the whole posture fits into an audit is covered in AI compliance for startups.

Start with a spreadsheet, not a platform

There is a fast-growing market of agent governance and registry products, and most of what you will find searching this term is one of them. A startup does not need one yet, and buying one early tends to produce an empty, expensive tool.

Start with a spreadsheet or a markdown file in the repo, with the fields above as columns. Two properties matter more than the format: it lives where your team already works, and updating it is part of shipping an agent rather than a separate chore. If the registry lives somewhere people have to remember to visit, it is already out of date.

Make it machine-readable as soon as it is boring to maintain. A JSON or YAML file in version control gives you three things a spreadsheet does not: the orchestrator can read it at runtime to decide which agent to invoke, code review becomes the approval workflow, and git history gives you the audit trail for free. That runtime use is the bridge to AI agent orchestration, because an orchestrator can only route to agents it knows about, and the registry is how it knows.

The graduation point to a real platform is when you need per-agent identity issuance, policy enforcement, and runtime telemetry tied together. That is a real threshold, and most startups are nowhere near it. Being able to say what you run, who owns it, and what it can reach already puts you ahead of most companies with a procurement budget.

What to do this week

• Write down every agent your company runs. Include the vendor ones, the ones inside your SaaS tools, and the personal ones on people's laptops. Expect the list to be longer than you guessed.
• Give every entry an owner with a name. Any agent you cannot assign to a person is your first candidate for deletion.
• Add two columns most teams forget: what data it can write, and the condition under which it gets retired.
• Pull the non-human identities from your identity provider and diff them against your list. Investigate everything that appears in one and not the other.
• Split the list into two tiers, sandbox and published, and put a four-question bar in front of the published tier. Start the review this week, with two people, at fifteen minutes.
• Copy the A2A agent card field list rather than designing your own schema, and add owner, status, and retirement condition.
• Set a recurring calendar item to review every entry whose last-reviewed date is over ninety days old.

The wider map of how agents, context, and governance fit together for a startup is in AI for startups. If you want this as an operating system rather than a set of habits, from product decisions through engineering and security, that is what I teach in AI Operating System for Startups.

The registry is not the interesting part of building with agents. It is the part that decides whether the interesting parts compound or just pile up.

Sources

• Fixing the AI Agent Discovery Problem (Greylock), the clip this article distills, on the organizing problem created by agent proliferation.
• The Enterprise Brain for AI Agents with Glean and Cresta (Greylock Change Agents), the full session that clip is cut from, and the source for the agent-company observation and the curation and approval material.
• Agent Discovery in A2A, the A2A protocol documentation, for the agent card's fields, the well-known URI, and the curated registry pattern.
• Introducing the MCP Registry (Model Context Protocol blog), for the official registry's launch, its role as a source of truth, and public and private sub-registries.
• Linux Foundation Announces the Formation of the Agentic AI Foundation and Google's A2A protocol gets a new home (Axios), for the governance of both protocols.
• What is Microsoft Entra Agent ID? (Microsoft Learn), for purpose-built agent identities and their governance.
• Profile: Arvind Jain, co-founder and CEO of Glean.