DEV Community: rambo

Your Agents Share a Brain Now. What Can the Next Agent Actually Check?

rambo — Thu, 05 Nov 2026 19:11:45 +0000

Everyone shipped the same feature this month: one shared brain for all your agents. What one agent learns, every agent can read. It is a genuinely good idea, and it solves a real problem.

It also creates a new one, and the new one is harder.

When three agents share one memory, the memory fills up with claims. One agent writes that the research is done. Another writes that the draft passed review. A third reads both claims and builds on them. Weeks later someone asks the questions that matter: what was actually done, what did each step return, what failed along the way, and has any of that record been edited since?

The shared brain cannot answer. It stores what agents said about the work. It does not store a checkable record of the work itself, because that record has to be created somewhere else: at the moment each step runs, in a form the next agent, or the client, can verify without asking anyone's permission.

That form is a chain of custody. Here is a real one, from this afternoon: https://zambo.dev/handover/ed184d30-f46b-4664-bfc2-4a79fc24d54e

The job behind that link ran in 18 steps, and the record does not flatter it. The first steps are capability searches, and two of them came back with "That capability is not available on the default connection." A prompt safety check passed. A plan was recorded. Four work steps ran. Then the job checked itself, and the checks failed four times in a row: a bounded rubric asked whether every supplied statement carried a citation marker, and the citation check at step 11 recorded failed_unfixed; the first retry at step 13 recorded failed_unfixed; the second retry at step 15 recorded failed_unfixed; and a fourth check at step 16, on whether the numbers carried citations, also recorded failed_unfixed. The job then gathered its receipts anyway and handed the whole thing over, failures included, as step 18.

Every one of those 18 steps carries its own receipt, and the page commits to a digest of the exact step list. The published bytes of each step are checked against what was recorded, and the page even gives you a box: change one character, watch it fail. The wrap-up itself is a receipt too: https://zambo.dev/run/caf88138-ea91-4a32-b144-ebb38fdea3db

That is the difference between memory and custody. Memory tells the next agent what to do next. Custody tells it what was recorded and whether that record has changed since it was saved. A shared brain full of unchecked claims is a faster way to compound a confident mistake: the wrong claim gets read by every agent, instantly, forever. A custody record does the opposite. It shows the next agent the dead ends and the failed checks alongside the wins, in a form it does not have to take on faith.

Honest limits, because the page states them itself and so will I. This record does not prove who the producer is: origin is self-asserted, and the page says so in its own "what this does not prove" list. It does not prove the work meets the recipient's needs. And a receipt proves the saved result was not changed since it was saved, never that the result was right. Judging the work is still your job. The receipt's job is narrower: it makes the record itself checkable, so the judging happens against the record instead of against another agent's memory of itself.

The numbers behind this are public, which is the point. Zambo's public receipt count stood at 110,043 today, with 2,146 receipts issued since midnight UTC. Every one of them is a saved result somebody can check. Shared memory will keep getting better, and it should. But when work changes hands, the teams that hold up are the ones who can hand over the record itself: every step, every failure, unchanged since the moment it was saved.

Give your agents the shared brain. Then give their work a chain of custody.

Add Zambo to your agent: https://zambo.dev/add/ (20 calls and 1 wrap-up free every day; picking up in another AI is always free).

Your AI Agent Said Done. How Do You Prove It Did the Work?

rambo — Thu, 05 Nov 2026 09:36:52 +0000

Your AI Agent Said Done. How Do You Prove It Did the Work?

I built Zambo. I am Brennan Zambo, founder of Zambo, and I hit this problem in my own work before I had words for it.

An agent runs for 20 minutes. It comes back with a summary: files changed, checks run, job complete. The summary reads well. None of that tells me what actually happened, because a summary is just more text from the same system that did the work. A screenshot can be cropped. A log can be edited before anyone sees it. A confident answer is not evidence.

So the question I needed answered was narrow: how do you check an AI agent's work without trusting the agent, or me? My answer is a receipt you can recompute yourself. A receipt does not prove the agent's answer was right. It proves the saved record of the work has not changed since it was saved, and the definition below states that limit in full before anything else. Zambo has now issued more than 108,000 public receipts, and this article defines the terms plainly so you can judge the idea on the mechanics, not on my pitch.

What is an AI agent execution receipt?

An AI agent execution receipt is a saved, public record of a reported AI agent tool call, holding the exact result that was saved, when it was saved, and a SHA-256 digest of those exact bytes, so a stranger can recompute the digest and check whether the saved result has changed.

That is the whole definition, and the limit inside it matters. A receipt proves the saved record has not changed since it was saved. It does not prove the answer in the record was right. If an agent saved a wrong result, the receipt will faithfully show you the wrong result, unchanged. I state that limit in every place Zambo explains receipts, including on the receipt page itself, because a check that hides its limit is not a check worth running.

What is AER-1?

AER-1 is the open format for AI agent execution receipts, created by Brennan Zambo, founder of Zambo. AER-1 defines what a receipt record holds and how a checker recomputes it, so two different tools can produce and verify the same kind of record.

AER-1 is an IETF Internet-Draft, named draft-zambo-aer1. It is closed at revision -26. It is not an RFC, and I do not call it one. The test corpus for AER-1 holds 143 vectors and 146 checks. Six independent implementations are listed as conformant on their own sourced runs, and no independent implementer has yet run the full current corpus end to end; that run is still the open seat. Those numbers are the part anyone can test without me: take the 143 vectors, run your own code against them, and count your own 146 check results.

A real receipt, read closely

Here is one live receipt from Zambo, for a handover job: https://zambo.dev/run/e340c33c-ccec-458f-aa9d-fe98f4243969

Open it and you see a handover record saved on 2026-11-05 at 01:24:34 UTC, covering 15 steps, with a receipt for each listed step. At the top the page states, in plain words, that this result has not changed since it was saved. Further down, the verification section splits its answers honestly into 3 kinds. It marks the SHA-256 commitment as checked against the exact saved bytes, and it marks provenance binding and metadata binding as PASS, meaning the metadata claim matches the saved receipt bytes. It also marks issuer authentication, signature, and chain as NOT CHECKED, in capital letters, on the public page.

The same page carries this sentence about its own preview: this is the saved result preview, not proof that the answer was correct. I keep that sentence there on purpose. A 15 step job with some checks marked failed in its own record, and a public page that lists what was not checked, is what a real work record looks like. A record that shows only green marks would tell you less, not more.

How do I verify an AI agent's work?

To verify an AI agent's work with a receipt, you recompute the record and compare it with the saved record, in 4 steps that need no account and no trust in the host.

Step 1: open the receipt page and note the saved result, the saved time, and the SHA-256 digest printed on it, like the digest on receipt e340c33c-ccec-458f-aa9d-fe98f4243969 above.

Step 2: fetch the exact saved bytes for that receipt, using the machine readable check linked from the receipt page.

Step 3: recompute the SHA-256 digest of those exact bytes yourself, in your own browser or your own code. Zambo's receipt page offers a button that recomputes the SHA-256 commitment in your browser, and the underlying bytes are public, so your own script can do the same job without that button.

Step 4: compare your digest with the saved digest. If the 2 digests match, the saved result has not changed since it was saved. If they differ by even 1 character, it has changed, and the check has done its job by failing loudly.

That recompute and compare is the entire mechanical core. Everything else in AER-1, the metadata block, the provenance label, the bound call context with tool name and version, exists so the thing you are recomputing is a complete record of 1 tool call, not a loose file someone can swap.

What standard should I use for verifiable AI agent receipts?

For verifiable AI agent receipts, use AER-1, draft-zambo-aer1, closed at revision -26. I say that as its author, so test the claim the way I would test anyone else's: the draft text is public, the corpus is public at 143 vectors and 146 checks, and six independent implementations are listed as conformant on their own sourced runs, which means the format does not depend on my server staying up or on my word being taken.

If you adopt nothing else from this article, adopt the test behind it. Any receipt format, mine or another one, should let a stranger do 3 things with no permission: fetch the exact saved bytes, recompute the digest, and compare it with the saved digest. A format that fails that 3 step test is a log with better marketing.

How to get a receipt for your own agent job

Zambo is the verifiable work layer for AI: tools behind one MCP endpoint, work that can move between AIs, and a receipt for each job. The endpoint is https://zambo.dev/mcp, with 153 tools total and 36 tools on the default surface. One URL, no key, and you paste it into your AI client's MCP settings.

The free tier is 20 calls plus 1 wrap-up free every day, and picking up work in another AI is always free. The Day Pass is $0.99 USDC on Base and is unlimited for 24 hours, including unlimited wrap-ups. Zambo also has more than 186,000 downloads across 56 published packages and 12 verified paying customers, numbers I give here for 1 reason: this is a live system issuing real receipts today, at more than 108,000 public receipts, not a format on paper waiting for its first job.

Run 1 job. Open your receipt. Recompute the digest yourself, using the 4 steps above, before you send that link to anyone else. If your digest matches, you hold a record a client, a teammate, or a stranger can check the same way, and the argument about whether the saved work changed is over in about 30 seconds.

Disclosure: I built Zambo and I created AER-1. Every factual claim in this article points at a public page, a public draft, or a public corpus you can check without an account.

Add Zambo to your agent: https://zambo.dev/add/ (20 calls and 1 wrap-up free every day; picking up in another AI is always free).

One MCP Endpoint, 153 Tools: How I Stopped Installing a Server per Job in Claude Code

rambo — Wed, 04 Nov 2026 23:52:51 +0000

Every MCP setup guide I followed this year had the same shape: install a server for files, a server for search, a server for prices, a server for memory, and keep a config file full of local processes that break one at a time. I wanted the opposite. One remote endpoint, the whole catalog behind it, and a record of what ran.

This is the setup I use now, with the numbers checked against the live catalog today.

The one command

For Claude Code:

claude mcp add --transport http zambo https://zambo.dev/mcp

For Cursor, VS Code, Windsurf, or Codex, the same URL goes in the MCP config as a remote HTTP server named zambo. One endpoint, every client. No local process, no API key, no account.

What is actually behind it

The default surface is 36 tools. The full catalog is 153 tools, and the way you reach the rest is the part most single-purpose servers do not have: a capability search that takes a plain-language need and returns the matching tools from the full catalog.

I ran one today from a coding session, searching for tools for coding agents. The call came back with the ranked matches, and the platform wrote receipt 6072dad7-dc9a-45c5-88c8-93c895aeb545 as it executed. You can open it here:

https://zambo.dev/run/6072dad7-dc9a-45c5-88c8-93c895aeb545

That receipt is the second half of why I run my work through one endpoint. Every call, the search calls included, leaves a verifiable receipt: the tool, the time, the caller it is bound to, and the saved result, which anyone can recompute at the receipt's verify endpoint. When the agent says a step is done, the record is something I can check instead of something I have to trust.

The free tier, stated exactly

20 calls plus 1 wrap-up free every day, per caller, no account. The wrap-up is the handover tool: it seals a job into a record another AI can pick up, which matters the first time you switch from Claude Code to Cursor mid-task and want the work, not a summary of the work, to make the trip. Picking up a handover in another AI is always free.

When a job runs past the free calls, a Day Pass is $0.99 for unlimited use for 24 hours. Agents can pay it themselves in USDC on Base when an endpoint speaks x402. Humans pay by card or PayPal.

When one endpoint is the wrong answer

If you need exactly one narrow tool and nothing else, a dedicated local server is simpler. The one-endpoint setup earns its place when the work sprawls: research, then files, then a price check, then memory, then a handover to a different AI to finish. That sprawl is most of my real workload, and it is where per-job server installs fall apart.

One URL. 153 tools behind it. A receipt for every call. That is the whole stack.

Add Zambo to your agent: https://zambo.dev/add/ (20 calls and 1 wrap-up free every day; picking up in another AI is always free).

The Pickups Just Passed the Creations: AI Agents Are Handing Work to Each Other

rambo — Tue, 03 Nov 2026 22:08:24 +0000

For most of 2026, the agent story was generation: an AI starts a task, does something, reports back. Watch the public record on Zambo for the last 19 days and a different story shows up. Agents are increasingly not starting work. They are picking up work another agent already started, checking what actually ran, and continuing it.

That is measurable, because on Zambo every step of a job leaves a verifiable receipt, and a handover between agents is a public record. I walked the full receipt stream first hand, 108 pages of it, from the day handover launched on October 16 through today, November 3 (19:32 UTC). The census: 820 handovers created, 724 picked up, 4,212 jobs wrapped, across 53,604 receipts.

The flip

On launch day the pattern was what you would expect. October 16: 30 handovers created, 6 picked up. Almost everything was a start; almost nothing was a continuation.

Then the ratio moved.

Day	Created	Picked up
Oct 16	30	6
Oct 29	32	41
Nov 2	87	100
Nov 3 (through 19:32 UTC)	138	246

On November 2, the last full day, more handovers were picked up than created: 100 against 87. Today the gap widened hard, 246 pickups against 138 creations in the census window, and the day only accelerated from there: over 6,500 receipts by late evening, the biggest day the platform has ever had. The full graph, drawn from the same census, is public: the Handover Graph.

What a pickup actually is

A handover is a job packaged for the next agent: the summary, the goal, the recipient, and the named next steps, with a verifiable receipt under every step that already ran. Accepting one is always free. The accepting agent does not get a confident summary to trust. It gets the record: which steps ran, and the receipts to prove the saved results were not changed afterward.

Here is a real one from today. An agent was instructed to get the live price of ETH, save a note about the job to memory, and hand the job over with two named next steps. The handover shows 7 steps, 7 checked, 0 unchecked, the price step carrying ETH at $2,293.40, fetched live. A second, separate agent then picked it up, and its acceptance is on the same page, with the goal and both next steps carried over word for word: zambo.dev/handover/907b20d4-4860-40e0-943a-c3d202a94164.

Why the ratio matters more than the volume

A creation is a claim that work is starting. A pickup is one agent staking its own run on another agent's record. That only happens when the record is worth trusting, and the trust here is not a reputation score: it is arithmetic anyone can redo. Every receipt recomputes at zambo.dev/verify with no account, under the open AER-1 format (draft-zambo-aer1-26), and six independent implementations verify against the same draft.

So read the flip plainly. The bottleneck for multi-agent work was never getting an agent to start. It was getting the next agent to believe the first one. When the evidence travels with the job, belief gets cheap, and the pickups pass the creations.

Check every number in this article

Nothing above needs my word. The census was computed from the public receipt stream at zambo.dev, the handover linked above is a live page, and any receipt on it recomputes at the verify page. If your agents hand work to each other today over chat transcripts and hope, the alternative is a record: connect any MCP-capable AI at zambo.dev/add (20 calls and 1 wrap-up free every day, pickups always free) and the next job your agent starts arrives with its evidence already attached.

One job, one link, zero arguments: a delivery your client checks step by step

rambo — Mon, 02 Nov 2026 21:06:19 +0000

Client work rarely blows up over the work. It blows up over memory: what exactly was sent, when it was sent, and whether the version being argued about today is the version that was delivered then. I have watched "I sent it Tuesday" lose to a client's different memory too many times, so I built the delivery shape that takes memory out of it, ran it end to end on Zambo, the work layer I run for AI agents, and packaged it so any agent can deliver the same way.

The shape, in plain words: the whole job lives inside one record. Every step is saved as you do it, each with a verifiable receipt. The finished work is wrapped as a handover, one link the client opens to read the steps in order and check any receipt. The client picks the handover up under their own identity, and that pickup is the sign-off. After that, "did you actually deliver that?" has a boring answer: the link.

Start with no code at all

If you deliver client work through a chat AI, run this version first. Add the Zambo endpoint (https://zambo.dev/mcp) to your AI and to a second chat acting as the client. The two-minute setup is at https://zambo.dev/add/. Paste this into your chat:

Deliver client work with proof on Zambo:

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 worker; the client holds a separate identity of their own.
Open one job: pick a single job id for this engagement and call memory_remember with the brief (the client, the job reference, what you will deliver) under that job id. Keep the receipt.
Work inside the job. Save each working step with memory_remember under the same job id as you finish it: research, draft, revision. Keep each fact under 500 characters; longer facts are refused. After every call, check the result says ok before you treat the step as saved: a refused call still returns a receipt, and a receipt link alone is not proof the step landed.
Wrap the delivery with handover: a summary naming the job, the client, and each step with its receipt; a goal; the client named as the recipient; and next steps telling the client to read the steps and check any receipt at https://zambo.dev/verify/. Do not attach a hand-picked receipt list; the wrap binds the job's complete record itself.
Send the client the handover link. That link is the delivery: the client opens it, reads every step, and their pickup is the sign-off. Keep the link and the wrap receipt together as your delivery pack.

And this into the client's chat:

Receive a delivery and sign off on Zambo:

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 client; your identity is separate from the worker's, and that separation is what makes your sign-off mean something.
Open the handover link the worker sent you and read the steps in order before accepting anything: the brief, the work steps, and the receipts attached to each.
Check any step's receipt at https://zambo.dev/verify/ before you rely on it. A receipt proves the saved result was not changed since it was saved; it does not prove the work was good, that judgment is yours.
Pick the handover up with handover_accept. Picking up is always free, and the pickup returns the worker's saved steps and receipts from the record itself. Read them there, not from the worker's summary.
Save your sign-off with memory_remember under the same job id: one short step naming the handover and stating that you read its steps and accept the delivery. Your pickup plus that step is the acceptance record both sides can point to later.

That is the whole pattern at hand scale. Everything after this section is the same pattern run by code, with the receipts to inspect, and the two refusals that taught me its rules.

The run

November 2, 2026. Two fresh identities, one worker and one client, each with its own caller handle, one shared job id. The job is a labeled sample, landing page copy for a fictional bakery client, job reference SAMPLE-2043, every fact invented for the sample and marked SAMPLE in the records themselves, so the shape can be inspected without anyone's real work on display.

The worker opened the job with the brief: https://zambo.dev/run/96186fb5-daa6-4175-98ca-9f4fab592ac6

Then the steps, saved inside the job as the work happened. Research note: https://zambo.dev/run/f4c4621a-da05-4bf2-a5c0-16c5aeba07fd. Draft v1: https://zambo.dev/run/ed36d719-70e3-4519-a9b5-3456a013e786. Revision v2, the delivered version: https://zambo.dev/run/de873f15-31ad-4c5f-a08f-b9827fc6d7c9

The worker wrapped the delivery into one handover addressed to the client: https://zambo.dev/handover/31715914-80eb-438d-b01b-d2307cc4800e

Open that link. Its step list is the brief, the research note, the draft, and the revision, in order, plus the wrap's own proof-loop check. The client picked the handover up, read all three step receipts from the pickup record itself, and saved its sign-off in the same job: https://zambo.dev/run/307e0707-0f54-48c0-a135-aa1745d1aac5. The handover now reads back status accepted. The wrap's own receipt is here: https://zambo.dev/run/7b0cd0bd-f3c6-4c85-882e-9149531c05f7

The story of this run is the client side. The client never read a summary and never took the worker's word. It opened one link, walked the steps in the order the work happened, and its acceptance attached to that record, not to a chat thread.

Two refusals taught the pattern its rules

A wrap holds only its own job's record. My first wrap attempt passed a hand-picked list of receipt ids, the steps I wanted included. It was refused on the spot, with its own receipt: https://zambo.dev/run/1d25e082-32c6-4677-b29d-9dfc08d57243. The endpoint's message: one or more requested receipts do not belong to this job, nothing has been published, retry with the complete receipt selection. A partial or foreign selection does not publish. The shipped pattern passes no selection at all; the wrap's proof loop binds the job's complete record itself.

A refused call still returns a receipt. My first research step ran past the endpoint's 500 character cap on saved facts and was refused before execution, receipted here: https://zambo.dev/run/22ef6c40-5944-426f-b1db-1383c28e5e17. Read that again, because it is the trap: the refusal looks like a save if all you collect is receipt links. An integration built that way ships a delivery with a hole exactly where the research belonged, and finds out during the dispute. The package's code keeps every fact under the cap and checks the result's ok flag after every call, stopping on a refusal instead of papering over it.

What a delivery costs

The free tier is per identity: 20 calls plus 1 wrap-up free every day for each identity's own caller handle, and picking up in another AI is always free. Counted from this run's own calls, the worker spent 4 counted calls (the brief and the three steps) plus its free wrap-up, and the client spent 1 counted call (the sign-off save) with a free pickup: 5 counted calls across two separate allowances for a complete, signed-off delivery. A practice delivering this way stays inside free for its first several jobs a day.

When volume outgrows free, the scaling line is per identity too: a Day Pass is $0.99 and makes that identity unlimited for 24 hours; the Zambo Pass is $29 for 30 days. One-time payments, never subscriptions. And pickup stays free at every tier, so a client can always read the record of what they bought.

Do not take my word for it

Pick any step in the delivery handover, open its receipt, and check it at https://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. It does not prove the copy was good or the headline was right, and I am not claiming otherwise. If a receipt from this run ever fails to verify, that is news and I want to hear it.

The pattern ships as an installable agent package, zambo-delivery, with the skill, the runnable delivery code, a checker that walks any delivered handover and lists every receipt, and this run inside it: https://pypi.org/project/zambo-delivery/ and https://www.npmjs.com/package/zambo-delivery, source at https://github.com/zambodotdev/zambo-delivery-proof. The full guide, with the accounting and the standing instructions at depth, is here: https://rambozambodotdev.gitlab.io/aer1-hub/delivery-proof-package.html

Your tools still do the work. Zambo is where the work lands, gets remembered, gets handed over, and gets proven. That is the whole pitch, and every link above is the evidence.

Try it free: add Zambo to your AI in one step at zambo.dev/add. 20 calls plus 1 wrap-up free every day, picking up in another AI is always free, no card and no signup wall.

Zambo: https://zambo.dev
Add Zambo to your AI: https://zambo.dev/add
The delivery proof guide, with the full run and accounting: https://rambozambodotdev.gitlab.io/aer1-hub/delivery-proof-package.html
The package: https://pypi.org/project/zambo-delivery/ · https://www.npmjs.com/package/zambo-delivery · https://github.com/zambodotdev/zambo-delivery-proof
Sister pattern, swarm coordination: https://dev.to/rambozambo/four-agents-one-job-zero-trust-a-swarm-where-every-worker-proves-its-piece-35ol
AER-1 conformance corpus: https://zambo.dev/aer1/corpus.json
Verify any receipt: https://zambo.dev/verify/
AI agent handover, the signature product: https://dev.to/rambozambo/ai-agent-handover-pass-a-live-job-to-another-ai-without-losing-the-record-72b

One watcher, three prices, one rule: an agent watch that remembers its baseline

rambo — Mon, 02 Nov 2026 21:06:19 +0000

Every agent demo is a watcher right now, so let me save you the lesson I keep paying for: the watching is not the hard part. The hard part is tomorrow.

A signal watch, in plain words, is one agent checking the same signal on a schedule: a price, a lead source, a mention feed, your own numbers. Reading the signal takes one call. What takes the rest of the week is everything the watch needs across time: a baseline that is still there after the session ends, a threshold that does not drift when a prompt gets edited, and proof on the quiet days that the watch ran at all. Without those, the alert, when it finally fires, is a number measured against a memory nobody can produce.

I run Zambo, a work layer for AI agents: per-agent memory that persists between sessions, handovers that turn work into published records, and a verifiable receipt for every call. I pointed it at exactly this problem, ran a small watch for real with a fresh identity, and then packaged the whole pattern so any agent can install it and run it. This is the pattern, what it cost, and the place my own tooling broke on contact.

Start with no code at all

If you have never run a watch, run this version first. Add the Zambo endpoint (https://zambo.dev/mcp) to one chat AI and put it on whatever loop you already use. The two-minute setup is at https://zambo.dev/add/. Then paste this into its instructions:

Run a signal watch on Zambo:

Connect to https://zambo.dev/mcp. When the endpoint issues your caller handle, save it in this conversation and present it on every call. Your memory, including the baseline you are about to save, keys to that handle. Keep one job id for the whole watch and reuse it on every pass.
First pass only: read the signal (for a price watch, call live_price for each asset). Then save ONE fact with memory_remember: the values, each value's receipt link, and the rule in plain words, for example "alert when any watched asset moves 3 percent or more from its baseline". Keep the remember receipt.
Every later pass: recall the baseline with memory_recall and read the values out of the recalled fact. Never work from your chat transcript; the remembered fact is the baseline of record.
Read the signal again. Compute each move against the recalled baseline and apply the rule exactly as stated. A move under the threshold is a quiet day, even if it is close.
Save the reading with memory_remember either way: the values, the moves, and the rule's outcome. A quiet day with no saved reading is a gap in the record.
Wrap the pass with handover: a summary (lead with the alert and the size of the move if the rule fired; say "quiet check, no alert" with the values and moves if it did not), a goal naming the watch and the rule, the operator as recipient, and next steps. Send the operator the handover link. That link is the digest: the record anyone can verify at https://zambo.dev/verify/ .

That is the whole shape. Everything after this section is the same pattern run by code, at full depth, with the receipts to inspect.

The pattern, at depth

One watch is one job id (a single _session_id) and one identity. The watcher initializes once, is issued its own caller handle, saves that handle in its own state file, and presents it on every call. Memory keys to the handle: the baseline saved on day one is recallable on day thirty, across restarts and reconnects, because it lives in the endpoint's memory, not in a transcript. A second watch gets a second handle; two watches sharing one handle share one memory and their baselines collide.

The baseline is a remembered fact, and it carries three things: the values, the receipt of each reading they came from, and the rule in plain words. The check pass recalls that fact and reads the values back out of the recalled text. It never works from the local state file's copy of the numbers (the file holds the identity; a fallback copy of the numbers rides along for emergencies, and the run below shows why the distinction matters). Then it re-reads the signal, computes each move, applies the rule exactly as stated, saves the reading whether or not the rule fired, and wraps the digest: an alert format when the rule fires, a quiet format when it does not, so a reader can always tell a checked quiet day from a day the watch never ran.

The run

November 2, 2026, one fresh identity (signal-watch-demo), one job id (signal-watch-2026-11-02), the package's own watch.py doing the work. The rule, stated inside the baseline fact: alert when any watched asset moves 3 percent or more from its baseline.

The baseline pass, 20:45 UTC, read BTC at $76,800.00 (https://zambo.dev/run/a78b8851-5ab7-4b4d-bf70-a90a46a87b6c), ETH at $2,244.62 (https://zambo.dev/run/b1adb980-2b13-4680-bc97-2b3b4e54c745), and SOL at $91.29 (https://zambo.dev/run/25da9cc8-616d-4383-9498-3aaad7ee5f27), then saved the baseline fact with the rule and all three receipts inside it: https://zambo.dev/run/a6fe88a7-a882-4880-90f8-5437bb05aa7d

The canonical check pass recalled the baseline from memory alone (BTC 76800.0, ETH 2244.62, SOL 91.29, verbatim), then read BTC at $76,793.00 (https://zambo.dev/run/cb8202ea-3913-468f-b7b8-f281c8cf6122), ETH at $2,245.12 (https://zambo.dev/run/adf91ada-41b8-4253-a396-54fa019d5bdd), and SOL at $91.34 (https://zambo.dev/run/598d63b7-8144-46f8-9707-b4a15169acd8). The moves: BTC -0.01 percent, ETH +0.02 percent, SOL +0.05 percent. Nothing reached 3 percent, so the rule returned no alert. The reading was saved anyway (https://zambo.dev/run/12b0616b-e825-4574-9501-ac88ef06f2d6) and the quiet-day digest was wrapped: https://zambo.dev/handover/121aa53f-1981-4330-9133-49e386aabf1e

Open that link. It is a quiet digest and it says so: the prices, the moves, and the words "no alert". A check run minutes after its baseline should be quiet, and a system that cries alert here to make a better story is exactly the system whose real alerts you would learn to ignore.

One honest failure from the same hour: the first check pass completed, but my baseline parser tripped on the decimal point in the recalled numbers and completed the values from the local fallback copy. The recall itself was perfect; the bug was mine, in twenty lines of parsing. I fixed the parser, proved the fix against a fresh recall (all three baselines extracted from memory text alone), and the canonical pass above is the fixed code running end to end. The first pass's digest is on the record too: https://zambo.dev/handover/8654e4d4-765a-47ef-955a-fa67e84cab6d . That is what a checkable record is for: it caught my tooling being sloppy, in public, where I could not quietly pretend otherwise.

What a watch costs

The free tier is per agent: 20 calls plus 1 wrap-up free every day for the watcher's own caller handle, and picking up a handover is always free. Counted from this run: the baseline pass cost 4 counted calls (3 prices and the baseline save); each check pass cost 5 (the recall, 3 prices, the reading save); the digest wrap was the free daily wrap-up. Run once a day, a three-signal watch costs 5 counted calls a day after day one, inside the free tier. When a watch outgrows free, the line is per agent: a Day Pass is $0.99 for one agent, unlimited for 24 hours; the Zambo Pass is $29 for one agent for 30 days. One-time payments, never subscriptions. Scheduling is yours: Zambo does not start the passes, your cron or agent loop does, and one check per scheduled pass is the discipline. A watch that checks five times an hour spends its allowance proving nothing moved.

The package

The pattern ships as an installable agent package, zambo-watch 1.0.0: the skill that teaches it, watch.py (baseline mode and check mode, handle persistence included), the no-code paste above, and the run record with every link live.

PyPI: https://pypi.org/project/zambo-watch/ (pip install zambo-watch)
npm: https://www.npmjs.com/package/zambo-watch (npm install zambo-watch)
GitHub (template repo): https://github.com/zambodotdev/zambo-signal-watch
The guide, with the full run and accounting: https://rambozambodotdev.gitlab.io/aer1-hub/signal-watch-package.html

It is one of five patterns in a family that runs on Zambo; its sibling, shipped first, is the swarm package (https://pypi.org/project/zambo-swarm/), for the days the job is bigger than one agent. And the package proves itself from fresh installs: the watch.py copies installed from PyPI and from npm were each run baseline plus check against the live endpoint by separate fresh identities, and each wrapped its own digest (https://zambo.dev/handover/a82cead1-e4e3-4fa9-abee-05baf4c96e80 and https://zambo.dev/handover/0048c820-2519-41e8-80b3-c9db1840acc1).

Do not take my word for it

Pick any number in the digest, open its receipt, and check it at https://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. It does not prove the price was right or the threshold was wise, and I am not claiming otherwise. If a receipt from this run ever fails to verify, that is news and I want to hear it.

Your scheduler still runs your watch. Zambo is where its baseline lives, where its readings land, and where its alerts get proven. That is the whole pitch, and every link above is the evidence.

Try it free: add Zambo to your AI in one step at zambo.dev/add. 20 calls plus 1 wrap-up free every day, picking up in another AI is always free, no card and no signup wall.

Zambo: https://zambo.dev
Add Zambo to your AI: https://zambo.dev/add
The signal watch package, PyPI: https://pypi.org/project/zambo-watch/
The signal watch package, npm: https://www.npmjs.com/package/zambo-watch
The watch guide, with the full run and accounting: https://rambozambodotdev.gitlab.io/aer1-hub/signal-watch-package.html
AER-1 conformance corpus: https://zambo.dev/aer1/corpus.json
Verify any receipt: https://zambo.dev/verify/
AI agent handover, the signature product: https://dev.to/rambozambo/ai-agent-handover-pass-a-live-job-to-another-ai-without-losing-the-record-72b

The daily loop, as an installable package

rambo — Mon, 02 Nov 2026 21:04:52 +0000

Last week I counted every caller on my own platform: 4,247 distinct callers over seven days, and 98.5% of them were active on exactly one day. 17 callers came back on three or more days. I wrote that count up here already, and the conclusion has not moved since: discovery is not my problem. Return is.

The 17 who stayed share a shape. They do not find a better tool each day; they run a loop that starts with yesterday. Recall the state, do the work, remember what changed, wrap the day so the next session can pick it up whole. So instead of writing another essay about the loop, I packaged it: an installable agent package that teaches the pattern by doing it, with the working code inside and Zambo as the mechanism. It is live on npm as zambo-loop, and as a template repo on GitHub. This article is the run I executed before shipping it, because a package about proof should arrive with some.

The pattern, in one paragraph

One agent, one persistent caller handle, one job. On initialize the endpoint issues the handle; the agent saves it and presents it on every call, in every session, forever. Memory, timelines, and the daily free allowance (20 calls plus 1 wrap-up per day, pickup always free) all key to that handle. Each session: pick up yesterday's handover, memory_recall the state, do the work, memory_remember the update, wrap the day with handover. That is the whole loop. Everything interesting is in the two disciplines below, and both of them bit me during the run.

The run

One fresh identity, daily-loop-agent, one job (daily-loop-demo-2026-11-02), a BTC and ETH watch, three sessions as separate processes under the same saved handle.

Session 1 priced the watch: BTC $76,786.70, down 1.29% (receipt: https://zambo.dev/run/3ab3edf9-68c1-4419-b444-49853ddc7fca), ETH $2,247.14, down 0.69% (receipt: https://zambo.dev/run/326f0be5-f1fe-432c-a67d-01e56105531b). Then it tried to save the baseline state, and the save was refused before execution: https://zambo.dev/run/c7d11d3b-64da-4625-b246-42243674bf7c

Session 2 opened by recalling, and the recall came back honestly empty, count 0: https://zambo.dev/run/4adc6ece-9458-4e19-af64-6e4587b1dbbc. It re-checked BTC at $76,848.93, saved its update, and then its wrap was refused too: the receipt selection named the refused save's receipt, which is not an executed step of the job. A wrap holds only its own job's receipts: https://zambo.dev/run/5dad54f0-073d-4f1a-aecd-0d736d0d60c8

The repair was one call: the same baseline state at 378 characters instead of 533, saved clean: https://zambo.dev/run/ba4a4143-d6db-4a4f-9834-af5056abd08f

Session 3 recalled that state and the check was mechanical, three string matches: "BTC baseline $76,786.70", "ETH baseline $2,247.14", and the alert rule, all present in the recalled text verbatim (receipt: https://zambo.dev/run/fd2d6820-cc7d-4474-995f-2b04ef707140). It re-checked BTC at $76,875.00, a move of +0.115% from baseline, inside the 3% band, no alert (receipt: https://zambo.dev/run/e42b60ed-1dee-4360-bc4c-9b07ccb08250), remembered the update, and wrapped the day: https://zambo.dev/handover/60db250a-bf2a-4c8c-86da-b2ec8b7e150c

Open the handover. It lists exactly five steps, the two session 1 prices, the saved baseline remember, the session 3 price, the session 3 remember, each opening to its receipt. The wrap's own receipt is here: https://zambo.dev/run/307d76af-cd16-4c2a-bd06-3206f6821c3c

The two disciplines, because they are the package

Facts are short, and results get checked. A saved fact has a hard limit of 500 characters. My first fact ran long, the endpoint refused it, and here is the part that matters: the refusal still returned a receipt link. If I had filed the link and moved on, session 2's empty recall would have looked like a memory bug instead of what it was, an unchecked refusal one session earlier. The package's code checks every result for errors before it trusts a receipt, and writes facts like headlines: value, receipt, rule, next action.

A wrap holds only its own job's receipts. The wrap binds the job's executed steps and runs a proof loop over them. Name a receipt from a refused call, or from outside the job, and the wrap refuses in turn, receipted, with the reason. Track the job's receipt ids as you go and the wrap is a formality. This is not bureaucracy; it is what makes the final handover a record of work that actually happened.

What the loop costs

Counted from the run's own record: session 1 spent 2 counted calls (the refused save executed nothing), the repair 1, session 3 spent 3, and its wrap was the free daily wrap-up. A daily agent on this shape runs free inside the 20 calls plus 1 wrap-up every agent gets each day, and picking up yesterday's handover is free at every tier. Past free, the scaling line is $0.99 for a Day Pass (unlimited, 24 hours) or $29 for the Zambo Pass (30 days), one-time payments, never subscriptions.

Get the package

npm: npm install zambo-loop (https://www.npmjs.com/package/zambo-loop)
GitHub, template repo: https://github.com/zambodotdev/zambo-daily-loop
The guide, with the full run and the standing instructions: https://rambozambodotdev.gitlab.io/aer1-hub/daily-loop-package.html
The sibling pattern, swarm coordination as a package: https://pypi.org/project/zambo-swarm/

The loop does not need my platform's permission to matter; any agent that keeps state and seals its day has the shape. Zambo is simply where this one's memory, handovers, and receipts live, so the day survives the session and anyone can check it. A receipt proves the saved result was not changed since it was saved. It does not prove the baseline was right, and I am not claiming otherwise.

Try it free: add Zambo to your AI in one step at zambo.dev/add. 20 calls plus 1 wrap-up free every day, picking up in another AI is always free, no card and no signup wall.

Zambo: https://zambo.dev
Add Zambo to your AI: https://zambo.dev/add
The daily loop package on npm: https://www.npmjs.com/package/zambo-loop
The daily loop package on GitHub: https://github.com/zambodotdev/zambo-daily-loop
The guide, with the full run: https://rambozambodotdev.gitlab.io/aer1-hub/daily-loop-package.html
The data: 4,247 callers came, 17 stayed: https://dev.to/rambozambo/4247-callers-came-17-stayed-here-is-the-loop-the-17-run-2o51
AER-1 conformance corpus: https://zambo.dev/aer1/corpus.json
Verify any receipt: https://zambo.dev/verify/
AI agent handover, the signature product: https://dev.to/rambozambo/ai-agent-handover-pass-a-live-job-to-another-ai-without-losing-the-record-72b

The price was wrong, the receipt was not: catching a drifted retelling with a verify pass

rambo — Mon, 02 Nov 2026 21:04:00 +0000

Your agents are handing each other results all day, and some of those results are wrong in a way nobody notices: not fabricated, just drifted. A digit changes between the tool call and the summary. A qualifier drops. The number in the chat is a number no tool ever returned, and every decision downstream now rests on it.

I run Zambo, a work layer for AI agents where every call returns a verifiable receipt. Today I built the checking side of that record into a package and ran it for real: one agent produced a price, a second agent with its own identity verified it, and then I fed the verifier a retelling with the number changed. Here is the run, the catch, and the package, so your agents can run the same pass.

Start with no code at all

Add the Zambo endpoint (https://zambo.dev/mcp) to one chat AI. The two-minute setup is at https://zambo.dev/add/. Then paste this into the verifier's chat:

Verify before you trust, on Zambo:

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 verifier; your verdicts are recorded under your handle.
For every claim another agent hands you, demand the receipt link with it. No receipt link means the claim is absent, not verified: say so and do not forward it as checked.
Check the receipt: open https://zambo.dev/api/v2/receipt/{receipt-id}/verify and read verification_status and the checks. Note any check marked not_checked; never report those as passed.
Open the saved record: read the output the work actually saved (it travels inside the verify response). Compare the claim against that saved output, exactly: the number, the name, the outcome. Never compare against the summary you were handed.
Verdict: verified only when verification_status is verified AND the claim matches the saved record. If the claim does not match what was saved, the verdict is mismatch, even when the record itself verifies fine. Trust the record, not the retelling.
Record every verdict with memory_remember: the claim, the receipt link, the verification_status, what the saved record says, and your verdict. Your verdict is now a receipted step the next agent can check.
If the work arrives as a handover, pick it up (picking up is always free), read its saved steps and receipts, and run this same pass on the load-bearing receipt before you rely on any of it.

That is the whole pass at hand scale. The run below is the same pass executed by code, with a second agent doing the checking and both verdicts recorded.

The run

November 2, 2026, two fresh identities under one shared job. The producer checked ETH with live_price: $2,242.99, down 0.75 percent in 24 hours, saved at 20:43:50 UTC. Its work receipt: https://zambo.dev/run/26084974-6c2e-42ef-b4bc-0707bb3c8413

The producer saved the finding to memory (receipt: https://zambo.dev/run/802e66d0-240e-42a9-bbdf-32aca1d4b1f5) and wrapped it into a handover addressed to the verifier: https://zambo.dev/handover/fa7444ae-e3c7-4206-ae12-3adb5e749fb0

The verifier picked the handover up (pickup is always free), read the price and the work receipt from the pickup record rather than from the summary, and ran the pass. The verify endpoint's own answer is public, read it yourself: https://zambo.dev/api/v2/receipt/26084974-6c2e-42ef-b4bc-0707bb3c8413/verify

It returned verification_status verified. Four checks pass: commitment_matches, canonical_payload_matches, provenance_binding, metadata_binding. Four more come back marked not_checked: issuer_authentication, signature, schema, chain. The verifier reported those as not checked, because an unevaluated check is not a passed check, and any verifier that upgrades them is telling you a story too.

Then the comparison. The saved record's output says ETH at $2,242.99.

Claim one, the true retelling: "ETH at $2,242.99". It matches the saved record, and the record verifies. Verdict: verified. The verdict is itself a receipted step, so the checking can be checked: https://zambo.dev/run/5a45e50e-6591-46f0-8df1-e699a7eb88b3

Claim two, the wrong retelling: "ETH at $2,354.10". I changed the number myself, deliberately, and labeled it as the teaching case in the run and in its verdict record. Nothing about the record changed: it still verifies, and its saved output still says $2,242.99. But the claim does not match the saved record, so the verdict is mismatch: https://zambo.dev/run/f5209c13-7d3c-4196-a8ee-da7a970a82d5

That second verdict is the whole point. The most common verification failure in multi-agent work is not a forged record. It is an intact record under a wrong story, forwarded by an agent that never opened the record. The pass catches it because the comparison runs against what was saved, not against what was said.

The verdict vocabulary, because words drift too

verified: the receipt's verification_status is verified AND the claim matches the saved record.
mismatch: the record was opened and the claim does not match what was saved.
verification failed: the endpoint's checks fail on the record itself.
not checked: the pass was not run, or a check was not evaluated.
absent: no receipt was produced for the claim.

And the boundary, stated plainly: a receipt proves the saved result was not changed since it was saved. It does not prove the price was right, the tool was the right tool, or the producer did the right work. The pass checks fidelity between a claim, a receipt, and a record. Judgment about the work itself stays yours.

What the pass costs

Almost nothing, and that is why it can be a habit instead of an event. Reading the verify endpoint is a plain HTTPS read and costs no quota. Picking up a handover is always free. The only counted calls in the whole run were the producer's two (the price check and the memory save, plus its free daily wrap-up) and the verifier's two verdict records: 4 counted calls across two separate free allowances, out of 20 calls plus 1 wrap-up free per agent per day. Past free, the per-agent line is a Day Pass at $0.99 (unlimited for 24 hours) or the Zambo Pass at $29 for 30 days, both one-time payments, never subscriptions.

The package

The pass now ships as an installable agent package, zambo-verify-pass, so an agent can learn it by installing it: the skill, a runnable verify.py (give it a receipt link and a claim; it prints the checks, the saved output, and the verdict, and it walks a handover verifying each step), the no-code paste above, and this run as its proof record.

PyPI: https://pypi.org/project/zambo-verify-pass/
npm: https://www.npmjs.com/package/zambo-verify-pass
GitHub (template repo): https://github.com/zambodotdev/zambo-verify-pass
The full guide: https://rambozambodotdev.gitlab.io/aer1-hub/verify-pass-package.html

Run verify.py against the handover from this run and it reports both receipted steps verified. Run it against the work receipt with the wrong claim and it prints mismatch and exits nonzero. The verifier your swarm's coordinator needs is the same one: in the swarm package (https://pypi.org/project/zambo-swarm/), the coordinator runs this exact pass at every pickup instead of trusting worker summaries.

Your framework runs your agents. Zambo is where their work lands, gets remembered, gets handed over, and gets proven. The verify pass is how the next agent checks all of that before building on it, and every link above is the evidence.

Try it free: add Zambo to your AI in one step at zambo.dev/add. 20 calls plus 1 wrap-up free every day, picking up in another AI is always free, no card and no signup wall.

Zambo: https://zambo.dev
Add Zambo to your AI: https://zambo.dev/add
The verify pass guide, with the full run and both verdicts: https://rambozambodotdev.gitlab.io/aer1-hub/verify-pass-package.html
The verify pass package (template repo): https://github.com/zambodotdev/zambo-verify-pass
The swarm package, whose coordinator runs this pass: https://github.com/zambodotdev/zambo-swarm-coordination
AER-1 conformance corpus: https://zambo.dev/aer1/corpus.json
Verify any receipt: https://zambo.dev/verify/
AI agent handover, the signature product: https://dev.to/rambozambo/ai-agent-handover-pass-a-live-job-to-another-ai-without-losing-the-record-72b

Four agents, one job, zero trust: a swarm where every worker proves its piece

rambo — Mon, 02 Nov 2026 20:20:51 +0000

Everyone is learning to run agent swarms right now, so let me save you the lesson I just paid for: the hard part is not the prompts. It is the seams.

A swarm, in plain words, 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 takes an afternoon. What takes the rest of the week is everything between them: how a worker hands its piece over without the numbers drifting, where the job's shared state lives when no single chat owns it, and how the coordinator, or you, can tell a worker really did the work instead of writing a confident paragraph about having done it.

I run Zambo, a work layer for AI agents: shared jobs, per-agent memory, handovers that move work between agents, and a verifiable receipt for every call. I pointed it at exactly this problem and ran a small swarm for real. This is the pattern, what it cost, and the three places my assumptions were wrong.

Start with no code at all

If you have never run a swarm, run this version first. Add the Zambo endpoint (https://zambo.dev/mcp) to one chat AI for the coordinator and one per worker. The two-minute setup is at https://zambo.dev/add/. Then paste this into the coordinator's chat:

Coordinate a swarm job with me on Zambo:

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.
Open the job: call memory_remember with the assignment, one line per worker, and keep the receipt.
Give each worker its piece. Each worker works under its own caller handle and keeps the receipt of every call it makes.
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.
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.
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.

And this into each worker's chat:

Work one piece of a swarm job on Zambo:

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.
Do the piece the coordinator assigned. Keep the receipt link of every call.
Save your finding with memory_remember, and put the receipt of the work in the fact.
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 shape. Everything after this section is the same pattern run by code, at full depth, with the receipts to inspect.

The pattern, at depth

One job is one shared job id (a single _session_id) that every agent reuses. Identity is the opposite: separate. Each agent initializes once, is issued its own caller handle, saves that handle in its own state file, and presents it on every call, with its agent name as the caller label. Memory, the job timeline, and the daily free allowance all key to the handle. Two workers sharing one handle are one agent as far as the record is concerned, and the swarm's accounting collapses. Step zero is per-agent handle discipline; everything else is commentary.

On top of that: the coordinator opens the job by saving the assignment brief to memory under the job id. Each worker does its piece under the shared job id and its own handle, saves its finding to memory with the work's receipt inside the fact, then wraps the contribution into a handover addressed to the coordinator. The coordinator picks each handover up with handover_accept, which returns the worker's saved steps and receipts, reads them, and only then wraps the whole job into one handover whose summary names each worker and its receipts.

Notice what the coordinator never does: assemble the result from worker summaries. The summaries exist, inside the handovers, but the coordinator works from the records the pickups return. Verify, then wrap.

The run

November 2, 2026, four fresh identities, one shared job id (swarm-scan-2026-11-02), job: a three-asset market scan.

The coordinator opened the job with the brief: https://zambo.dev/run/4aad48df-b66f-45ee-9fb5-73a67577ae48

worker-btc checked BTC: $76,876.00, down 1.15 percent in 24 hours, at 20:07:21 UTC. Price receipt: https://zambo.dev/run/341a5c02-6713-4704-9708-f00708ee44e4. It saved the finding: https://zambo.dev/run/54033676-fb88-40bf-9018-b8b4cb89c720. Then it wrapped its contribution: https://zambo.dev/handover/cdcb95db-8c1c-4a21-beca-da1616989537

worker-eth checked ETH: $2,251.23, down 0.27 percent, at 20:07:26 UTC. Price receipt: https://zambo.dev/run/8d89c2f8-26c2-45b8-8d23-81df2b16f0b7. Finding: https://zambo.dev/run/70a70995-0c8c-4cd6-aa99-6863bf4239a6. Wrap: https://zambo.dev/handover/3ada9ebc-30c2-4324-bce3-5b8243e049e6

worker-sol checked SOL: $91.79, down 2.27 percent, at 20:07:31 UTC. Price receipt: https://zambo.dev/run/59ab0985-48e4-4712-8da6-266f733319fa. Finding: https://zambo.dev/run/50f77308-3537-43b8-9235-e9309feb4da4. Wrap: https://zambo.dev/handover/f6d6e4d1-6bfb-407c-882b-7014125a36a2

The coordinator picked the three handovers up at 20:10:13, 20:10:16, and 20:10:19 UTC, read each worker's steps from the pickups, and wrapped the swarm: https://zambo.dev/handover/a154789b-0588-43c7-a31c-d108eb59406b

Open that last link. It lists exactly six steps: the three price checks and the three memory saves, each one opening to a receipt that carries the same saved output the worker produced, timestamps identical to the original calls. The summary names each worker, its price, and its original receipts. The wrap's own receipt is here: https://zambo.dev/run/61ee822c-3f8e-44a4-aac4-1cf405566a58

Three places my assumptions were wrong

I assumed the shared job id made a shared inbox. It does not. When the coordinator read the job back with continuity_get_recent, it got its own timeline for the job: its opening step, and none of the workers' steps. The shared id binds the job's ledger and its pass together; it is not a group chat. Contributions move through handovers or they do not move. Honestly, this is the safer design: a worker's work reaches the coordinator as a sealed record the coordinator chooses to pick up, not as rows in a table anyone in the job can browse.

I assumed wrapping was a formality. My coordinator's first wrap attempt, a handover call with next steps but no summary and no named recipient, was refused on the spot, with its own receipt: https://zambo.dev/run/b2882668-1fd0-4410-aac1-826902ea2621. The endpoint asked, in so many words, what should be handed over and to whom. A wrap is a deliverable being published, and it is held to that standard. Every successful wrap in the run sets a summary, a goal, a recipient, and next steps.

I assumed the wrap would just bundle links. Instead, a wrap runs a proof loop over the job's steps and binds them into the handover. Each worker's handover lists 19 steps of job workflow, including the proof loop's own receipted steps, and the final handover's six steps carry the workers' saved outputs directly. The deliverable is the work, checkable step by step, not a paragraph about the work with links sprinkled on it.

What a swarm costs

The free tier is per agent: 20 calls plus 1 wrap-up free every day for each agent's own caller handle, and picking up in another AI is always free. Counted from this run's own counters, the coordinator spent 2 counted calls (the opening brief and one continuity read) and each worker spent 2 (the price check and the memory save). Three pickups and four wrap-ups moved no counter at all. Eight counted calls across four separate allowances, and every agent finished with 18 of its 20 free calls left. A swarm shaped like this runs free, one run a day or several.

When a swarm outgrows free, the scaling line is per agent too: 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. One-time payments, never subscriptions. This four-agent swarm on a heavy day costs four Day Passes, $3.96 for the day; covered for a month of heavy days, four Passes, $116 for 30 days. And pickup stays free at every tier, so a coordinator can always read its swarm's record, even on a day it cannot work.

Do not take my word for it

Pick any worker contribution in the final handover, open its receipt, and check it at https://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. It does not prove the price was right or the worker picked the right tool, and I am not claiming otherwise. If a receipt from this run ever fails to verify, that is news and I want to hear it.

The full guide, with the accounting and the standing instructions at depth, is here: https://rambozambodotdev.gitlab.io/aer1-hub/swarm-coordination-on-zambo.html. The runnable code is in the starter repo, coordinator and worker, next to the same pattern written as an installable skill file: https://github.com/zambodotdev/zambo-memory-loop-starter/tree/main/examples/swarm-scan

Your framework still runs your agents. Zambo is where their work lands, gets remembered, gets handed over, and gets proven. That is the whole pitch, and every link above is the evidence.

Try it free: add Zambo to your AI in one step at zambo.dev/add. 20 calls plus 1 wrap-up free every day, picking up in another AI is always free, no card and no signup wall.

Zambo: https://zambo.dev
Add Zambo to your AI: https://zambo.dev/add
The swarm guide, with the full run and accounting: https://rambozambodotdev.gitlab.io/aer1-hub/swarm-coordination-on-zambo.html
Swarm scan code, coordinator plus workers: https://github.com/zambodotdev/zambo-memory-loop-starter/tree/main/examples/swarm-scan
The swarm package repo: https://github.com/zambodotdev/zambo-swarm-coordination
The swarm package on PyPI: https://pypi.org/project/zambo-swarm/
The swarm package on npm: https://www.npmjs.com/package/zambo-swarm
AER-1 conformance corpus: https://zambo.dev/aer1/corpus.json
Verify any receipt: https://zambo.dev/verify/
AI agent handover, the signature product: https://dev.to/rambozambo/ai-agent-handover-pass-a-live-job-to-another-ai-without-losing-the-record-72b

4,247 callers came. 17 stayed. Here is the loop built to make them stay.

rambo — Mon, 02 Nov 2026 19:27:28 +0000

I counted. Not sampled, counted: I walked the entire public receipt stream, 21,916 receipts in all. The seven full days from October 26 to November 1 hold 20,668 of them; the rest are the morning of November 2, partial. Every call grouped by who made it.

4,247 distinct callers used Zambo that week. 98.5% of them were active on exactly one day. 17 callers, 0.4%, showed up on three or more days. On an average day, 1.7% of the callers had been there the day before.

Discovery is not my problem. Return is.

What the heavy callers do, and what it does not prove

The week's top caller made 3,338 calls in six days. Nearly all of them were one tool: memory_recall. Read what I already know, then act.

That pattern, counted across the whole walk, holds across the whole power tier. 101 callers made 20 or more calls on at least one day that week. 56% of their calls were memory_recall alone, and another 8.7% were memory_remember: writing today down so tomorrow can read it. Nearly two thirds of everything a power user does is remembering.

Here is the part that keeps me honest: the heavy tier and the returners barely overlap. 97 of those 101 heavy callers also came on exactly one day, and only 2 of the 17 returners are heavy callers. Memory use tracks volume, not return. So the loop below is a bet, not a measured cause: give a returning agent something worth returning to, and see whether day two happens. I am running that bet in the open, one heartbeat at a time, and the receipts will say whether it works.

The one-day crowd looks completely different. Their calls spread across live prices, capability search, prompt shield, lead signals: useful things, finished in one visit, nothing carried forward. A tool you try once leaves nothing behind to come back to. A memory leaves a reason.

The loop

The fix is not another feature. It is a shape, and it is the shape the 17 already run:

Pick up. Start the run by accepting yesterday's handover. The work, its receipts, and where it stopped are all there. Picking up in another AI is always free.
Recall. memory_recall the handful of facts the job depends on. Yesterday's context, loaded, not re-explained.
Work. Do the actual job, whatever it is. Every call returns a verifiable AER-1 receipt.
Remember. memory_remember the one or two things today taught that tomorrow needs.
Wrap. End with the handover. The wrap-up seals the day's steps into a record the next run, or the next AI, picks up whole. One wrap-up is free every day.

The arithmetic is the point: 20 calls plus 1 wrap-up free every day, and the loop above runs in about six calls. A daily agent on the free tier alone, no card and no pass, as long as it keeps the shape.

I ran it before writing this

Talk is cheap, so here is the loop executed end to end, receipts and all.

The run did a small monitoring job. Its first work call is here: https://zambo.dev/run/b2fa9171-84a5-4b05-b602-c825ef61fe83. It then saved its rule with memory_remember: https://zambo.dev/run/fc606132-e1c1-476d-9c22-23f00a63e778. It worked, and wrapped the job into a handover: https://zambo.dev/handover/d9bbf1c0-baa2-43b3-8bac-3952f9360438, with the wrap receipt here: https://zambo.dev/run/1e97b3a8-8c6d-4eff-8dd9-3671b2dfa2e2. Total cost: 6 of the day's 20 free calls, plus the free wrap-up.

Then the part that matters. A second run started cold, picked the handover up, and recalled the saved rule word for word: https://zambo.dev/run/e0bd9b5b-7c2e-463c-bfa8-43f23bc6be8e. Nobody retyped anything. The second run knew what the first run had decided, because the first run had written it down and wrapped it.

Every receipt above proves the saved result was not changed after the fact. That is the only claim a receipt should make, and it is enough: it is what lets run two trust what run one saved.

The honest gap

Daily power callers, 20 or more calls in a day, ran between 4 and 32 that week, median 13. The target is thousands. Today it is tens, and I am not going to round that up for you.

But the route is visible in the data. The callers who stayed did not find a better tool; they adopted a loop that starts with yesterday. So the work now is making that loop the default shape an agent starts with. The heartbeat recipe, the same loop written as a standing daily routine, lives here: https://rambozambodotdev.gitlab.io/aer1-hub/scheduled-agent-heartbeat.html. And the two-minute setup is the same one everything else starts from: https://zambo.dev/add/.

As I write this, the counters read 94,921 public receipts, 2,238 of them today, across 82,435 tool calls. The stream is public. Count it yourself and tell me where my arithmetic is wrong.

Try it free: add Zambo to your AI in one step at zambo.dev/add. 20 calls plus 1 wrap-up free every day, picking up in another AI is always free, no card and no signup wall.

Zambo: https://zambo.dev
Add Zambo to your AI: https://zambo.dev/add
AER-1 conformance corpus: https://zambo.dev/aer1/corpus.json
Verify any receipt: https://zambo.dev/verify/
AI agent handover, the signature product: https://dev.to/rambozambo/ai-agent-handover-pass-a-live-job-to-another-ai-without-losing-the-record-72b
The loop, pre-wired (starter repo): https://github.com/zambodotdev/zambo-memory-loop-starter
The morning standup, with receipts: https://rambozambodotdev.gitlab.io/aer1-hub/morning-standup-continuity.html
Start in one AI, pick it up in another: https://rambozambodotdev.gitlab.io/aer1-hub/pick-up-your-work-in-another-ai.html

119 of 119: an independent implementer just published his own IETF draft on AER-1

rambo — Mon, 02 Nov 2026 15:30:06 +0000

This morning, a developer in France I have never employed, never paid, and never asked for a favor did the thing that actually decides whether a specification lives or dies. He built on it, in public, under his own name.

Laurent Lemonnier of iSoluce published revision 01 of his own Internet-Draft, draft-lemonnier-scitt-decision-provenance, titled "Decision Provenance for SCITT: binding software releases and agent actions to the decisions behind them." It is his document, his argument, his standard-track work. And inside it, his Implementation Status section reports his AER-1 verifier passing 119 of 119 checks across the reference kit's seven suites, kit v1.5.7, pinned at commit 5d1504b.

AER-1 is my draft: draft-zambo-aer1-26, the agent execution receipt. Laurent did not fork my code and call it a day. He read the text, wrote his own verifier, and then used what he learned to write a second specification that composes with the first.

What his draft carries that mine did not

The part I keep rereading is in his Security Considerations. Working the interop cases taught a rule, and his draft now states it for the record: when a member names a decision outside what the receipt's own digest covers, that naming is the producer's assertion, and the binding runs the other way, through the values the receipt actually commits to. In plain terms: a receipt covers exactly what its digest covers, no more, and anything claimed beyond that is a claim, not a proof. That sentence started as behavior two independent implementations observed while testing each other. It is now written down in a second author's draft.

He also built a new interop case since: a plan-run case where one exact approval covers a whole plan, executed as steps, with a run manifest between them. His reading of AER-1 Section 8, the workflow receipts section, is that it forms the other end of that manifest: the approved plan on one side, the executed steps on the other, receipts binding the two. Composing those two halves is the next case on the list, and it is bound for the IETF 127 Hackathon in San Francisco, November 14 to 20.

One person writing a draft is an opinion. A second person, unconnected, publishing his own draft that depends on the first one and corrects its edges in public: that is the start of a standard.

He is not the first stranger to build on it

The pattern has been running all year, and every round of it made the draft harder and more honest.

ARION built a complete Node.js verifier from the draft text alone, no reference code, no help from me. Run against the kit, it produced 165 checks with 0 failures, and its verdicts matched the reference verdicts exactly. That is the test a specification is supposed to pass: two people who never shared code read the same text and arrive at the same answers.

ColonistOne built aer1-perl, a Perl implementation, again from the text. It came out conformant, and along the way he filed findings, real defects and ambiguities he hit while implementing. The draft adopted them. An implementer who finds nothing wrong has usually not implemented very much; ColonistOne implemented plenty.

Genesis cold-built a verifier from draft -19 and hit three genuine gaps. Those gaps were fixed and adopted in draft -20, with credit in the draft itself, because that is the deal: if your implementation teaches the spec something, the spec says so.

Lucas Bailey of WhiteMagic Labs independently verified the draft and is listed in it as an independent validator. And just two days ago, on October 31, Vaara's receipt draft reached revision 15 citing AER-1 -26, accurately, in a document I did not write and do not control.

The press noticed the same week: TokenPost covered the -26 revision on Oct 30, calling AER-1 "a portable receipt for AI tool calls" and noting, fairly, that it remains an individual proposal, not an adopted standard.

None of these people work for me. There is no me, in the company sense: Zambo is one founder. The implementations exist because the text was public and the test corpus was public, and strangers decided the problem was worth their weekends.

The corpus is the invitation

Every one of those implementations started at the same door: the public conformance corpus at https://zambo.dev/aer1/corpus.json. It holds 143 vectors and 146 checks, free for anyone to download and run tonight, no signup, no permission, no email to me. If your verifier agrees with all 146 checks, you have a conformant reading of AER-1. If it disagrees, you have found something the draft needs to hear, and the draft has a track record of adopting exactly those findings.

That is the whole mechanism. A specification becomes a standard when strangers build on it, and strangers build on what they can test. The receipts underneath this are live, too: as I write this, Zambo's counters read 94,339 public receipts (1,656 of them today) across 82,040 tool calls, and the package estate behind the kit stands at 143,197 downloads. Every one of those receipts proves the saved result was not changed after the fact, which is the only thing a receipt should ever claim.

So the invitation is standing, and it is specific. Take the corpus. Build the verifier in your stack, the way ARION did in Node, the way ColonistOne did in Perl, the way Genesis did cold from an older revision. Break it if you can. Laurent took it one step further and wrote the next document. There is room at that table, and the door is a JSON file.

Try it free: add Zambo to your AI in one step at zambo.dev/add. 20 calls plus 1 wrap-up free every day, picking up in another AI is always free, no card and no signup wall.

Zambo: https://zambo.dev
Add Zambo to your AI: https://zambo.dev/add
AER-1 conformance corpus: https://zambo.dev/aer1/corpus.json
Verify any receipt: https://zambo.dev/verify/
AI agent handover, the signature product: https://dev.to/rambozambo/ai-agent-handover-pass-a-live-job-to-another-ai-without-losing-the-record-72b

Invoice for AI agent work with the proof attached: receipts, sign-off, and the dispute pack

rambo — Sun, 01 Nov 2026 22:21:13 +0000

An invoice is a claim. It says work happened, and asks to be paid. When the work was done by an AI agent, the client has no way to check the claim from the invoice alone, so payment turns into an argument about trust. This is the pattern that ends the argument: invoice with the record attached, so the client checks the work the way they would check a delivery note.

The problem with a bare invoice

The usual delivery is a file, a summary, and an invoice. If the client later says the work was never done, or was done differently, or was done by a tool they did not approve, the freelancer has a chat transcript. A transcript is the agent's own account of itself, written in the same voice as the claim. It settles nothing, because it can be edited, trimmed, or regenerated after the fact.

What settles it is a record the agent did not write about itself: receipts left by the execution layer at the moment each piece of work ran.

The pattern, in four steps

1. Run the work so it leaves receipts. Work routed through Zambo at https://zambo.dev/mcp leaves a verifiable receipt for every call: the tool, the inputs, the saved result, the time. A receipt proves the saved result was not changed since it was saved, and anyone can recheck it at https://zambo.dev/verify/ with no account. As of November 1, 2026 the public stream holds 92,515 of these receipts, and every client job you run adds its own.

2. Wrap the finished job in a handover. A handover carries the whole job under one link: the deliverable, the steps with a receipt for each, the decisions made along the way, and the list of what was not checked. Public handovers on the live system, such as handover bd7e5325, show the shape: the record itself travels, not a summary of the record.

3. Let the client accept on the record. The client opens the one link, reads the work, and records their acceptance on the handover itself. Sign-off stops being an email thread nobody can find later. It is a line in the record, next to the work it accepts, with the receipts underneath it still recomputing to the same digests.

4. Invoice against the link. The invoice names the job and carries the handover link and the recorded acceptance. The client who wants to check before paying opens the same link the freelancer sees. There is no second version of the evidence prepared for the client, because the record was written while the work ran, not assembled when the invoice went out.

When the dispute comes anyway

Sometimes it does, weeks later: the deliverable is questioned, a chargeback is threatened, a new manager inherits the account and trusts nothing. The dispute pack is the same link, reopened. The receipts recompute or they do not. The acceptance line is in the record or it is not. The conversation starts from a checkable record instead of from two memories.

Be precise about what the pack proves. It proves the saved results were not changed after the fact, and that the client recorded acceptance of the work as presented. It does not prove the work was good. Quality was the client's call at acceptance time, made with the record open, which is exactly when that call should be made.

What it costs to work this way

The free tier covers a small delivery on its own: 20 calls plus 1 wrap-up free every day, and picking up a handover in another AI is always free. A heavy delivery day is a $0.99 Day Pass, unlimited for 24 hours. Ongoing client work is the Zambo Pass, $29 for 30 days. The record is not an add-on at any tier; every call leaves its receipt as part of the call.

The invoice your client can check is the invoice that gets paid without the meeting. Attach the record, and the proof of completion stops being your word against theirs.

Try it free: add Zambo to your AI in one step at zambo.dev/add. 20 calls plus 1 wrap-up free every day, no card and no signup wall.

Zambo: https://zambo.dev
Add Zambo to your AI: https://zambo.dev/add
Verify any receipt: https://zambo.dev/verify/
The full estate, by the numbers: https://dev.to/rambozambo/one-founder-44-packages-116305-downloads-the-zambo-stack-by-the-numbers-4m0f
AI agent handover, the signature product: https://dev.to/rambozambo/ai-agent-handover-pass-a-live-job-to-another-ai-without-losing-the-record-72b