The most useful way to understand agent-to-agent systems is as task handoff. Agents pass work, context and responsibility between them. The receiving agent needs to understand what has already happened, what remains unresolved, and what it is expected to do next.
That can take several forms. Two agents might work through a problem in dialogue. A software team might pass requirements, designs and code between specialised roles. Agents from separate organisations might exchange requests while keeping their tools and internal records private. Each arrangement makes different assumptions about what can be shared and who has authority to act. 1
There is also a distinction between collaboration and its infrastructure. Here, agent-to-agent describes agents coordinating work. The Agent2Agent (A2A) protocol provides a standard interface for discovering capabilities and exchanging tasks and results across systems. A protocol connection still needs a workflow that gives those exchanges a purpose. 2
Consider a checkout service that sometimes creates duplicate orders when a payment request is retried. We want an agent system to reproduce the bug, identify its cause, implement a fix and demonstrate that legitimate new purchases still work. We’ll use this illustrative example throughout the post.
“Fix checkout” leaves too much open. A useful assignment includes the starting state, the constraints and a completion condition. The same purchase retried must produce one order, distinct purchases must remain distinct, concurrent requests must be covered. Those conditions let another agent assess the work without guessing what the original requester meant.
The task then has a dependency structure. Inspecting application logs and checking the payment provider’s retry behaviour can happen concurrently. Implementing the fix depends on the findings. Reviewing the fix depends on having a patch and a way to reproduce the original failure.
This is where multiple agents might earn their cost. Independent investigations can run in parallel and return focused findings. A tightly coupled sequence, where each step needs the full context of the previous one, can instead create repeated explanations and waiting. Research comparing single-agent and multi-agent approaches finds that this distinction affects which arrangement performs better on its tested long-horizon tasks. 3
Access also shapes the task. An internal agent might see our order database while a provider’s agent sees payment-processing records. Neither has the whole picture. They need to exchange enough evidence to connect the two views. Benchmarks that distribute information between agents test this requirement more directly than tasks where every participant receives everything upfront. 4
A role gives an agent a defined contribution. For checkout, a possible team is:
Each role needs inputs, tools, an expected output and limits on its authority. The investigator may need read access to production logs. The implementer needs permission to change code in a development environment. The reviewer needs the original requirements and execution evidence. Permission to propose a patch does not automatically include permission to deploy it.
These agents can use the same underlying model. Their specialisation can come from different context, tools and instructions. Giving an agent a title is only the beginning. A reviewer that sees only the implementer’s confident summary has little basis for checking the implementation.
There are two useful ways to organise their work. Agents can discuss an uncertain problem until they have enough detail to proceed, or exchange a defined deliverable that the next role consumes. CAMEL makes role-based dialogue explicit; ChatDev places dialogues within stages of software development; MetaGPT emphasises structured requirements and design artifacts. These are examples of choices we can combine in our own workflow. 5, 6, 7
For checkout, discussion is useful while investigating an ambiguous failure. Once the cause is understood, a reproduction and a patch give the reviewer something concrete to inspect.
Across organisations, a role also identifies whose interests the agent represents. A payment provider’s agent may help investigate an incident while being unable to disclose another customer’s records. Its instructions, evidence and permissions remain separate from ours. Studies of agents with private environments show why evaluating that boundary requires attention to each participant’s obligations. 8
“I fixed the retries” is a poor handoff. The reviewer still needs to know what changed, which version was tested, and what remains uncertain. A more useful handoff might look like this:
task: prevent duplicate orders on payment retry
revision: checkout-fix-03
finding: retry path creates a new order before checking the request key
artifact: checkout-fix.patch
checks:
- same key retried: one order
- different keys: separate orders
unresolved:
- concurrent retries have not been tested
requested_next_step: review concurrency handlingThis is an illustrative format. In a running system, the patch and test results need to be retrievable and tied to the stated revision. The unresolved item tells the reviewer where the evidence stops and further work begins.
The handoff should preserve the context needed for the next decision. Sending the entire conversation can bury a critical constraint among discarded ideas. Sending a short conclusion can lose the observation that supports it. A useful middle ground is a focused summary with links to the underlying evidence, plus explicit constraints and open questions.
A structured artifact helps when the receiver expects particular fields, such as an interface definition or a list of tests. Dialogue helps when the receiver needs clarification. Our reviewer could ask, “Do these results include two retries arriving at the same time?” The answer can change the next action from accepting the patch to investigating a race condition. Structured documents and iterative conversation can serve different parts of the same handoff. 6, 7
Information can also outlive the current team. A shared store of previous task trajectories could help a later investigator find a similar retry bug. Retrieval then becomes another form of exchange, with its own question. Does this earlier solution apply to the current system? Multi-Agent Transactive Memory explores this reuse across agent populations. 9
Uncertainty belongs in the handoff too. “Concurrent retries have not been tested” is actionable. A confidence score needs additional care. Its usefulness depends on whether it predicts correctness and whether the receiver knows how to use it. Research on calibrated confidence trains both the signal and its downstream use. An arbitrary percentage in a message provides neither property by itself. 10
Some experimental systems exchange internal model representations rather than readable text, including latent working memory and compressed latent information. This changes the representation and inspection of a handoff and requires suitable access to model internals. It is a separate engineering choice from connecting independently hosted services through a message protocol. 11, 12
Service boundaries introduce delivery concerns as well. If the provider’s agent is offline, who retains our request? Can a replacement instance resume the exchange? Agent Transfer Protocol explores stable logical addresses and domain servers that store messages for later retrieval. Its prototype demonstrates continuity in a controlled workflow; the application still has to decide whether a received answer resolves the task. 27
A message can therefore succeed at one layer and fail at another. It arrives intact, matches the schema but leaves “retry handled” ambiguous. Clarification establishes what was actually checked. Source verification establishes where a message came from; factual verification checks its claims; authorisation determines which actions it may trigger. These are separate responsibilities at a handoff. 13, 14
Suppose the reviewer finds that two concurrent requests can both create an order before either records the request key. Something must turn that finding into another action.
In a simple coordinated workflow, the sequence could be:
The message has changed the state of the work. Responsibility for the next action is explicit, and a successful delivery is distinguishable from an accepted result.
A fixed workflow can encode those transitions directly. A conversation-driven workflow can let a reply trigger tool execution or another exchange. Code goes to an execution agent, its traceback returns to the implementer, and the implementer revises it. AutoGen makes this combination of conversation, computation and programmed control explicit. 15
The controller can also adapt. It might select another specialist based on the current task state or estimated capability, or let agents route work through a network. Previous successful handoffs can inform later plans. Research explores learned central selection, competence-aware participation, decentralised routing and historical workflow priors. Each places the decision about who acts next in a different part of the system. 16, 17, 18, 19
For our checkout task, explicit dependencies and a bounded revision loop are a reasonable starting point. The important decisions are already visible; who can reject a result, who can request more evidence, what happens when a peer does not respond, and what ends the run. A more adaptive controller is worth testing when this arrangement has a measurable limitation.
The team is finished when the checkout behaviour meets the requirements. Agreement between the agents is one observation; a reproducible concurrency test is evidence about the service.
Evaluate the original failure, sequential retries, concurrent retries and distinct purchases. Track intermediate milestones too. Was the reproduction valid, did the implementer use the investigator’s finding and did the reviewer check the final revision? A plausible explanation attached to an incorrect patch should remain a failed run.
Then compare against a capable single agent with the same tools, evidence access and a comparable budget, including opportunities to inspect its work and retry. For private-information tasks, preserve the access boundaries. A single agent granted everyone’s private records represents a different deployment condition.
Three further comparisons help explain any improvement.
Generating and combining answers can improve response quality in evaluated settings, as Mixture-of-Agents demonstrates. That is a useful baseline for separating the value of multiple proposals from the value of an ongoing team workflow. Also check whether later interaction preserves the strongest proposal. MASTraceBench finds cases where strong initial answers regress during collaboration. 20, 21
For interactive tasks, progress includes the agents’ actions in the environment. Did they divide the work, exchange missing information and adjust to each other’s actions? Benchmarks such as Collab-Overcooked and MASBench make those coordination demands part of the evaluation. 22, 4
When the checkout team fails, retain enough evidence to identify where the handoff broke. Perhaps the investigator omitted a constraint, the implementer ignored it, or the reviewer checked an earlier revision. Failure studies distinguish workflow-design problems, inter-agent misalignment and inadequate verification, and investigate which agent and step introduced a decisive error. Those distinctions help turn an unsuccessful run into a specific fix to the system. 23, 24
Test recovery as well as clean exchanges. Give an agent an incomplete result, an answer to the wrong question, or a missing response. Does it identify the gap and ask a useful follow-up, or continue as though the dependency were satisfied? UnCoBench evaluates these unreliable-colleague conditions. 25
Record the cost of getting to the result: elapsed time, tokens, tool calls, repeated work and human intervention. Measure factual reliability separately from task success, too. A study of clinical tasks found that improved task performance did not reliably come with reduced hallucination in the generated rationales. Across organisational boundaries, check each agent’s obligations as well as the shared outcome. 26, 8
For checkout, the useful result is a verified fix whose time and cost justify the arrangement. Every extra agent should have a contribution we can identify, a handoff the next agent can use, and an outcome we can check.