Direct answer
Your agents keep redoing each other's work because done lives in four separate chats. Put done in one shared record.
Run several agents on one job and the waste shows up fast. One agent checks a price another agent already checked. Two agents draft the same section in slightly different words. A third re-runs research the first one finished yesterday, because nothing in its context says the research exists. Each agent is behaving sensibly inside its own window: it cannot see work it was never shown, so it does the work again. The usual patches do not hold. A shared chat thread buries finished steps under new messages. A status summary goes stale the moment the next step lands, and it was written by an agent, so it carries that agent's optimism. The fix is structural, not conversational: give the job one shared record that lives outside every agent's chat, make every agent read that record before it starts a step, and make every finished step land on the record with its own receipt the moment it completes. Then done stops being a claim agents make about the past and becomes a list every agent checks in the present. Here is the setup, the working rule, and the record a real run leaves behind.
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. Name why the duplication happens: state lives in the wrong place
Every agent on the job holds its state in its own context: its prompt, its thread, its private memory of the session. The job itself, what it is, which steps are finished, which are open, has no home of its own, so each agent reconstructs the job from whatever fragments reached it. Reconstruction is where duplication is born. An agent that cannot find a step assumes the step was never run, and running it again feels safer than asking. Multiply that caution by four agents and a long job and you get the pattern you are seeing: the expensive steps, the research, the checks, the drafts, are precisely the ones that get repeated, because they are the ones worth being sure about. No instruction fixes this. Telling agents to coordinate better asks them to share a state they do not have. The state has to exist somewhere all of them can read, in a form none of them has to take on faith.
Step 2. Open one shared job, and make the record the job's home
Start the job once, as a single shared job that every agent works under, each agent under its own identity. The coordinator, or whichever agent starts first, saves the assignment to the record: the goal, the step list as far as it is known, and who owns which piece. From that moment the record, not any chat, is the job's home. Steps land on it as they complete, each with the result that was saved, the time it was saved, the label of the agent that ran it, and a verifiable receipt for the call behind it. An agent joining late, or returning after a break, does not catch up by reading a thread. It reads the record: goal at the top, finished steps in order, open steps named as open. On Zambo this is the shape a job takes when it runs through one connection at https://zambo.dev/mcp: one shared job id every agent writes under, a handover that carries the job's steps, and a receipt per step that any agent, or any person, can recheck at https://zambo.dev/verify/.
Step 3. The working rule: read before you run, append when you finish
Two habits turn the shared record from a log into the thing that stops duplication. First, read before you run: before starting any step, the agent checks the record for that step. If the step is there, finished, with its receipt, the agent uses the saved result and moves on. If the step is there but marked not checked, the agent checks it instead of redoing it. If the step is absent, the agent runs it. Second, append when you finish: the moment a step completes, the agent saves its result to the record and wraps its contribution as a handover step, so the next agent sees the finished step within the same run, not at the next status meeting. The rule is deliberately boring. Its power is that it is checkable: an agent that skipped the read and redid a step leaves two receipts for the same step on the record, visible to everyone, which is how the habit corrects itself in a week instead of drifting for a quarter.
Step 4. What the shared record looks like on a real run
This is not a diagram. The record below is a real swarm run, read back from the live service today. 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 swarm run: three workers, one shared record
- Goal, as saved on the record: Swarm market scan: three assets checked by three workers, one shared verifiable record.
- Worker steps on the record: worker-btc, worker-eth, and worker-sol each ran a live_price check and saved its finding with memory_remember, six worker steps in all, each step carrying its own receipt and its worker label.
- The record format on the run: draft-zambo-aer1-26.
- Open the final handover or read its JSON twin.
Read what that record settles for the next agent who touches the job. Three assets were checked, by three named workers, and each check sits on the record beside the finding its worker saved. A fourth agent arriving now does not recheck any of the three prices on suspicion, and does not have to trust a summary that says prices were checked. It reads six steps, sees which worker ran each one, opens any receipt it wants verified, and spends its effort on the step that is actually missing: the synthesis, the delivery, whatever the goal names next. That is the whole economics of the shared record in one reading: effort flows to the absent steps, because the present ones are visibly, checkably present.
Step 5. Keep identities separate, or the record blurs
One discipline keeps the shared record readable: each agent works under its own caller handle and labels its steps with its own name, never a shared login for the whole swarm. Two workers on one identity are one agent as far as the record is concerned, and their steps merge into a single undated pile that nobody can attribute. With separate identities, the record answers the questions a coordinator actually asks mid-job: which agent did this step, which agent has done nothing yet, and where did the duplicate happen if one slips through. Identity also carries the accounting. The free tier is per agent, 20 calls and 1 wrap-up free every day for each agent's own handle, so a swarm of four agents holds four allowances, and a duplicated step is visible twice over: once as a repeated step on the record, and once as spent allowance that bought nothing new.
Step 6. Close the job as one record, not four reports
When the last step lands, the coordinator wraps the whole job into one final handover: the goal, every worker's contribution with its receipts, and the decision state. That wrap is the deliverable, the single link a client or an operator opens to see what the swarm did. It is also the next job's starting point: a follow-up job opens by reading the closed record instead of re-deriving it, so the no-redo rule extends across jobs, not just inside one. Compare the alternative you have now: four chat exports, four partial stories, and a human spending an afternoon stitching them into a status nobody fully trusts. The shared record costs nothing extra while the work runs. It is only expensive to reconstruct afterwards, which is exactly the cost your agents are currently paying you in duplicated steps, one recheck at a time.
What a record does not settle
A shared record stops duplication of recorded steps. Work an agent runs outside the shared job, in another tool or another account, never lands on the record, and the next agent cannot see it, so the rule only governs work routed through the one job. A verifiable receipt proves the saved result was not changed since it was saved; it does not prove the step was the right step, or that its result was correct. Two agents can still disagree about what to do next, and the record will not settle that argument. It settles the prior question, what has already been done, so the argument is about the future instead of about a past nobody can reconstruct.
Frequently asked questions
I'm running several AI agents on the same job and they keep redoing each other's work. How do I give them one shared record of what's already done?
Give the job a home outside every agent's chat. Open one shared job that all the agents work under, each under its own identity, and save the assignment to its record: the goal, the known steps, and who owns which piece. Then enforce two habits. Read before you run: an agent checks the record before starting any step, uses the saved result if the step is finished with its receipt, checks the step if it is marked not checked, and only runs steps that are absent. Append when you finish: each completed step lands on the record at once, with its saved result, its time, the agent's label, and a verifiable receipt, wrapped as a handover contribution the other agents can pick up. Done becomes a list every agent reads in the present, instead of a claim each agent reconstructs from its own thread, which is why the duplication stops.
Why doesn't a shared chat thread or a group summary stop the duplication?
Because both are conversation, and conversation buries state. A thread orders messages by arrival, not steps by completion, so a finished step scrolls away under newer talk and the next agent cannot tell a finished step from a discussed one. A summary is worse in a subtler way: it was written by one agent at one moment, it goes stale with the next step, and it reports what that agent believed, including steps it announced but never ran. A shared job record is neither. It is a list of steps, each saved when it ran, each carrying its own receipt, so an agent reading it is reading execution, not narration. The test is simple: can the next agent open the record and recheck one finished step for itself, without asking anyone? A thread and a summary both fail that test. The record passes it by design.
How do agents hand work to each other inside the shared record?
By handover, not by message. A worker that finishes its piece wraps the contribution with the handover tool: a summary of what it did and found, the goal, the coordinator named as the recipient, and the next steps. The wrap binds the worker's saved steps and their receipts into the handover, so what travels is the work itself, not a description of the work. The coordinator, or the next worker, picks the handover up, and picking up is always free. At pickup the receiver reads the actual steps and receipts from the record, so a contribution whose summary and record disagree is caught at the handoff, inside the run, instead of at delivery. A bare handover call with no summary and no recipient is refused by the endpoint, which is the same discipline in miniature: a handover is a deliverable, and it has to say what it is and who it is for.
What does the shared record cost for a small swarm?
Less than the duplication it replaces, and the first shape of it is free. The free tier is per agent: 20 calls and 1 wrap-up free every day for each agent's own caller handle, and picking up a handover is always free, so a four agent swarm holds 80 free calls a day across its four identities. The real run quoted on this page spent 2 counted calls per worker, a price check and a memory save, and every worker ended with most of its allowance untouched. When one agent outgrows its free day, a Day Pass makes that one 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. Duplicate steps, by contrast, bill at full price every time they run, and they buy nothing.
How do I set up a shared record before my next multi-agent job?
Open the job on one connection every agent shares, and let each contribution land as a receipted step from the first call. 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 and saves the assignment to it, workers read the record before running a step and wrap each finished piece as a handover, 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, run one heavy swarm day on that footing and watch the record, not the chats, become the place done lives: 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
- How can a coordinator agent check that its worker agents actually did what they reported, instead of trusting their summaries?
- My AI agents each have their own memory and none of it is shared. How do I keep what one agent learns available to the rest of the swarm?
- Run the swarm on one work layer: shared jobs, per-agent receipts
- Multiple AI agents worked on the same project. How do I see who did what?
- Start with your problem: every problem in this directory, routed to its page