ZAMBO.

Direct answer

The framework is layer one of five. Here are the other four, in the order you will miss them.

Every multi-agent tutorial ends at the same place: a framework demo where three agents exchange messages and a result appears. Then you run a real job, longer than the demo, with a client or a deadline attached, and the missing layers announce themselves one failure at a time. Agents redo each other's work, because nothing holds shared state. A worker finishes and nobody can check its steps, because nothing keeps proof. One agent crashes and the job restarts, because the state lived in its session. The framework did its job: orchestration, who talks to whom, in what order. What it never claimed to provide is the work layer underneath: scheduling with a budget, one shared record of what is done, handoffs that move the work itself between agents, shared memory for what the swarm learns, and a verifiable receipt on every step so done can be checked instead of believed. This page teaches that layer, piece by piece, with a real four-role run at the end.

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

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

Layer 1. Orchestration: the framework you already have

Your framework decides roles, message flow, and turn order: a coordinator decomposes a goal, workers execute pieces, results flow back. Keep it. Nothing on this page replaces it, and the commonest beginner mistake is shopping for a second framework when the first failure appears, because the failure is almost never orchestration. If your agents can address each other and a simple two-step job completes, layer one works. Every failure after that belongs to a layer the framework was never selling, and adding a second framework stacks a second layer one on top of the same missing four. Diagnose by layer, not by brand: when something breaks, ask which of the next four layers was absent, and you will have the fix and the vocabulary for it in one move.

Layer 2. Scheduling and budget: who runs, when, and at what cost

A demo runs every agent until it stops. A system schedules: which agent picks up which piece, in what order, with what allowance of tool calls, and what happens when the allowance runs out mid-job. Two rules carry most of the weight. Give each agent its own identity and its own allowance, so cost and blame attach to an agent, never to the swarm as a blur. And make the budget a written line inside the job before it starts, a number of calls per agent per day, a cap where spend stops and a human or coordinator decides, so a looping worker burns its own allowance and stops instead of billing the whole system for its confusion. On Zambo this accounting is per caller handle by construction: 20 calls and 1 wrap-up free every day per agent, pickup always free, and spend limit tools that refuse at the line and record the refusal with its own receipt.

Layer 3. Shared state and handoffs: one job, outside every session

Shared state is the layer whose absence causes the redoing, the lost crashes, and the contradictory results. The pattern: the job, not the agent, owns the state. Open one shared job per piece of work. Every finished step lands on its record as it completes, with its saved result, its time, and the producing agent's label. Agents read the record before running a step and append when they finish. Movement between agents happens by handover: the finishing agent wraps its contribution, summary, goal, recipient, next steps, with its saved steps bound in, and the receiving agent picks the handover up and reads the actual work. A handover is therefore not a message about work. It is the work, changing hands, with its evidence attached. Once this layer exists, sessions become replaceable, agents become interchangeable, and the job survives both.

Layer 4. Shared memory: what the swarm learns, kept where the swarm can reach it

State is what the job has done; memory is what the swarm has learned: the stale source, the accepted format, the price that was checked and when. Save each finding as one short fact tied to its job, under the learning agent's own identity, with the receipt of the work behind it written into the fact. Recall by topic before running a piece becomes the swarm's standing order. Two properties keep memory honest as it grows: entries are attributed and dated by their receipts, so a reader can judge age and author, and corrections land as new entries that supersede old ones, never as silent edits, so the swarm keeps a history of what it believed. Skip this layer and the swarm stays busy forever without getting smarter, relearning the same lessons at full price on every run.

Layer 5. Proof: a receipt per step, checked by someone else

The last layer is the one demos never show, because a demo's audience is its builder. Real work has a second audience: a coordinator who did not watch the workers, a client who did not watch anyone, an operator reading the job next quarter. For them, each step carries a verifiable receipt, a record of the saved result that anyone can recheck at a public verifier, under an open format: AER-1, published as an IETF Internet-Draft (draft-zambo-aer1-26). 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. Proof changes the questions a system can answer. Not did the swarm say it finished, but which steps are on the record, which are marked not checked, and which receipts verify. The real run below is small enough to hold in your head and complete enough to show all five layers at once:

The swarm run: three workers, one shared record

Read it by layer. Orchestration: a coordinator's goal decomposed across three named workers. Shared state: all six steps on one job record, readable by any of them. Handoffs and memory: each worker paired its check with a memory save, so the finding outlives the worker. Proof: every step carries its own receipt, and the final handover gathers the whole run behind one link. Scheduling and budget sit underneath: three workers, 2 counted calls each, inside a free daily allowance of 20 per agent, with headroom the record makes visible. That is a complete multi-agent system in miniature. Scale changes the counts, not the layers.

What a record does not settle

Layers do not supply judgement. A shared record will not decide whether a worker's step was the right step, and a verifiable receipt proves the saved result was not changed since it was saved, not that the result was correct. Scheduling and budgets bound cost; they do not make a bad plan cheap enough to be a good one. And the work layer only covers work routed through it: steps an agent runs in other tools, under other accounts, leave no step on the shared record, so the discipline is a routing decision, made at setup, not a property the system has by default.

Frequently asked questions

I'm learning to build multi-agent systems. What do I actually need beyond the framework: scheduling, shared state, handoffs, proof?

Five layers in all, and the framework is only the first. Orchestration, which your framework provides: roles, message flow, turn order. Scheduling and budget: each agent on its own identity with its own call allowance and a spend cap that stops a looping worker at its own line. Shared state: one job record outside every session, where finished steps land as they complete, so agents read before they run and no step is done twice or lost in a crash. Handoffs and shared memory: work moves between agents as wrapped handovers carrying the saved steps themselves, and findings are saved as attributed facts any agent can recall. Proof: a verifiable receipt on every step, in the open AER-1 format, so a coordinator, a client, or you next quarter can check what the swarm did instead of trusting its summaries. Build them in that order; each missing layer produces a characteristic failure you can diagnose by name.

Do I need to replace my framework to get shared state, handoffs, and proof?

No. The work layer sits underneath whichever framework you already run, because the two solve different problems. Your framework keeps deciding who talks to whom and in what order. The work layer is a connection the agents do their tool work through, which is where steps get saved, receipts get issued, handovers get wrapped and picked up, and memory gets shared. The integration is mostly a routing rule, work runs through the one connection, plus three habits: read the job record before running a step, wrap contributions as handovers instead of reporting them in chat, and save findings to the job memory as you learn them. If a simple two-step job already completes in your framework, orchestration is fine and nothing about it needs to change. The failures that send builders framework shopping, duplication, unverifiable workers, crash losses, almost always live in the missing layers, not in layer one.

What breaks first when a multi-agent system has no shared state?

Duplication, quietly, and then contradiction, loudly. Without one job record, each agent reconstructs the job from its own context, cannot find a step a sibling finished, and runs it again, so the expensive steps get paid for twice. Next, two agents complete the same step differently, both report success, and the coordinator assembles a result that quietly contains both versions or picks one by arrival order. Then the first crash lands and the job's true state turns out to have been the crashed agent's session, which is gone. Shared state prevents all three with a single mechanism: one record, appended as steps complete, read before any step runs. It is the cheapest layer to add and the one whose absence is most expensive, which is why it sits immediately above orchestration in the build order.

How is a handover different from one agent messaging another?

A message describes work; a handover delivers it. When a worker messages a coordinator that a check is done, the coordinator holds a sentence, written by the worker, from memory, after the fact. When a worker wraps a handover, the wrap binds the steps the worker actually saved, each with its saved result and receipt, under a summary, goal, recipient, and next steps, and the receiver picks that package up and reads the work itself. The difference shows at the first disagreement: with messages, the argument is about what was said; with handovers, both sides open the same steps and the record settles it. Handover also carries the job across sessions and across AIs, because the package lives on the work connection, not in either agent's chat. Messages are for coordination chatter. Anything that counts as done should travel as a handover.

How do I run my first complete five-layer system this week?

Take one small real job, three or four agents, and run it through one work connection so every layer is exercised at toy scale before you scale any of them. When the work runs through Zambo, each agent connects to https://zambo.dev/mcp under its own caller handle, the coordinator opens one shared job, workers wrap contributions with handover and save findings with memory_remember, and every step carries a verifiable receipt 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, give the swarm one heavy day with all five layers live and inspect the final handover as your first complete system record: get the Day Pass. A Day Pass is unlimited for 24 hours, no subscription. Ongoing use is the Zambo Pass at $29 a month, $19 a month for $ZAMBO holders, or Lifetime at $250 one time.

Related