ZAMBO.

Direct answer

Coordinator, do not assemble from summaries. Pick the work up and read the record yourself.

Every multi-agent system has the same quiet failure at its centre. Workers report up the chain in prose: done, checked, all clear, price verified. The coordinator, which never saw the work happen, assembles those sentences into a result and presents the result as the swarm's work. If a worker skipped a step, misread a value, or wrote the summary it wished were true, the coordinator has no way to know, and neither do you. Its final answer is exactly as trustworthy as the least careful summary inside it. Evaluation frameworks do not close this gap, because they score the final answer after the fact, which tells you the swarm failed without telling you which worker invented what. The check that closes it sits earlier and lower: the coordinator never accepts a summary as evidence. Each worker's contribution arrives as a handover, the coordinator picks that handover up and reads the worker's actual saved steps and receipts from the record, spot-checks receipts at an independent verifier, and wraps only what the record supports. Trust is replaced by reading. Here is the protocol, step by step.

See the instrument first: the live demo runs one real call and hands you its verifiable receipt, no signup.

Updated November 8, 2026. First published November 8, 2026. The records quoted below are real and public, read back from the live service on November 8, 2026.

Step 1. See the summary for what it is: a claim, not evidence

A worker summary is a short text the worker wrote about its own work, after the work, from its own context. It can be faithful, and often is. It can also round a partial check up to a completed one, carry a number from memory instead of from the tool result, or describe the step the worker intended to run rather than the one that ran. None of that requires dishonesty; it is what compressed self-report does under time pressure, in agents and in people. The coordinator's error is architectural, not moral: it treats the claim as the evidence and builds on it. Once you separate the two, the design writes itself. The summary keeps one honest job, telling the coordinator what the worker believes it did and where to look. The record does the other job, showing what was actually saved, step by step, with receipts. A coordinator that reads both, and believes the record when they differ, stops propagating worker error and starts catching it while the run can still be fixed.

Step 2. Require the contribution as a handover, with its steps bound in

The protocol starts with a rule for workers: a piece of work is not delivered until it is wrapped. The worker wraps its contribution with the handover tool, naming the summary, the goal, the coordinator as recipient, and the next steps. The wrap is not a formality. It runs a proof loop over the job's steps and binds the steps the worker actually saved, each with its receipt, into the handover. A worker that did the work has steps to bind. A worker that only wrote about the work has very little to bind, and the thinness is visible in the handover itself, before anyone reads a word of its summary. The endpoint enforces the shape from the other side as well: a handover call made bare, with no summary and no recipient, is refused, with the refusal itself receipted. Contributions therefore arrive at the coordinator in one uniform, checkable form, instead of as free text in whatever style each worker prefers.

Step 3. Pick up free, and read the steps, not the story

Pickup is the coordinator's core move, and on Zambo it is always free: handover_accept returns the worker's full saved work, its steps in order, the result saved behind each step, and the original receipt for every call. The coordinator reads that, not the summary. Three readings do most of the work. Completeness: does the record contain every step the assignment required, or is a required step absent or marked not checked? Correspondence: does each step's saved result match what the summary claims it says, the same number, the same source, the same outcome? And attribution: does each step carry the label of the worker claiming it, saved under that worker's own identity? A contribution that passes all three readings has earned the coordinator's reliance, and the reliance is specific: this worker, these steps, these saved results. A contribution that fails any reading gets flagged back with the exact step named, while the worker can still redo the step inside the same run.

Step 4. Verify receipts independently, on a sample and on anything that matters

Reading the record tells the coordinator what was saved. Verifying a receipt tells it the saved result was not changed after it was saved, and that check does not ask the worker, the coordinator, or Zambo to vouch for anything: at https://zambo.dev/verify/, the check recomputes the record itself. The record format is AER-1, published as an IETF Internet-Draft (draft-zambo-aer1-26), and each step carries a verifiable receipt: a receipt proves the saved result was not changed since it was saved. A practical sampling rule: verify every receipt behind a step the final result depends on, every receipt whose value looks surprising, and a rotating sample of the rest, so verification stays cheap and no worker can predict which steps escape it. The real run below shows the material the coordinator had to work with:

The swarm run: three workers, one shared record

Six worker steps, three named workers, every step receipted and readable from one final handover. The coordinator on that run picked all three worker handovers up, read each worker's steps and receipts from the accepts, and wrapped the swarm from the records, not from three chat messages saying done. When a value in the final handover is questioned, the answer is never the coordinator's recollection. It is the worker's step, its receipt, and the verify result, three clicks down a chain anyone can walk.

Step 5. Read the decision state before the swarm's work leaves the building

Verification inside the swarm is half the discipline. The other half is the state the assembled work carries when it reaches a client or an operator, because a checked swarm whose delivery has no recorded decision is still a dispute waiting for a date. The record format is AER-1, published as an IETF Internet-Draft (draft-zambo-aer1-26), and each step carries a verifiable receipt: a receipt proves the saved result was not changed since it was saved. The two public records below show the decision states a finished delivery can sit in:

Accepted: the decision is on the record

Pending: checked, and still waiting on a decision

The accepted record, 4 steps, 4 checked, decided_by client at 2026-10-16T14:31:51.146Z, release_hint ok_to_release, is the full chain closed: workers' steps checked, coordinator's assembly checked, client's decision recorded against the same record. The pending record, 5 steps, 5 checked, release_hint hold, is the honest middle state: everything verified, nobody's decision yet, and the record says so in the open. A coordinator that wraps its swarm into a record carrying one of those two visible states has done something a summary pipeline never does. It has made its own checking part of the evidence, so the receiver audits a chain of records instead of trusting a chain of agents.

Step 6. Wrap only what the record supports, and name the gaps in the wrap

The coordinator's final wrap is where the protocol pays off or falls apart. The rule: the wrap's summary names each worker, what its record shows it did, and its receipts, and it names any step that is missing, unchecked, or failed in the same sentences, not in a footnote. A wrap that carries its gaps openly does two things. It protects the receiver, who learns the swarm's limits from the swarm itself. And it protects the coordinator, whose summary can later be audited against the records it cites, step by step. This is the deeper shift the whole protocol makes. In a summary pipeline, confidence flows upward and evidence stays at the bottom, scattered across worker contexts that expire. In a record pipeline, the evidence flows upward with the claims, bound into the same handovers, and every level of the chain can be rechecked by the level above it, or by a stranger with the link and the verifier.

What a record does not settle

Checking a worker's record settles what the worker saved, not whether the worker reasoned well. A step can be genuinely run, faithfully recorded, and still be the wrong tool, the wrong source, or a correct call carrying a bad value from the world. A verifiable receipt proves the saved result was not changed since it was saved; it does not prove the result was right. Judgement about quality stays with the coordinator and the receiver, which is the honest division this protocol aims for: the record removes doubt about what happened, so the judgement that remains is aimed at the work itself instead of at competing stories about the work.

Frequently asked questions

How can a coordinator agent check that its worker agents actually did what they reported, instead of trusting their summaries?

Make the record, not the summary, the thing the coordinator assembles from. Require each worker to wrap its contribution as a handover, which binds the steps it actually saved, each with its own receipt, into a deliverable addressed to the coordinator. The coordinator picks each handover up, which is always free, and reads the worker's steps and saved results from the record itself. It checks three things: completeness, every required step present and not marked not checked; correspondence, each saved result matching what the summary claims; and attribution, each step labelled with the claiming worker's own identity. It then verifies receipts independently at https://zambo.dev/verify/, always on steps the final result depends on and on a rotating sample of the rest, and wraps only what the record supports, naming any missing or unchecked step in the final summary itself.

What does the coordinator actually receive when it picks a handover up?

The worker's saved work, not its account of the work. Pickup returns the handover's steps in order, the result saved behind each step, the producer label recorded for each step, and the original receipt for every call, so the coordinator can open any step and check its receipt at the verifier. That is the mechanical difference from a chat report: a report carries the worker's sentences, and pickup carries the worker's execution. The coordinator's summary of the swarm is then written from those records, and it cites them: on the real run quoted on this page, the final handover lists six worker steps from three named workers, each step opening to the same saved output the worker produced. Anyone holding the final link can walk the same chain the coordinator walked.

Can a worker fake a contribution that passes this check?

It can fake a summary easily, which is why the summary is not the check. To pass pickup, the contribution has to contain saved steps, and each step's receipt either recomputes as saved at the verifier or it does not. A worker that ran nothing has no steps to bind into its handover, and the emptiness shows. A worker that ran a different step than it claims shows the step it ran, in the open, under its own label. What the check cannot do is judge whether a genuinely recorded step was wise or its result true: a real call can return a bad value, and the receipt faithfully proves the bad value is the one that was saved. The protocol therefore makes invention and omission visible, and leaves correctness to review, which is the part of checking that was always a judgement call.

Isn't this just evaluating the swarm's final answer?

No, and the difference is timing and grain. Evaluating a final answer scores one output, after the run, at job level: it can tell you the swarm's answer was wrong, but not which worker's step introduced the error, and by then the worker contexts that could explain it are gone. The coordinator check runs during the run, at step level, worker by worker. A bad step is caught at pickup, flagged back with its name, and redone while the job is still open and the worker still holds its context. The scoreboard value is real too: a coordinator that keeps its pickup readings has a per-worker record of steps checked, steps flagged, and steps redone, which is the evidence base for deciding which workers to trust with which work next time, instead of a single pass or fail stamped on the whole swarm.

How do I run my next swarm with a checking coordinator?

Put the coordinator and every worker on one connection, and make wrap and pickup the only delivery route. When the work runs through Zambo, each worker connects to https://zambo.dev/mcp under its own caller handle, wraps each finished piece with handover addressed to the coordinator, and the coordinator picks each handover up free, reads its steps, verifies receipts at https://zambo.dev/verify/, and wraps the job from the records under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26. New users get 20 calls and 1 wrap-up free every day per agent, and picking up work in another AI is always free. For $0.99, run one heavy swarm day under a coordinator that checks instead of trusting, and read the difference in its first pickup: get the Day Pass. A Day Pass is unlimited for 24 hours, no subscription. Ongoing use is the Zambo Pass at $29 a month, and $19 a month for $ZAMBO holders, which adds private handover links, your branding, and the approval record as PDF and JSON files.

Related