Protocol scope
A2A coordinates work; it does not settle the purchase
Agent2Agent defines a way for independent agent systems to discover capabilities, exchange messages, manage tasks, and return artifacts. In commerce, one agent might request a quote from a specialist, delegate itinerary construction, ask a merchant agent to create an order, or monitor fulfillment. Durable task state is useful because commercial work often outlives one synchronous request.
The protocol does not turn every task into authorized economic action. Agent discovery and authentication can help identify the remote participant, while task messages carry requested work and context. The principal's authority, merchant order, payment credential, rail submission, settlement, and recourse remain separate responsibilities. An A2A task can reference those artifacts, but the payment system must verify them before money moves.
Agent-to-agent delegation can move work across systems. Financial delegation must narrow authority at every hop and remain traceable to the principal.
Carry a verifiable delegation chain with the task
A task should identify the requesting agent, its operator, the represented principal, the purpose, and the authority reference. A downstream agent should receive only the constraints needed for its assigned work. If it creates a further subtask, the derived scope must be equal to or narrower than the upstream mandate: a lower amount, shorter expiry, restricted merchants, or a read-only quote operation. No agent should enlarge authority because a broader capability would make the task easier.
Keep identity and authorization distinct. An Agent Card or authenticated connection can help establish which agent endpoint is involved; it does not prove that the endpoint represents the named principal or can commit funds. Verify issuer, audience, key status, mandate chain, and exact order independently. When a downstream participant cannot validate required evidence, it should return an authorization-required or blocked state rather than asking the model to infer permission from conversation history.
| Artifact | Purpose | Failure if missing |
|---|---|---|
| Principal and operator reference | Names whose interest and system are involved | No accountable owner for the task |
| Mandate chain | Shows bounded delegated authority | Remote agent treats a request as permission |
| Order digest | Binds approval to commercial terms | Price, seller, or items drift between agents |
| Policy decision | Records deterministic allow, deny, or step-up | Downstream execution cannot reproduce authorization |
| Payment and fulfillment references | Connects task outcome to money and delivery | Task completion is mistaken for commercial completion |
Join task state to the financial state machine
A task can be working, waiting for input, completed, failed, canceled, or require authentication while the related payment has a different lifecycle. A completed quote task proves neither payment nor fulfillment. A failed agent response after payment submission may conceal a settled transaction. Keep task, order, authorization, payment, settlement, and fulfillment states separate, then link them with stable identifiers.
Retries must reuse the intended economic action. When a coordinator resends a task, the downstream service should return the prior result for the same semantic request or reject changed terms under the same idempotency key. Cancellation should state what it cancels: future work, an unsubmitted payment, a merchant order, or nothing on the rail. Once value is final, remediation may require a refund or compensating transfer rather than task cancellation.
- Persist the normalized task and financial intent before dispatching remote work.
- Use independent identifiers for task, order, policy decision, payment attempt, and settlement.
- Represent pending and unknown outcomes instead of converting transport failure into payment failure.
- Authenticate push notifications and deduplicate repeated task or payment events.
- Require step-up when a remote agent returns materially different commercial terms.
Make multi-agent accountability inspectable
A multi-agent receipt should record which participant discovered the option, proposed the order, evaluated policy, requested a credential, submitted payment, and observed fulfillment. Preserve messages or canonical digests needed to establish those handoffs without storing unnecessary private conversation. Signatures can protect selected requests, but verification metadata must say which fields were covered, which key was trusted, and whether freshness checks passed.
Operational controls should constrain one participant without disabling the entire network where possible. Revoke an agent key, block a merchant, pause a task class, lower a mandate ceiling, or freeze a signer independently. Incidents still need one end-to-end owner: rotating a remote agent's key does not reverse value, and completing an A2A task does not close a refund. Reconciliation and recourse must resolve the principal's commercial outcome.
- Log delegation, acceptance, sub-delegation, denial, and completion with issuer and timestamps.
- Test confused-deputy, cross-principal, stale-task, replay, and changed-order scenarios.
- Expose human-readable responsibility without presenting agent authentication as user authorization.
- Retain protocol and schema versions so historical artifacts remain interpretable.
Source discipline
Primary sources
Product status and protocol behavior are checked against maintainer documentation. Company sources establish what their organizations publish; they do not independently prove adoption or performance.