Agent Capability Manifest

Problem

Hardcoding which agent does what, where it lives, and how to authenticate couples every caller to every callee: when an agent changes its skills, endpoint, or auth, every caller breaks until it is updated by hand. Embedding the same facts in a central configuration moves the coupling but not the brittleness. And when agents come from different vendors, there is no shared way to even express what an agent offers, so integration is bespoke per pair. Without a common, machine-readable self-description, discovery is manual and binding is rigid.

Solution

Define a standard schema for an agent's self-description — identity, skills or capabilities, service endpoint, supported protocols, and authentication requirements — and have each agent serve it as a machine-readable manifest at a well-known, discoverable location. Callers and registries fetch the manifest to learn what the agent can do and how to reach it, then bind by capability rather than by hardcoded address. The manifest is versioned so consumers can detect change, and because the format is shared, agents from different vendors interoperate without bespoke per-pair integration. A registry can aggregate many manifests; a peer can also fetch one directly.

When to use

• Agents from different teams or vendors must discover and call each other.
• Callers should bind to agents by capability at runtime, not by hardcoded address.
• Agent endpoints, skills, or auth change often enough that hardcoding is brittle.
• A registry or peer-to-peer discovery layer consumes agent descriptions.