Agent Architecture and Orchestration
Agent Registry — Stack
Agent registry › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
The question is where lookup data lives, how fresh it has to be, and what breaks when the store that holds it is unavailable.
- Availability coupling. What happens to agent traffic when the catalogue is down. Any design that cannot serve from a local cache has made lookup a single point of failure.
- Query shape. Whether consumers need exact resolution by name, filtering on structured attributes, or similarity search over descriptions. These push toward very different stores.
- Schema discipline. Whether entries are validated on publication or accepted as free-form documents that each consumer parses hopefully.
- Propagation. How a change reaches consumers — push, poll, or cache expiry — and the worst-case staleness that implies for a deprecation or an emergency disable.
- Environment scoping. Whether the same mechanism cleanly separates development, staging, and production, and per-tenant visibility where that applies.
- Authorisation. Whether the store can express and enforce which callers may resolve or invoke which entries, or whether that has to be layered on top.
- Publication audit. Whether there is a record of who published or changed an entry, and whether a bad entry can be rolled back without a deploy.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Static manifest compiled into the build | Small fixed sets where every caller ships together | Changing the set requires redeploying every consumer; cross-team reuse is impossible |
| Configuration service or key-value store with versioned keys | Teams that already run one and want change without redeploy | No schema unless you add one; easy to accumulate entries nobody owns |
| Service registries (Consul, etcd, Kubernetes services and custom resources) | Agents deployed as independent services with health signals already present | Models availability well and capability poorly; descriptive metadata ends up in annotations |
| Internal developer portals and software catalogues (Backstage and similar) | Ownership, lifecycle status, and documentation for humans | Built for people browsing, not for a router resolving an entry on a latency budget |
| MCP server listings and tool discovery | Exposing agents to clients that already speak the protocol | Describes an invocation surface, not fleet-level governance or ownership |
| A2A agent card discovery at a well-known location | Agents that must be found across organisational boundaries | Discovery across a trust boundary needs an identity and verification story you must supply |
| Vector index over entry descriptions | Catalogues large enough that exact-name resolution is not how callers find things | Similarity search returns a plausible neighbour for queries that should have matched nothing |
| Agent platform built-in registries | Fastest path when the whole fleet lives on one platform | Entries are shaped by that platform and do not describe agents running anywhere else |