A remote agent can answer a question correctly in a demo and still fail its user in production. The boundary must carry the requester’s authority, the evidence behind the answer, and an intelligible account of what happened when the work did not finish.
On August 26, Eon reported three failures: a non-streaming request hit a 60-second gateway timeout; remote errors disappeared from the orchestrator’s input; and remote history exhausted its context window. Eon also added requester identity and a DataContext provenance envelope. Its deployment used A2A 0.3; the post discusses v1.0 too. Eon’s production report on AAIF.
A timeout leaves the work’s outcome unresolved
Consider a hypothetical operations assistant asked to inspect a large backup inventory. The specialist takes ninety seconds to finish, while a gateway closes the request sooner. The assistant can observe the connection failure without knowing whether the specialist has stopped, is still working, or has already produced a result elsewhere.
Streaming progress can help with an idle timeout if events arrive before the relevant deadline. It cannot remove an absolute gateway deadline or guarantee that a task completes. A useful integration separately defines how long to wait for activity, how long the job may run, and how to retrieve its status after losing the connection.
Retrying needs a decision about the original operation. Repeating a read-only inspection may waste resources; repeating an operation that changes retention settings can have a different consequence. The coordinator should identify the task or business operation and resolve its previous outcome before issuing a duplicate with side effects. These are our operational recommendations, not results from an Eon test.
An invisible error changes the meaning of an answer
Suppose the specialist fails to inspect one storage account. If the coordinator receives only the successful accounts, it may answer “everything looks healthy.” The missing failure has changed a partial check into an apparent complete check.
| Observed state | Answer supported by that state |
|---|---|
| Task accepted | The check has been requested |
| Progress received | The check is running |
| Connection lost | The outcome needs to be resolved |
| One account failed inspection | The overall result is incomplete |
| All required results validated | The specified check is complete |
Our proposed adapter preserves a structured failure for software and a concise description for the coordinating model. It identifies the affected task, the scope left unchecked, and the next allowed action. A later successful retry should supersede that failure in the relevant task state, so an old error does not become a permanent fact about the service.
Carry identity through a verified channel
Eon’s custom requester encoding in context_id assumes control of both ends. Deployment-specific identity handling. A caller-supplied string naming a user does not, by itself, prove that the caller may act for that person.
In our backup example, the receiving service should bind the task to a verified caller and apply the relevant user or tenant policy before reading data. Authentication at the A2A endpoint and authorization for the downstream storage system are separate decisions. The A2A v1.0 specification describes security mechanisms and task lifecycles; the application still has to implement its access policy.
Preserve evidence when a conversation starts over
A new remote conversation may solve a context-capacity problem while discarding facts that matter to the task. Our proposed recovery record would retain the verified principal, task scope, outstanding actions, and references to previously obtained evidence. It would re-check current permission before resuming work. Copying the entire old transcript can simply reproduce the capacity problem.
Evidence needs its own lifetime too. If a specialist reports that eighteen backups require review, a reviewer needs to know the inventory snapshot, the definition of “requires review,” and which accounts were included. A numeric answer can remain in a summary long after the underlying data changes.
For routine browsing, displaying text while marking its evidence as unavailable may be acceptable. For an automated deletion or compliance decision, missing evidence may require pausing the action. The policy should set that consequence explicitly; a parser silently dropping metadata should not determine it by accident.
This follows the permission chain in our Microsoft A2A explainer through a production workflow. For AgentCollusion, the question is whether the next agent receives enough reliable context to check the previous one. Successful message delivery is only one part of that evidence.
Sources checked September 7, 2026. The examples and proposed evaluations identified in this article are AgentCollusion’s analysis; they are not additional experimental results.
