Why Your AI Agent Framework Needs a Registry, Not a Framework

Every week, a new AI agent framework launches. New abstractions for chaining LLM calls. New ways to define tools. New orchestration patterns. The community celebrates, benchmarks are posted, and everyone migrates their prototypes to the latest thing.

Meanwhile, every enterprise I talk to asks the same question: "We have twelve agents built by three different teams. None of them know about each other. How do we manage this?"

The answer is not another framework. The answer is a registry.

The Framework Trap

Frameworks solve the wrong problem at the wrong layer. When a team builds an AI agent, the framework handles the mechanics: prompt construction, tool dispatch, memory management, LLM API calls. This is important work. But it is build-time work. It ends when the agent is deployed.

The hard problems start after deployment: How many agents do we have? What can each agent do? Which agents are running right now? How do agents relate to each other? Who is responsible for each agent?

These are not framework problems. These are registry problems.

You can see the symptom before you can name the disease. A support team ships a triage agent. Three months later, a separate ops team ships a near-identical triage agent, because nobody knew the first one existed. An incident hits production, and the on-call engineer cannot get a straight answer to "which agents touched this account in the last hour?" A security review asks for a list of every AI agent with write access to customer data, and the honest answer is a shrug. None of this is a framework failure. Every one of those agents was built well. The framework did its job. What was missing was a place to look them up.

This is why "which framework should we standardise on?" is the wrong first question for a platform team to ask. Standardising the build tool does nothing for the lookup problem — you can enforce one framework across the company and still have no idea how many agents exist, because the framework was never designed to answer that question. It was designed to help one team ship one agent.

What Container Registries Taught Us

Container registries (Docker Registry, ECR, GCR, Harbor) solved this by establishing a single source of truth for what exists. Not how to build it — what exists, where it is, what version it is, and what it contains.

The registry did not replace the build tool. Docker builds still used Dockerfiles. But the registry gave the organisation a catalogue — a shared, searchable, versioned record of every deployable unit.

Look at what that catalogue actually made possible. Every image carries a tag and a content-addressed digest, so "which version is live" stops being a question anyone has to ask a person — it is a lookup. Promotion between environments becomes a metadata operation: the same image gets tagged staging, tested, then re-tagged production, rather than rebuilt from scratch at each stage, which removes an entire class of "it worked in staging but broke in prod because the build was slightly different" incidents. Vulnerability scanners plug into the registry once and cover every image that ever passes through it, instead of every team bolting on its own scanning step. And when something goes wrong, the registry's history answers "what was running at 3pm yesterday" without anyone needing to remember or reconstruct it.

None of that came from a better build tool. It came from having one place, external to any single build, that recorded what existed.

This is exactly what AI agents need.

The Agent Registry

An Agent Registry is the authoritative catalogue of every AI agent in your organisation.

1. What agents exist?

Every agent is registered with a unique identifier, a human-readable name, a role description, and a department assignment. The registry is the single source of truth. This sounds obvious until you try to answer "how many agents do we run" without one — most organisations discover the honest answer is "we don't know," because agents get created in a script here, a notebook there, a Slack bot somewhere else, each with no shared record. A registry entry is the difference between an agent existing informally, known only to the person who built it, and existing formally, discoverable by anyone with a reason to look.

2. What can each agent do?

The registry stores the agent tool manifest — the list of tools it is authorised to use, with their schemas. This turns "what could this agent possibly have done" from a forensic exercise into a lookup. When a security review asks which agents can write to the billing database, the manifest answers it directly, instead of someone reading through every agent's source code to find out. The manifest is also what makes least-privilege enforceable at scale: a tool is either on an agent's list or it isn't, and that list is auditable independently of the agent's code.

3. How are agents organised?

Agents work in teams — coordinated groups with a shared task and a coordination pattern. Teams belong to spaces — departmental boundaries that provide scope and access control. This hierarchy matters because "agent sprawl" is really "agent isolation" — dozens of capable agents, each doing useful work, none aware of the others, none composable into a larger workflow. Grouping agents into teams with an explicit coordination pattern is what turns a pile of individually useful agents into a system that can be reasoned about, extended, and handed off between teams without starting from zero.

4. What is the operational status?

Every agent has a lifecycle state: active, paused, shadow, deprecated. The registry tracks when each agent last ran, how long it took, whether it succeeded or failed. This is the operational layer a framework never gives you, because a framework's view ends at deployment. A "shadow" state matters in particular — it lets a new or revised agent run alongside the one it's replacing, observed but not yet acting, so a team can compare behaviour before cutting over. Without a registry, that kind of staged rollout has to be improvised per-agent instead of being a standard lifecycle state everyone understands the same way.

5. Who owns each agent?

The registry associates every agent with an owner, a space, and access controls. When an agent misbehaves, "who owns this" should be a lookup, not an investigation. This is the accountability layer that most AI deployments skip entirely, because nothing forces it to exist — a framework will happily let you ship an agent with no named owner, no documented scope, and no access boundary, and it will run exactly the same either way. A registry makes ownership a required field, not a hoped-for convention.

6. What did each agent actually do?

Beyond current status, the registry is the audit trail: every run, every tool call, every handoff between agents, timestamped and attributable. This is what turns "an agent did something wrong" from a mystery into an investigation with a starting point. When an incident touches a customer account, the registry can answer which agents interacted with that account and in what order — the same question an on-call engineer asks about a service outage, now answerable about an agent workflow instead of being unanswerable by design.

The Three-Level Hierarchy

Level 1: Agents — Individual units of capability. The container image equivalent. Each one does one job well, with a defined tool manifest and a named owner. This is the unit a framework helps you build, and the unit the registry helps you find again six months later.

Level 2: Teams — Coordinated groups with a coordination pattern: Supervisor (80% of enterprise use cases), Pipeline (sequential, deterministic), or Swarm (dynamic peer-to-peer handoffs). A Supervisor pattern suits work where one agent needs to plan and delegate to specialists, then assemble their output — most enterprise workflows fit this shape. A Pipeline suits work with a fixed sequence of steps, each agent handing off to the next, where the order never changes. A Swarm suits work where agents need to negotiate the division of labour dynamically, because the right split isn't known in advance. Picking the wrong pattern for the job is a common early mistake — a Swarm where a Pipeline would do adds coordination overhead with no benefit, and a Pipeline where a Swarm is needed is brittle the moment the task doesn't fit the fixed sequence.

Level 3: Spaces — Department or domain boundaries. The finance space cannot see the HR space agents unless explicitly granted access. This is the access-control layer, and it exists because "every agent in one flat list" breaks down the same way "every employee in one flat org chart with no reporting lines" would. Spaces let each department own its agents, its data boundaries, and its own review process, while the registry still gives the organisation as a whole one place to look up anything, anywhere, that a cross-cutting review needs to see.

What Changes in Practice

The difference shows up first in the moments that used to be improvised. Onboarding a new agent stops being "tell a few people it exists" and becomes registering it, which makes it discoverable by default. A security review stops being a multi-week archaeology project across every team's codebase and becomes a set of registry queries. An incident response stops with "let me go ask around about which agents might have touched this" and starts with a lookup that returns a definitive answer. None of this requires anyone to write a better agent. It requires the organisation to have somewhere to look.

The Uncomfortable Truth

The AI agent ecosystem is infatuated with frameworks because frameworks are fun to build. Registries are not fun. They are infrastructure. They are the boring, essential, unsexy layer that makes everything else work.

But the registry always wins. npm is more durable than any JavaScript framework. Docker Hub outlasted Docker Swarm. The Python Package Index will outlive every ML framework built on top of it. Maven Central has quietly outlasted three generations of Java build tools built on top of it. In every case, the framework layer churns every few years while the registry underneath keeps working, because the registry solves a problem that doesn't go out of fashion: knowing what you have.

If you are building AI agents for your enterprise, stop asking "which framework should we use?" and start asking "where is our registry?"