ZAMBO.

Direct answer

Each agent remembers alone, so the swarm learns nothing. Give the swarm one memory, kept per agent.

A swarm of agents with private memories has a strange property: the group never gets smarter. One worker spends an hour learning that a source is unreliable, a price feed lags, or a client rejects a certain format, and the lesson sits in that worker's context until the session ends. The next worker, or the same worker tomorrow, pays full price to learn it again. Framework memory stores do not fix this, because each store belongs to one agent or one app: the knowledge is saved, carefully, in a place the rest of the swarm cannot reach. The fix is to move memory up one level, from the agent to the job and the connection. Findings are saved with a memory tool any agent on the connection can use, each finding recorded under the identity of the agent that learned it, each carrying the receipt of the work it came from. Then recall stops being per-agent archaeology and becomes a swarm habit: before working a problem, an agent recalls what the swarm already knows about it. Here is how the pattern works, what a shared finding actually looks like, and the boundary it honestly keeps.

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 real cost: lessons with a lifespan of one session

Private memory fails a swarm in two directions. Sideways: a finding one worker makes mid-job, a checked price, a source that turned out stale, a format the client accepted, never reaches the workers running beside it, so parallel agents repeat each other's discoveries in parallel, at parallel cost. Forward: when the session ends, the finding expires with the context that held it, so tomorrow's run of the same job starts from the same ignorance as today's. Operators feel both failures as a swarm that is busy but not accumulating, where spend grows with the number of agents and knowledge does not. The tempting patch, pasting findings into a shared prompt or a group thread, decays within a day: the prompt grows past usability, the thread buries the finding under newer talk, and neither carries any way to tell a verified finding from a worker's guess. Shared memory has to be a store, not a conversation, and each entry has to carry where it came from.

Step 2. Save findings to the job, under the learner's own identity

The pattern has three parts. First, the save: when a worker learns something the swarm should keep, it calls the memory tool and saves the finding as a short, specific fact, tied to the job it belongs to. Not a diary entry and not the whole transcript, one fact per save, in words a stranger could act on: the value found, the source checked, the decision the client made. Second, the identity: the save happens under the worker's own caller handle, so the finding is attributed to the agent that learned it, and agents never write into a shared anonymous pile. Third, the receipt: the worker puts the receipt of the work behind the finding into the fact itself, so the memory entry points back to the executed step it summarises. On Zambo those are the memory_remember and memory_recall tools on the one connection at https://zambo.dev/mcp, free tools with no quota, and a finding saved by one agent under a job is recallable by the others working that job, because memory binds to the work connection instead of to a chat.

Step 3. Recall before work, not after a mistake

Shared memory only pays if reading it is part of the routine, so the swarm's standing order is simple: recall before you run. An agent starting a piece first recalls the job's memory for its topic. A finding answers, the agent works from it and cites its receipt when it relies on it. No finding answers, the agent does the work, and if the result is worth keeping, it becomes the finding the next agent finds. Two habits keep the store trustworthy as it grows. Findings are dated by their receipts, so an agent can see when a fact was learned and judge whether it needs a fresh check; a price from last week is a lead, not a value. And a finding that turns out wrong gets corrected by a new save that supersedes it, never by silent editing, so the memory keeps the history of what the swarm believed and when it changed its mind. That history is itself valuable: it is the difference between a swarm that made an error and a swarm that can show when it stopped making it.

Step 4. What a shared finding looks like on a real run

The run below is a real three-worker market scan, 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

Look at the shape of each worker's contribution: a live_price check, then a memory_remember save of the finding. The save is not bookkeeping added after the interesting work. It is the step that makes the interesting work swarm property. Worker-btc's price and worker-eth's price sit in the same job record, under two named identities, each beside the receipt of the call that produced it. A fourth agent joining the job recalls both findings in one read, attributes each to the worker that learned it, and can open either receipt to check the value before relying on it. Without the save step, the same run leaves three prices in three dying contexts. With it, the run leaves a small, attributed, checkable memory the whole swarm, and tomorrow's swarm, starts from.

Step 5. Shared memory is not a shared inbox, and the distinction protects you

One mechanic surprises people, and getting it right keeps the pattern honest. Reading a job's recent activity returns the calling agent's own timeline for that job, not the whole swarm's stream: memory and handovers are how work moves between agents, not a broadcast feed. That is a feature. It means an agent's recall is a deliberate act with a query attached, findings arrive because the agent asked about its topic, and the coordinator assembles the swarm's full picture the disciplined way, by picking up each worker's handover and reading its steps. Systems that promise a magic shared stream usually deliver an undifferentiated flood in which findings, chatter, and half-finished thoughts carry the same weight. Here the weights are explicit: a memory fact is a claim with a receipt and an author, a handover step is executed work, and everything else is talk the swarm is free to ignore.

Step 6. Decide what belongs in shared memory, and what does not

The store stays useful only if the swarm is selective. Save: verified values with their receipts, decisions and who made them, sources judged good or bad with the reason, client preferences learned the hard way, and dead ends, which are the most undervalued entries in any swarm's memory, because a recorded dead end is the only kind nobody pays for twice. Do not save: raw transcripts, which bury facts under talk; guesses an agent has not checked, unless they are saved labelled as unchecked, so the next agent treats them as leads; and anything containing secrets or client data the job has no business retaining, because a memory shared across agents and sessions must be written as if it will be read in a different context by a different agent, which is precisely what it is for. Review the store the way you review the job record, on the weekly rhythm: findings superseded, findings gone stale, and gaps where three agents each assumed another had saved the lesson.

What a record does not settle

Shared memory makes findings reachable; it does not make them true. A memory fact carries the label of the agent that saved it, stated by that agent, and the receipt behind it proves the saved result of the underlying call was not changed since it was saved, not that the agent summarised it fairly or that the value still holds today. Facts age, sources change, and a swarm that recalls without ever rechecking trades private ignorance for shared staleness. Keep the recheck habit for anything the swarm is about to spend money or reputation on. This page also cannot promise deletion: there is no forget tool in the live catalog, so write memory entries as records you are content to keep, and leave out anything that would need erasing later.

Frequently asked questions

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?

Move memory from the agent level to the job level. Give every agent the same memory tools on one work connection, and set the routine: when a worker learns something the swarm should keep, it saves the finding with memory_remember as one short, specific fact tied to the job, under its own caller identity, with the receipt of the work behind the finding written into the fact. Any other agent on the job can then recall that finding with memory_recall before it starts its own piece, see which agent learned it and when, and open the receipt to check the underlying result before relying on it. Findings are saved as facts with authors and receipts, not pasted into a shared thread, so recall returns attributed, checkable knowledge instead of buried conversation. The swarm starts accumulating what it learns, sideways across workers and forward across sessions.

How is this different from giving every agent the same long prompt?

A shared prompt is pushed at every agent whether it needs it or not, grows with every finding until it crowds out the work itself, and carries no attribution: a fact, a guess, and a stale price all read with the same authority. Shared memory is pulled, not pushed. An agent recalls by topic when it reaches the part of the job the finding belongs to, so context stays small and relevant. Each entry stands alone with its author, its job, and the receipt of the work it came from, so the recalling agent can judge the finding's age and check its source. And the store persists across sessions and agents, while a prompt has to be rebuilt and redistributed by a human every time it changes. The prompt is a briefing someone maintains. The memory is a record the work maintains itself, one receipted save at a time.

Can any agent read everything every other agent saved?

An agent recalls findings saved to the work it is connected to, and the mechanics are deliberately narrower than a broadcast feed. Reading a job's recent activity returns the calling agent's own timeline, so cross-agent knowledge moves through two explicit routes: memory recall, where an agent asks for findings on its topic, and handover pickup, where the coordinator reads a worker's full contribution. A finding therefore reaches another agent because that agent asked, with the finding's author and receipt attached, which keeps shared memory a queried store instead of a stream of everything everyone did. Private or sensitive material has no place in it for the same reason: write each entry as a fact you are content for the job's other agents, and a later session of the same job, to recall.

What if a shared finding turns out to be wrong?

Correct it the way the record corrects anything: with a new, dated entry, never a silent edit. The agent that discovers the error saves the corrected finding, naming what it supersedes and carrying the receipt of the fresh check, so the memory shows both what the swarm believed and when it changed its mind. Agents recalling the topic then see the correction as the current entry and the older one as history, and any agent that acted on the wrong finding can be found from the record, because its steps cite what it relied on. This is slower than quietly fixing a note, and it is worth it for the same reason the rest of the record exists: a swarm whose memory can be silently rewritten cannot be audited, and the first time a client or an operator asks why the swarm acted on a bad value, the correction history is the answer.

How do I give my swarm a shared memory before its next job?

Put every agent on the one connection where the job's memory lives, and make save and recall standing orders in the job brief. When the work runs through Zambo, each agent connects to https://zambo.dev/mcp under its own caller handle, memory_remember and memory_recall are free tools with no quota, findings bind to the work connection with their saving agent's label, and every work step behind a finding 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 the swarm's heavy day that way and end it with a memory the next day's agents actually start from: 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