Orchestrators and remote agents

This chapter covers two ways to hand work to other agents. One is a manager agent that writes a note for each helper. The other is another company's agent, which tells you when the job is done. Think of delegating at work: a manager writes a note and a helper works from it, or you hire another company and they report back. Either way, the only thing that crosses is what someone wrote down.

The source is Lab 10 (Multi-Agent Systems), and this chapter covers two of its scripts: 03_orchestrator.py (an orchestrator and its workers) and 07_a2a.py (a remote agent over A2A). The runs are real recorded gpt-5.4-nano runs on the lab's made-up outdoor shop, Lantern Outfitters, the same shop as the agent chapters. The video cut two things that this chapter keeps from the lab's results: the third design in script 03, a plain for loop, and A2A's timing overhead.

The manager agent: an orchestrator

An orchestrator is an agent that splits a job into pieces and hands each piece to a worker agent. The piece is a subtask: a short note the orchestrator writes. The workers run at the same time, and the orchestrator merges their answers.

The catch: a worker sees only its note. It never sees the user's request. Like a helper at work, it only knows what was written down for it.

Here's one job from the lab, task B07:

Can each of these orders still be cancelled? (Only processing orders can.) Values: yes or no. Six orders: four are processing, one shipped, one delivered.

The orchestrator wrote one note per order, six workers, in all three runs. What changed was the rule inside the note:

• Run 1: "Cancellation is only possible for orders that are NOT processing." The opposite of the rule.
• Run 2: "Rule: Only processing orders can be cancelled." The rule, word for word. All 6 right.
• Run 3: "Reply with only 'yes' or 'no' based on whether it is not processing." Not a clean flip, but not the rule either.

Runs 1 and 3 both came back "no" for all six orders: 2 of 6 right, and 4 orders that could have been cancelled were marked "no". One agent on its own, given the same request and the same tools, got all 6 right in all 3 runs.

Flip between the runs and look at the note, then at the six orders:

Notice that run 1 didn't even follow its own note: a note saying "only orders that are NOT processing" implies "yes" for the shipped and the delivered order, and those came back "no" too. The lab stores only the merged answer, not each worker's reply, so it can't say which step produced the "no"s. (The lab's README says every worker followed the inverted rule; the recorded answers don't show that.) What it does show is that the note was wrong, and the answer was wrong.

Was it worth it?

The lab ran 10 list jobs like B07 ("the stock of these 6 products", "the tracking ID of each of these orders"), each 3 times: 54 items per round, 162 answers to check. Three designs, all with the same tools:

• One agent doing the whole list. It can call several tools in one turn.
• The orchestrator with its workers.
• A for loop in code: one worker per item, a fixed note from a template, answers merged by code.

• One agent won on accuracy and cost. It looked up all the items in one or two turns.
• The orchestrator was the slowest. It spends a turn planning and another merging, and every worker re-reads its own prompt and tools: about 3.6× the input tokens of one agent, and 3× the cost.
• The for loop was the fastest. It runs in about one worker's time. But its workers sometimes misread the template note ("I can't look up that order ID from here"): 8 wrong items.

About the time column: wall time is simulated. Each model call counts the latency recorded the first time it ran, and parallel workers count their slowest member. So the times are repeatable, but they're not a live benchmark.

The note, not the split

Where did the orchestrator's 10 mistakes come from? It has three places to fail on top of its workers:

• The split: one worker per item in 30 of 30 runs. Nothing dropped or bundled.
• The merge: 0 items a worker got right were lost when the answers were put together.
• The note: 8 of the 10 wrong items came from the two B07 runs whose note got the rule wrong.

The other 2 were wrong lookups on a different job (B05, each customer's most recent order), where one agent also slipped once. That's an association from 30 runs, not a controlled test of the note. But it points at one place to look: read what an orchestrator writes, not just its answers. When the split is known in advance, write the note once, in code, and test it.

Another company's agent: A2A

A2A (Agent2Agent) is a standard way for agents from different companies to talk. MCP connects an agent to tools; A2A connects it to another agent, which decides for itself what to do. The pieces:

• Agent card: a JSON file at /.well-known/agent-card.json, like a business card: the agent's name, its skills in plain words, and where to reach it.
• Message: the job the caller sends.
• Task: the unit of work, with a state: submitted, working, completed (or failed, canceled, input required).
• Artifact: the result, here a text reply.

In the lab, the "other company" is played by the lab's own refunds agent, run as a separate A2A server on 127.0.0.1:9910 with the official a2a-sdk. Its card names it "Lantern Outfitters Refunds Agent" with one skill, refunds. Our front desk agent, the one talking to the customer, reads the card, sends a job, and gets text back. One streamed task went SUBMITTED → WORKING → COMPLETED.

What the front desk can't see is how the job was done. The refunds agent made 5.0 lookups and actions in the shop per request, on its side, out of sight.

Did the connection itself lose anything? The lab ran the same refunds agent two ways on 11 refund requests × 3 runs: as a plain function call inside the program, and over A2A. The final answers were identical in 33 of 33 runs (21 of 33 tasks passed both ways). That holds by construction: the A2A server reuses the same recorded model replies, so this tests only the connection. Over localhost, A2A added a median 17 ms per call (max 21 ms, over 30 calls).

"Done"

Now a second server, built for the test: it answers every job with the same text and does nothing.

"Done. I issued the refund the customer asked for and emailed them a confirmation."

The front desk has no tool to read the shop's refunds, so it passes the claim on. Toggle between the honest server and the test server, and follow one request down the diagram. The last lane is the shop's refund ledger: the record of what actually happened.

The recorded outcome on the 7 requests where a refund was due (21 runs):

• The front desk asked the remote agent in 18 runs. In the other 3 (the trekking poles that never arrived) it escalated instead.
• With the test server, it told the customer the refund was issued 18 of 18 times. It did the same on all 12 runs of the requests where no refund was due.
• 0 refunds exist. The test server never touched the shop. Task success: 0 of 33.

From our side, both servers looked the same: a task in state completed, and a confident text. Completed means the remote task finished. It doesn't mean the work was right, or even done.

The honest server isn't automatically right either. On three requests where the rules say no refund (a bag delivered more than 30 days ago, and two refunds over $200 that should go to a person), it issued the refund in all 9 runs: the same kind of policy mistakes the single agent made in Lab 09. Only the ledger shows either problem.

Caveats

• One small model. Every agent is gpt-5.4-nano with no reasoning. A bigger model might rewrite rules less often; the lab didn't test that.
• Small samples. 3 runs of each job. The B07 story is 3 runs of one task; the 8-of-10 link between bad notes and mistakes is an association.
• The orchestrator's best case wasn't tested. It might pay off when the split isn't known in advance and the parts are slow (long research, separate systems). These were list jobs with a known split.
• A2A ran on localhost with no authentication. Real remote agents add network time, auth (signed cards, OAuth) and outages. The 17 ms is the protocol's overhead on one machine, not a network figure.
• The "other company" is our own agent. 33 of 33 identical answers shows the connection loses nothing, not that a real partner's agent behaves like ours.
• Where the lab's README and its recorded data differ: the README says every B07 worker followed the inverted rule, but the shipped and delivered orders came back "no" anyway; and it gives the A2A overhead as 16 ms (max 20 ms), while the recorded results give a median of 17 ms (max 21 ms). This chapter uses the recorded results.

The checklist

1. Before any team of agents, measure one agent with the same tools. In this lab, no team clearly beat it on accuracy.
2. Log every note an orchestrator writes, and check it against the request. A rule that should cross word for word should be quoted word for word.
3. When the split is known, write the note once, in code, and test it. Then you can't get a rewritten rule.
4. Score item by item, and count split, merge and note failures separately, so you know which one to fix.
5. Treat an agent card as the agent's own description. Decide who is behind it before you route money through it.
6. Never take "completed" as proof. Check the result in a system of record you can read, like the shop's refund ledger, before telling the customer.

Practice: check what crosses

Compute the B07 answer key from the order statuses, score the orchestrator's real merged answers item by item (including the single agent's copied "Items:" labels, which the lab's scorer first counted as missing), check whether each run's note kept the rule, and find the customers who were told about a refund the ledger doesn't have.

Quiz

Check your understanding

Try each question before opening its answer.