Suppose one agent sends another a simple request: update a file, run a check, and return the result.
The message arrives. The receiver can parse it. The transport worked.
Before allowing the receiver to act, I would want answers to a different set of questions. Who is asking? What authority moved with the request? Which task does it belong to? How far does that authority reach? What happens if the work has to stop? What evidence will come back?
Once the request can cause consequential work, it has become a delegation event.
That does not mean every inter-agent message carries the same authority. A status update may be data. A question may be read-only. But a request that can call tools, change files, spend money, create records, trigger another agent, or alter external state crosses a different boundary. Delivery is now only one part of the contract.
Transport gets the request there
The A2A 1.0 specification is useful because it makes several layers explicit. It separates a canonical data model and abstract operations from concrete protocol bindings, and it defines concepts for agent discovery, messages, tasks, task state, artifacts, errors, security, and cancellation.
Those are meaningful protocol primitives. They still do not answer every application-level authority question.
A system can authenticate an agent and still need to decide what that agent may ask another agent to do. It can authorize access to a task and still need to decide whether a human ever delegated permission to merge code, publish content, spend money, or modify production state. It can return a successful message and still need evidence that the requested effect actually happened.
The protocol can carry the interaction, but the application still has to define the authority behind it.
One implementation makes the hidden contract visible
Claudeway provides a concrete custom implementation example.
Its current repository describes a Slack-to-Claude Code gateway. A separate implementation write-up describes extending that system with a direct inter-agent request path, including local bearer authentication, project-scoped sessions, sender and return-path context, and a read-only default unless broader capability is explicitly granted.
What matters here is how quickly a "send a message to the other agent" feature turns into questions about identity, scope, session ownership, and return evidence.
The implementation account also kept an important limit visible: its live cross-agent end-to-end test was still pending at publication time. The feature branch described in the write-up was not visible in the current repository branch index used for this analysis, so I am treating the article as Jenil D Gohel's implementation account, not as proof of current-main behavior, A2A compliance, or production reliability.
That qualification matters because the example is useful without needing to stand in for an industry standard.
Identity is not authority
Agent identity is necessary but insufficient.
An Agent Card can expose declared identity and capabilities, while authentication can help establish who or what is on the other side. Authorization controls can determine whether a principal may access a resource or operation. Those are real boundaries.
Delegation adds another question: what was this principal actually entrusted to do on this task?
A coding agent may be allowed to propose a patch without being allowed to merge it. A research agent may be allowed to retrieve sources without being allowed to send an external message. A publishing agent may be allowed to prepare a draft without being allowed to make it public.
The receiver therefore needs more than "this request came from a valid agent." It needs enough context to resolve the requested effect against the authority that was granted.
That is an application decision. A2A can provide interoperable identity, task, security, and lifecycle primitives; it cannot know which human or organizational decision made a particular downstream effect legitimate.
A related boundary appears in Capability Needed a Containment Contract: capability describes what a runtime can attempt, while surrounding controls determine which effects it can actually produce. Delegation has to line up with that effect boundary rather than assuming that a valid sender may exercise every available capability.
A request needs a task, not only a reply
The moment work can outlive one synchronous exchange, a plain request-response mental model starts losing information.
A2A treats tasks as first-class objects with lifecycle state rather than reducing every interaction to one message and one answer. That is the right shape for consequential delegated work because the operator may need to ask which request a result belongs to, whether work is still active, what artifacts were produced, or what happened after a reconnect.
The task identity matters for another reason: authority needs somewhere to attach.
If an agent is authorized to perform one bounded task, that does not automatically authorize every later request in the same conversation or every operation available to the same receiver. A task gives the system a concrete unit against which scope, status, evidence, and termination can be checked.
Without that correlation, conversational continuity can quietly become authority continuity even though the two are not equivalent.
Cancellation is not the same as revocation
A2A includes cancellation as part of task lifecycle. That is useful, but a cancellation attempt is not evidence that every downstream effect has stopped.
A queued operation may already have been accepted. A child process may still be running. A credential may remain valid. An external system may have crossed a state boundary before the cancellation reached it.
This is where delegation semantics have to meet containment and revocation semantics. The system needs to know what "stop" is supposed to revoke: local execution, queued work, tool access, temporary credentials, callbacks, child sessions, or some combination of them.
Sometimes the honest state will be "cancellation requested; external effect not yet established." That is less satisfying than a clean stopped/running switch, and much more useful.
Failure needs semantics the caller can act on
"Failed" is also too coarse when one agent is deciding what to do next.
There is a meaningful difference between a request that was rejected because the sender lacked authority, a task that could not start because a dependency was unavailable, a task that partially completed, a transport failure where execution state is unknown, and a completed task whose returned artifact failed validation.
Those states imply different recovery behavior.
Retrying an authorization failure is usually not the same operation as retrying a transient transport failure. Retrying after an unknown external effect can be dangerous if the action is not idempotent. Treating a partial result as total failure can discard evidence the caller still needs.
The interface does not need one universal error taxonomy for every product. What it does need is enough failure information that the next action is not based on a guess.
Provenance has to come back with the result
The weakest completion message is simply: done.
For low-consequence work, that may be enough. Once the request can change external state, "done" is only a claim unless the interface returns evidence appropriate to the action.
The evidence depends on what was delegated.
A research task can return source references and the exact artifact synthesized from them. A code task can return the exact revision, diff, or pull request that contains the change. A deployment task can return a deployment identity plus the observable status that was checked. A document task can return the exact file identity and current state.
A2A gives useful structure for messages, task state, artifacts, and history. Those objects can carry or point to evidence. They do not automatically prove the human delegation chain that made the action legitimate, and they do not make every returned assertion self-verifying.
That distinction is important because an agent can produce a plausible summary of what it believes happened.
The summary can be useful, but the evidence still has to belong to the effect being claimed.
The delegation contract fits into six questions
I do not think this needs a giant policy language before it becomes useful. The minimum review can be small:
- Who is asking? Resolve the sender or principal well enough for the requested consequence.
- What was delegated? State the allowed action and its scope instead of inheriting every capability the receiver has.
- Which task owns the request? Give authority, status, artifacts, and retries a stable correlation point.
- How does authority end? Define completion, expiry, cancellation, revocation, or another bounded termination condition.
- What happens when the receiver cannot act? Return a failure state that distinguishes rejection, inability, partial completion, and unknown execution where those differences matter.
- What evidence comes back? Match proof to the effect rather than treating a success message as proof by default.
The exact representation can vary. Some systems will carry this in task metadata, some in scoped credentials, some in policy objects, and some across several layers.
The invariant is more important than the envelope: the receiving agent should not have to invent the authority semantics from conversational context.
The protocol boundary should stay visible
As an interoperability protocol, A2A can standardize useful objects and operations for agents that need to discover one another, exchange messages, manage tasks, expose artifacts, report errors, and apply security mechanisms. That makes it part of the solution.
It does not mean the protocol should somehow encode every product's approval chain, every company's delegation policy, or every operator's evidence standard. The application still owns questions such as whether an agent may merge a change, whether a human confirmation is required before money moves, which actions are never delegable, and which evidence is sufficient before another system trusts the result.
Claudeway's custom implementation choices sit on that application side too. They are one concrete agent-to-agent solution described in Jenil D Gohel's implementation account, not a definition of A2A and not proof that A2A itself supplies the same policy.
Keeping those layers separate avoids two opposite mistakes: reducing agent-to-agent work to transport plumbing, or expecting the transport protocol to become the entire governance system.
The message was only the visible part
I care less about whether agent A can technically reach agent B than about whether the handoff preserves the decision that made B's action legitimate.
When the receiver can cause consequential work, the request needs enough structure to answer who delegated what, for which task, under which limits, and against which evidence. Otherwise the interface has moved a payload and left the authority implicit.
A message can be delivered correctly while the delegation contract remains undefined.
// End of transmission. Keep the authority visible. — ZYANE