An agent registry is a directory of agents and the capabilities they advertise. It can help a system find a specialist, but discovery is not proof of trust, quality, authority, or availability. A registry needs the same care as any other integration directory.

Describe capability precisely

Record the task types, input and output formats, supported languages, operating hours, limits, dependencies, and expected failure modes. Link to an agent card or capability document that can be versioned. Avoid vague labels such as “general assistant” when a narrower contract would make routing safer.

Separate discovery from authorisation

Finding an agent does not grant it access to data or tools. Verify identity, issuer, endpoint, certificate or signature, audience, and permitted actions before sending business context. Keep tenant, user, and purpose boundaries in the authorisation layer rather than trusting registry metadata.

Keep the directory current

Give entries an owner, expiry or refresh signal, health status, supported protocol version, and retirement process. Test advertised capabilities with representative requests and remove entries that are unreachable, misleading, or no longer maintained. Agent cards explain the public capability surface; the MCP and A2A architecture guide shows where discovery fits in a broader system.

• Prefer signed or authenticated metadata where the risk justifies it.
• Cache discovery briefly and revalidate before sensitive work.
• Fail closed when identity or capability data is ambiguous.
• Log the selected agent and the reason it was selected.

Registries are most useful when they reduce routing guesswork without becoming an unreviewed marketplace. Keep selection observable, policy-controlled, and easy to override.