ZAMBO.

Direct answer

Run the swarm on one work layer: shared jobs, per-agent receipts

An agent swarm is several AI agents working one job at once: one checks prices, one drafts, one verifies, and a coordinator hands out the pieces and assembles the result. Starting the agents is the easy part. The hard parts are the seams: how a worker hands its piece over, where the shared state lives, and how anyone, including the coordinator, knows a worker really did what it says it did. Zambo is the layer under those seams: one shared job the work lands in, one identity per agent, shared memory, handovers that move work between agents, and a verifiable receipt for every single call. This page teaches the pattern twice: once as a paste for people brand new to swarms, and once at full depth, with a real four-agent run and every receipt linked.

See the instrument first: the live demo runs one real call and hands you its verifiable receipt, no signup. New here? Add Zambo to your AI in one step, then run the paste below. Reading as an agent? This guide has a plain markdown twin, same content, no styling.

Updated November 2, 2026. First published November 2, 2026. The worked example is a real run executed against the live service on November 2, 2026, with every receipt read back the same day.

New to swarms? Start here, no code

You need one chat AI for the coordinator and one for each worker; two workers is a fine first swarm. Add the Zambo endpoint to each one first (the one-step setup at zambo.dev/add), then paste the coordinator block into the coordinator's chat and the worker block into each worker's chat, and name the job. Each AI saves the identity (its caller handle) that the endpoint issues inside its own conversation, does its piece, and hands work over as a link. Nothing else needs to be built.

The paste, for the coordinator

Coordinate a swarm job with me on Zambo:
1. Connect to https://zambo.dev/mcp. When the endpoint issues your caller handle, save it in this conversation and present it on every call. You are the coordinator.
2. Open the job: call memory_remember with the assignment, one line per worker, and keep the receipt.
3. Give each worker its piece. Each worker works under its own caller handle and keeps the receipt of every call it makes.
4. When a worker finishes, it wraps its contribution with handover, with a summary and you named as the recipient, and gives you the handover link.
5. Pick each handover up (picking up is always free) and read its steps and receipts yourself. Check any receipt at https://zambo.dev/verify/ before you rely on it.
6. Wrap the whole job with handover: a summary naming each worker, what it found, and its receipt. That handover is the deliverable: the link a client or an operator opens to verify the swarm's work.

The paste, for each worker

Work one piece of a swarm job on Zambo:
1. Connect to https://zambo.dev/mcp. When the endpoint issues your caller handle, save it in this conversation and present it on every call. You are a worker; the coordinator holds the job.
2. Do the piece the coordinator assigned. Keep the receipt link of every call.
3. Save your finding with memory_remember, and put the receipt of the work in the fact.
4. Wrap your contribution with handover: a summary of what you did and found, the coordinator named as the recipient. Send the coordinator the handover link. That link is your deliverable: the record the coordinator, a client, or an operator can verify.

That is the whole pattern at hand scale. Everything below is the same pattern with the depth turned up: persistent identities, exact accounting, and the receipts of a run executed by code.

What a swarm actually struggles with

Workers handing off. A worker finishes its piece in its own context window, and the piece has to travel: to the coordinator, to the next worker, sometimes to a different AI entirely. Pasted summaries drift, lose numbers, and quietly edit themselves. A handover moves the work as a saved record instead: the steps, the outputs, and the receipts, opened from one link.

Shared state. A swarm needs a place where the job itself lives, separate from any one agent's chat: what the job is, what is done, what is left. If that state lives inside one agent's prompt, the swarm dies when that session does. On Zambo the job is a shared job id that every agent writes under, each under its own identity, and the job's handovers are its durable record.

Trusting worker output. This is the one that bites. A worker reports "done, price checked, all clear," and the coordinator has no way to tell a real check from a confident sentence. In this pattern the coordinator never has to guess: every contribution arrives as a handover whose steps carry receipts, the coordinator reads the steps itself at pickup, and any receipt can be verified independently. The record settles what the worker did; the coordinator's judgment settles what it is worth.

The pattern

Step zero, per agent: each agent connects once, is issued a caller handle, saves it, and presents it on every call. One handle per agent, never shared: identity, memory, and the daily free allowance all key to it.
1. Open: the coordinator opens one shared job (a single _session_id every agent reuses) and saves the assignment brief to memory under it, receipted.
2. Contribute: each worker does its piece under the shared job id and its own handle, then saves its finding to memory. Every call returns a receipt.
3. Wrap the piece: each worker wraps its contribution into a handover addressed to the coordinator: summary, goal, recipient, next steps. The wrap is the worker's free daily wrap-up.
4. Pick up and verify: the coordinator picks each worker handover up with handover_accept, always free, and reads the worker's saved steps and receipts from the record, not from the worker's summary.
5. Wrap the swarm: the coordinator wraps the whole job into one handover whose summary names each worker, its result, and its receipts, with the contribution receipts attached. That handover is the swarm's deliverable.

The real run: a three-asset market scan, four agents

Executed November 2, 2026, against the live endpoint. One coordinator (swarm-coordinator) and three workers (worker-btc, worker-eth, worker-sol), each initialized separately, each issued its own caller handle, all working under one shared job id, swarm-scan-2026-11-02. The coordinator opened the job with the assignment brief: receipt 4aad48df.

The contributions

The coordinator picked all three handovers up (20:10:13, 20:10:16, 20:10:19 UTC), read each worker's steps and receipts from the accepts, and wrapped the swarm: the final handover, or its JSON twin. The final handover lists exactly six steps, the three price checks and the three memory saves, each opening to a receipt carrying the same saved output the worker produced, timestamps identical to the original calls. Its summary names each worker, its price, and its original receipts, and the wrap's own receipt is 61ee822c. Runnable code for this exact run shape ships in the starter repo as examples/swarm-scan, and the pattern also ships as an installable skill file in the same repo at skills/swarm-coordination/SKILL.md. The whole pattern also ships as one standalone agent package, the skill, the coordinator and worker code, the no-code pastes, and this run's full record in a single template repo an agent can clone and run: zambo-swarm-coordination. Install it from PyPI (pip install zambo-swarm: https://pypi.org/project/zambo-swarm/) or npm (npm install zambo-swarm: https://www.npmjs.com/package/zambo-swarm). Same bundle either way.

Audit this run

Do not take this page's word for any of it. Pick any worker contribution in the final handover, open its receipt, and check it at zambo.dev/verify. A receipt proves the saved result was not changed since it was saved, and the check recomputes that from the record itself, without asking anyone to vouch for it. If a receipt from this run ever fails to verify, that is news, and we want to hear it: write to brennanzambo@zambo.dev. A record that moved after it was saved is the one failure this system exists to make visible.

Step zero, at depth: one handle per agent

When an agent initializes against https://zambo.dev/mcp, the endpoint issues a caller handle (in the initialize response and the X-Zambo-Caller-Handle header). That handle is the agent's continuity identity: its memory, its job timelines, and its daily free allowance all key to it. The discipline is mechanical. The agent saves the handle in its own state file before doing anything else, presents it as _caller_handle on every call, and adds its agent name as _caller_label so the job's record attributes every step to a named agent. Handles are never shared between agents: two workers on one handle are one agent as far as memory and quota are concerned, and the swarm's accounting collapses. The four agents in the run above each hold their own state file, and those exact identities are reused by the daily public swarm demo, so their memory compounds day over day instead of resetting.

What the coordinator actually reads

Two mechanics matter here, and both are easy to get wrong. First, continuity_get_recent under a shared job id reads back the CALLER's own timeline for that job, not the whole swarm's: in the run above, the coordinator's read returned its own opening step and none of the workers' steps. The shared job id binds the job's ledger and its pass together; it is not a shared inbox. Contributions move through handovers, which is the second mechanic: handover_accept returns the worker's full saved work, its steps, its prices, and its original receipts, and it costs nothing. The coordinator's verification habit is therefore simple: never assemble from worker summaries. Accept, read the record, spot-check receipts at the verifier, then wrap.

Wrap discipline

A handover call is a deliverable being published, and the endpoint treats it that way: called bare, with no summary and no recipient, it refuses, issues its own receipt, and asks what should be handed over and to whom. The run above contains that refusal, from the coordinator's first wrap attempt: receipt b2882668. A proper wrap sets the summary (what was done and found), the goal, the recipient, and the next steps. A wrap also runs a proof loop over the job's steps and binds them into the handover, which is why a worker handover lists the job's workflow steps, each receipted, and why the final handover's six steps carry the same saved outputs as the workers' original calls. The coordinator's final wrap additionally attaches the contribution receipt ids as evidence and chains off the last pickup with continue_from, so the swarm's record is one chain, not four piles.

The accounting: what a swarm costs

The free tier is per agent: 20 calls + 1 wrap-up free every day for each agent's own caller handle, and picking up in another AI is always free. Counted from the run's own counters: the coordinator spent 2 counted calls (the opening remember and one continuity read); each worker spent 2 (its price check and its memory save). Three pickups and four wrap-ups, one per agent, moved no counter at all. Total: 8 counted calls across four separate allowances, and every agent ended the run with 18 of its 20 free calls left. A swarm whose agents each stay inside that shape runs free indefinitely, one run a day or several.

The scaling line, for when a swarm outgrows free: a Day Pass is $0.99 per agent and makes that agent unlimited for 24 hours; the Zambo Pass is $29 per agent for 30 days. Both are one-time payments, never subscriptions. So this four-agent swarm, on a heavy day that outgrows the free tier, costs four Day Passes: $3.96 for the day. The same four agents covered for a month of heavy days: four Passes, $116 for 30 days. Agents that stay inside the free shape keep costing nothing, and pickup stays free at every tier, so a coordinator can always read its swarm's record even on a day it cannot work. Start at zambo.dev/add.

Standing instructions, at depth

For the coordinator

1. Connect to https://zambo.dev/mcp, initialize once, and save the caller handle the endpoint issues in this agent's state file. Present it as _caller_handle on every call. One handle per agent, never shared.
2. Open one shared job: pick a single _session_id for the job and memory_remember the assignment brief under it. Keep the receipt.
3. Hand each worker its piece and the shared job id. Workers work under their own handles and state files.
4. As each worker's handover arrives, pick it up with handover_accept (always free) and read its steps and receipts from the record. Verify any receipt at https://zambo.dev/verify/ before relying on it. Never assemble from summaries.
5. Wrap the job with handover: a summary naming each worker, its result, and its receipts, the contribution receipt ids attached, continue_from set to the last pickup. That handover is the deliverable: the link a client or an operator opens to verify the swarm's work.

For each worker

1. Connect to https://zambo.dev/mcp, initialize once, and save your caller handle in your own state file. Present it on every call, with your agent name as the caller label.
2. Work under the shared job id the coordinator gave you. Keep the receipt link of every call.
3. memory_remember your finding under the job id, with the work's receipt in the fact.
4. Wrap your contribution with handover: summary, goal, the coordinator named as recipient, next steps. A handover call without a summary and a recipient is refused. Send the coordinator the handover link: that link is your deliverable, the record anyone can verify.

What Zambo is not here

Zambo is not a swarm orchestrator, not an agent framework, and not a scheduler. It does not spawn agents, assign their work, retry their failures, or supervise their reasoning. Your framework, your scripts, or your chat sessions do that, and this page takes no position on which you use. Zambo is the shared work layer the swarm runs on: the job the work lands in, the memory each agent keeps, the handovers that move work between agents, and a verifiable receipt for every call. It also does not make worker output correct. A receipt proves the saved result was not changed since it was saved; it does not prove the price was right or the worker chose the right tool. The record makes the swarm's work checkable, so judgment, the coordinator's, a client's, an operator's, can rest on what actually happened.

Frequently asked questions

What is an agent swarm, in plain words?

An agent swarm is several AI agents working on one job at the same time, each doing a piece: one reads prices, one drafts, one checks, while a coordinator agent hands out the pieces and assembles the result. The agents are easy to start. The hard parts are the seams: how a worker hands its piece to the coordinator, where the shared state lives, and how anyone knows a worker really did what it claims. This guide is about those seams.

Does Zambo run or schedule the swarm?

No. Zambo is not a swarm orchestrator or an agent framework, and it does not schedule, spawn, or supervise agents. Your framework, script, or chat sessions run the agents. Zambo is the work layer underneath: the shared job the work lands in, the per-agent memory, the handovers that move work between agents, and a verifiable receipt for every call, so the swarm's output is a record anyone can check instead of a pile of chat claims.

How does the coordinator know a worker really did the work?

It does not take the worker's summary on faith. Each worker wraps its contribution into a handover; the coordinator picks that handover up with handover_accept, which is always free, and reads the worker's actual saved steps and receipts from the record itself. Any receipt can be checked at https://zambo.dev/verify/, where the check recomputes whether the saved result was changed after it was saved. A worker whose story and record disagree gets caught at pickup, not at delivery.

What does a small swarm cost on the free tier?

The free tier is per agent: 20 calls + 1 wrap-up free every day for each agent's own caller handle, and picking up a handover is always free. The four-agent run on this page spent 2 counted calls per agent, 8 in all, and every agent ended the run with 18 of its 20 free calls left. When one agent outgrows the free tier, a Day Pass makes that agent unlimited for 24 hours for $0.99, and the Zambo Pass covers an agent for 30 days for $29; both are one-time payments, never subscriptions. A four-agent swarm on Day Passes for a heavy day is $3.96 in total.

Can I run this pattern with no code?

Yes. Add https://zambo.dev/mcp to a chat AI for the coordinator and one for each worker, then paste the coordinator block and the worker block from the start-here section of this guide. Each AI saves the caller handle it is issued inside its conversation, does its piece, wraps its contribution, and hands the coordinator a link. It is the same pattern the code runs, worked by hand.

Related

The Loop kit

One routine, every piece of it in one place: the data that found the loop, the recipe, the library of pre-built jobs, the two shapes a daily loop takes, and a starter repo with Zambo already wired in.