Case study · 2026
Infinite agents, one ledger
I built one shared ledger that any number of AI agents can work against, then ran a real, repetitive workflow on it for two months. The agents found items on external sites, screened them against rules, filled and submitted forms, and triaged the email that came back. This is what broke, and what fixed it.
- Agents
- Any number. This run used five: Codex, Meta Muse, two Grok bots, a ChatGPT agent
- Shared record
- One spreadsheet, 340+ tracked items
- Schedule
- Daily runs, plus mail checks at 11:45 and 21:00
- My role
- Designed the rules, ledger and audits; ran it day to day
The setup
The workflow had the classic shape of work people want to automate: many small items, each needing a judgment call, a long web form, a file upload, and follow-up by email. No single agent was reliable enough on its own, so the ledger lets any agent pick up work, and adding one is a matter of giving it the rules. For this run I split the work like this:
- Cloud agents (Muse, two Grok bots, a ChatGPT agent) searched on a schedule, screened candidates against written criteria, and submitted the clear cases.
- A local agent (Codex) maintained the shared record, audited what the others wrote, and checked both mailboxes twice a day.
- I handled anything that needed tailored material or a real decision.
Everything met in one spreadsheet: one row per item, a stable ID, which agent did the work, the exact file version used (by SHA-256), where the source page was archived, and the current status.
What broke
An agent erased the work queue
Mid-afternoon, a 42-row queue dropped to one row, header included. An agent had written a stale snapshot over the live sheet. Another time, two rows got merged, so one item's name sat next to another item's ID and file.
Fix: every write now starts by reading the live rows it will touch. Records are addressed by stable ID, never by row number. Each run saves a before and after snapshot, so any change can be traced and reversed.
"Prepared" kept turning into "submitted"
Agents would generate the file, open the form, and log the item as done. Some never reached the final click.
Fix: an item counts as submitted only when there is a receipt. A prepared file or an "in progress" page is a different status, and an uncertain submission is never retried until its outcome is checked.
Nobody knew who did what
When one agent edited another's row, it often overwrote the author. Twelve records were credited to the wrong agent before I noticed.
Fix: the attribution field records the agent that originally did the work and never changes on later edits. A second account of the same bot gets its own name.
The rulebook grew faster than the work
Each incident added a rule. After two months, the instructions file had dozens of them, and a large share of the agents' time went into maintaining formatting and status rules rather than doing the task.
Fix, still in progress: move the rules that matter into code (dedupe, hash checks, status transitions) and delete the rest.
The result that mattered
Volume was the wrong metric.
The agents processed hundreds of items. But almost every good outcome came from the small set I handled by hand with tailored material. So the division of labor changed: agents now do search, deduplication, mail triage and calendar reminders, which they do well, and the high-value cases come to me.
What this means for your project
- Agents writing to a shared system need read-before-write, stable IDs and snapshots from day one.
- Define "done" by evidence, not by the agent's own report.
- Measure outcomes, not throughput, and move the work humans do better back to humans.