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.

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.

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.

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.

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.

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.

5. Who owns each agent?

The registry associates every agent with an owner, a space, and access controls.

The Three-Level Hierarchy

Level 1: Agents — Individual units of capability. The container image equivalent.

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).

Level 3: Spaces — Department or domain boundaries. The finance space cannot see the HR space agents unless explicitly granted access.

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.

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