A2A Delegation: How Agents Hand Off Work to Each Other

Picture this: A data ingestion agent reads incoming orders every morning, transforms them into a standard format, and passes them to a warehouse agent. Nobody specified what “standard format” means. The warehouse agent interprets it one way, loads the data, and the next morning an accounting agent reports the numbers are wrong. The three agents all executed their code without error. The system did what the code told it to do. But accountability? It vanished somewhere between the three handoffs.

This is not a theoretical problem. In every organization trying to scale agent work, tasks move between agents constantly. Orders flow from intake to fulfillment. Data moves from source to analysis to decision. Questions cascade through a chain of reasoning agents before reaching a human. But if those handoffs are not defined, sooner or later a silent failure will cascade too.

Handoff Without Rules Produces Silent Failures

In a human team, when work moves from one person to another, unspoken rules carry the flow:

• The receiver knows roughly what good work looks like.
• If it’s wrong, they send it back.
• If they’re unsure, they ask.
• Accountability is mutual peer pressure: nobody wants their name on bad work.

Agents have no peer pressure. They don’t care. Code that says “accept this input and process it” will accept it, even if the input is half-broken. The agent will produce output. The output will move downstream. Nobody stops the flow until a human notices something is wrong.

To prevent this, handoffs between agents must become explicit contracts.

When agent A hands work to agent B, the contract must specify:

1. What done looks like. A list of checks, not a feeling. “Contains all required fields.” “Timestamp is within the last hour.” “Character encoding is UTF-8, not Latin-1.”
2. What failure looks like. When should agent B reject the input and return it? When should it log and escalate? When should it pause the whole flow?
3. Who approves the output. Does agent B’s output go straight to agent C, or does a verification agent inspect it first?

Without these three, what you have is not A2A delegation. You have agents working in the dark, passing broken things along, and blaming each other when the final output is garbage.

Approval Chains Stop Problems Early

Here is a realistic flow:

1. Ingestion agent reads raw order data and transforms it.
2. Format validator checks that the transformed data matches the schema. If not, it rejects the batch and logs the error. No more downstream movement.
3. Warehouse agent receives only validated data. It loads it.
4. Audit agent independently reads what the warehouse agent wrote and compares it to the input. If numbers don’t match, it raises an alert.
5. Human observer receives alerts and investigates.

Each agent in this chain has a single job. The chain is linear. Problems surface at step 2, not at step 5 when it’s too late to fix.

But building this chain is not automatic. You have to define it. You have to code it. You have to log every step. You have to alert when a step fails.

Accountability Doesn’t Spread; It Concentrates

Here is a mistake that many teams make: They assume that because three agents are involved, accountability spreads. “Well, the data agent might have sent bad data, or the warehouse agent might have loaded it wrong, or the audit agent might have missed it.”

Wrong. Accountability concentrates.

If the data agent’s job is to transform order data correctly, and it sends bad data downstream, it is responsible. Even if the warehouse agent also fails to catch it.

If the warehouse agent’s job is to load validated data, and the data validator failed to reject bad data, the warehouse agent is still responsible for what it loaded. It should have its own sanity checks.

If the audit agent’s job is to verify that the warehouse contains what was intended, it is responsible for raising the alert early, not weeks later.

But underneath all three is a single point of accountability: The human who designed the agent fleet, who defined what each agent should do, and who set the rules for handoff. That person is responsible for the system.

What Goes Wrong in Practice

The reason we need explicit approval chains is because informal handoffs fail in predictable ways:

Failure 1: Signal Loss. Agent A says “I’m done.” Agent B assumes it succeeded. But “done” for agent A might mean “I ran and didn’t crash,” not “I ran and produced correct output.” Agent B never verifies.

Failure 2: Boundary Confusion. Agent A thinks its job is to ingest data. Agent B thinks its job is to validate data. Nobody said so explicitly, so in practice agent A also validates (badly), and agent B assumes it’s receiving clean data (it’s not). Both agents are surprised.

Failure 3: Escalation Trap. Agent A detects a problem but doesn’t know what to do. Instead of stopping, it passes the problem to agent B with a note. Agent B sees the note, gets confused, and passes it to agent C. Nobody actually stops the flow until a human discovers something is very wrong.

Failure 4: Scope Creep. Agent A successfully hands tasks to agent B. Agent B discovers it can delegate to agent C. Nobody defined whether agent B is allowed to subdelegate, or to how many levels. Suddenly you have a chain six agents deep, and if agent C fails, nobody remembers that agent A started it.

Each of these fails silently until damage has spread.

Logging and Feedback Loops

To make A2A delegation safe, log every handoff:

• Which agent handed off to which.
• What was handed.
• Whether the receiving agent accepted or rejected it.
• How long the task took.
• Whether an error occurred and what kind.

Over time, these logs reveal patterns:

• Agent X rejects data from agent Y consistently. Something in Y’s output doesn’t match X’s requirements. Fix it.
• Agent Z takes three times longer than expected to process batches. It might be hitting resource limits, or its code might be inefficient. Investigate.
• The flow from A → B → C works fine, but A → B → C → D fails often. Agent D might be unstable. Consider rerouting around it.

In a human organization, a manager reads these patterns and makes decisions. In an agent organization, you can monitor the same patterns and tune the system automatically. Or you can have a human read the data and make a call.

When Agents Can Sub-Delegate

Some agent systems need hierarchy. A high-level orchestration agent breaks a big task into smaller tasks and assigns them to worker agents. One of those worker agents might further break its task into subtasks.

This is fine, as long as it is controlled.

Before you allow an agent to delegate to another agent, define:

1. Which agents are allowed to delegate.
2. To which other agents they can delegate.
3. What conditions must be met (e.g., only if the task meets certain criteria).
4. How many levels of sub-delegation are allowed.

Write these rules in your policy file. Check them at runtime. If an agent tries to delegate when it shouldn’t, the system says no.

Without these rules, you quickly end up with a hidden pyramid of agents delegating to agents delegating to agents, and when something breaks, untangling the mess takes days.

The first four days established what an agent is, where it sits in the organization, what rules govern it, and what states it can be in. Today we see the operational reality: agents hand work to each other. That handoff can be controlled, tracked, and audited. Or it can be a black box. The difference is policy, approval chains, and the willingness to log every step.