"Done" Is Not a Handback: What a Worker Agent Should Actually Return to Its Supervisor

A supervisor agent dispatches four workers to gather pricing data on a competitor set. Twenty minutes later all four report back: "Completed. Collected pricing for all assigned vendors." The supervisor assembles the comparison table and hands it up. Three of the numbers are wrong, and one vendor's pricing was never public in the first place — the worker inferred it from a cached blog post and reported the same cheerful "completed" as everyone else.

Nothing failed. No tool errored, no step timed out, no retry fired. The system broke at the seam where a worker described its own work and the supervisor believed the description.

🔍 The supervisor can only judge what it can see

A worker agent's handback is the supervisor's entire view of the work. Whatever is not in that payload effectively did not happen — the supervisor cannot re-derive it, and by the time the run is over the worker's context is gone.

That makes the handback shape a real design decision, not a serialization detail. Three shapes are common, and they fail in different directions.

The raw transcript. Hand back everything: every tool call, every result, every intermediate thought. Nothing is lost, and the supervisor can audit anything. But it floods the supervisor's context — four workers at 15k tokens each and the supervisor is now reasoning over 60k tokens of noise to answer one question. Worse, the supervisor tends to re-do the worker's reasoning instead of judging its output, which is the whole reason you delegated.

The prose summary. Hand back a paragraph: what I did, what I found. Cheap, readable, and exactly what most multi-agent setups do by default. It is also unverifiable. A summary written by the same model that did the work inherits that model's confidence, including its confidence in the parts it guessed. "Collected pricing for all assigned vendors" is what a worker says whether it found four prices or three prices and one plausible invention.

The structured result with evidence pointers. Hand back a typed object: the values, plus, for each value, where it came from and how sure the worker is. Bulkier than prose, far smaller than a transcript, and — the point — checkable without trusting the worker's narration.

The field that changes everything: provenance per item

The single highest-value addition to a handback is not a confidence score. It is a pointer, per claim, to the specific tool result that produced it.

{
  "vendor": "Northwind",
  "plan": "Business",
  "price_monthly": 49,
  "currency": "USD",
  "source": {
    "tool_call_id": "fetch_page:7",
    "url": "https://…/pricing",
    "retrieved_at": "2026-09-08T14:02:11Z",
    "quote": "Business — $49 per user / month"
  },
  "status": "found"
}

Compare that to the vendor the worker guessed. If the schema requires a source with a real tool_call_id, the worker has three options: find the number, emit status: "not_found", or fabricate a call id. The first two are useful. The third is the one thing a supervisor can mechanically catch — a source id that does not appear in the run's tool log is a hard error, no judgment required.

That is the property worth designing for. A good handback makes at least some failures checkable by code rather than by a second model's opinion.

✅ The five fields worth requiring

Regardless of domain, most worker handbacks converge on the same skeleton:

1. Outcome status, from a closed set: complete, partial, blocked, refused. Not free text. "Done with caveats" and "done" must not collapse into the same string.
2. The result payload, typed to whatever the supervisor asked for — and empty or null where the worker found nothing, never filled with a plausible placeholder.
3. Per-item provenance, as above, for anything the worker asserts about the outside world.
4. What was not done, explicitly. The assigned vendor with no public pricing belongs here, named, not silently dropped from a list of four that comes back with three entries.
5. Cost and effort actually spent — tool calls made, tokens used, wall time. The supervisor needs this to decide whether to retry the worker or route around it.

Notice what is absent: the worker's reasoning. A supervisor that reads worker reasoning starts arguing with it. Keep the chain of thought in the worker and hand up conclusions plus evidence.

⚠️ Partial success is the case everyone skips

Most handback schemas are written for the happy path, so workers are forced to choose between "complete" and "failed" when the truth is "three of four." Faced with that choice, a model that got most of the way there will say complete — it is the closer answer, and nothing in the schema rewards precision.

Then the supervisor aggregates four "complete" results into a report that quietly has a hole in it.

The fix is structural, not a prompt tweak: make partial a first-class status, require a missing array whenever it is used, and have the supervisor treat any non-empty missing as a routing decision — retry with a different tool, escalate to a human, or ship with an explicit gap noted. What it must not do is average four statuses into a vibe.

💡 The cheap version, if you are not ready for schemas

Not every setup needs typed objects. A meaningful improvement lands in one line of the worker's instructions:

Report each assigned item on its own line as item | found/not-found | value | url. Do not summarize. If you did not retrieve a value from a tool result this run, mark it not-found.

That is not enforcement — a determined model can still write a URL it never fetched. But it converts one confident paragraph into a per-item ledger, and per-item ledgers are where holes become visible.

The takeaway

Delegation between agents is not finished when the worker stops. It is finished when the supervisor can tell the difference between work that succeeded, work that partly succeeded, and work that was narrated. A prose summary destroys that distinction on purpose — it is a compression format optimized for reading, and supervisors are not readers, they are routers.

Design the handback for the decision the supervisor has to make next. If it cannot act differently on partial than on complete, the extra fields are theater. If it can, they are the only thing standing between four confident reports and one wrong table.