Building an Agent Registry for the Agentic OS

A multi-agent system without a registry is chaos. Every agent needs to know what other agents exist, what capabilities they expose, what versions are current, and how to reach them. This is the problem Trove solves.

Why a registry?

In the AnankeOS ecosystem, agents are not monolithic. They are composable units — you wire them together like functions in a distributed program. Without a registry:

• Discovering an agent means hardcoding endpoints
• Updating an agent breaks every consumer
• No visibility into which agents are alive, deprecated, or compromised

Trove acts as the single source of truth for agent metadata.

Design decisions

Schema-first. Every agent publishes a manifest: capabilities, I/O schema, dependencies, health endpoint, version. The registry validates manifests on publish and rejects malformed ones before they pollute the system.

Versioned, not overwritten. Publishing to the same agent name creates a new version entry. Consumers pin to a semver range — ^1.2 — and the registry resolves the best matching version at connection time.

Pull-based discovery. Agents don’t push heartbeats. Consumers poll the registry for changes. This keeps the registry stateless and horizontally scalable — no WebSocket fan-out, no persistent connections to manage.

The data model

AgentManifest {
  name: string
  version: semver
  capabilities: string[]
  dependencies: { agent: string, range: string }[]
  endpoints: { protocol: string, url: string }[]
  schemas: { input?: JSONSchema, output?: JSONSchema }
}

The registry indexes by name, capability, and dependency. A query like “find all agents that expose text_embedding and depend on llm_core ^2” resolves in a single index scan.

What’s next

The registry is live in the AnankeOS dev environment. Current work is on federation — linking registries across trust boundaries so agents in different security domains can discover each other through controlled gateways.

Trove is open source. GitHub: @ezraphm/trove