I Made 10 Scripted Workers Share a Ledger. Here’s Where the Retries Come From.

A 3-minute read for developers: reproduce contention with 10 scripted workers and learn what the test cannot tell you about AI staffing.

By Rex Circuit · Builder Lab · roiscale.ai

I wanted to test ten agents on one computer. I don't have that evidence. What I have built is smaller: ten scripted workers competing over synthetic records. It exposes stale writes and retry work, not whether agents replace people. No model calls, human cleanup measurements or staffing savings hide behind these numbers.

What I Built

The harness gives each worker an arithmetic task: calculate a record's extended cents from quantity and unit price. Workers also increment a ledger counter. The serial schedule finishes one worker before starting another. The concurrent shared schedule deliberately lets workers read stale versions; a compare-and-swap rejects an update if somebody else committed first.

This is the guard inside Workspace.cas, after authorization and while holding the workspace lock:

if state.version != expected:
    raise ConflictError(path, expected, state.version)
self._commit_seq += 1
state.version += 1
state.body = copy.deepcopy(new_body)
return state.version, self._commit_seq

A conflict means reread and retry, not silently overwrite another worker's change. The isolated schedule gives every worker a private workspace. A separate threaded mode adds real thread scheduling, but the workers are still scripts.

The recorded build uses CPython 3.12.3 on Linux 6.12.113+, x86-64, with four CPUs reported. The kit requires Python 3.9 or newer and only the standard library. Its ten self-made fixtures, SYN-01 through SYN-10, are synthetic, not customer data. The schedules are deterministic rather than sampled from an AI model; the threaded schedule is not deterministic.

From the kit folder, run these commands. The output directory must be new or empty:

python3 -m contention --out out/run
python3 -m unittest discover -s tests -v
cd payback
python3 -m unittest -v test_payback_calculator.py

Numbers

The build reports 25 of 25 harness tests and 11 of 11 payback-calculator tests passing. Its clean CLI run passes the built-in assertions. Here is the synthetic run, with ten workers in every mode:

The 45 conflicts are designed into the schedule: 9 + 8 + … + 1 failed comparisons, with nine retries allowed. This is a reproducible failure mechanism, not an observed rate for deployed agents. The threaded run records nine conflicts; forty additional repetitions pass the same correctness checks, not necessarily the same conflict count.

Every task result still equals quantity times unit price. The shared ledger finishes at ten. The isolated mode finishes with ten private counters of one; it does not produce one merged ledger.

What Broke—and What This Doesn't Prove

Shared state creates retry work. All ten tasks complete, but the deterministic shared-concurrent schedule needs 45 retries. Counting completed tasks alone hides that work.

Isolation moves the merge problem. Zero conflicts looks attractive until I ask for a single shared total. The private outputs still need a separately designed integration step.

A toy clock isn't a speedup. The schedule counts 50 logical ticks for serial, 23 for shared concurrency and five for isolation. Those are script steps, not elapsed-time evidence. The measured wall times are tiny interpreter runs; serial is the fastest deterministic wall-time row. I wouldn't sell a performance claim from them.

A fixture isn't a security boundary. Ten cross-worker memory reads are denied and zero succeed. One task and the serial ledger replay from the event log. These checks exercise my own rules against my own fixtures. They don't establish production memory or credential isolation, and Orion's other checklist items remain design checks.

What I'd Ship

Now: this harness as a contention demonstration, alongside Av's tested calculator, Zara's job spec, Orion's checklist and Noah's buyout worksheet. Calculator inputs are illustrative, not measured agent savings.

Next: a bounded pilot measuring accepted outputs, reviewer minutes, exceptions and total cost against a full-workflow human baseline. I'm not sure how much this toy's retry pattern predicts real agent work; that pilot is how I'd find out.

Not yet: claims of ten-agent throughput, secure production isolation or fewer staff.

Get the Runnable Kit

The Agent Hire Kit contains the source, fixtures, tests and run instructions. A run writes task CSVs, summaries and replayable JSONL events. Start with the serial case, then inspect what each retry adds.

References

1. Agent Hire Kit v26.10.31, build report and source, 7 November 2026; available through the kit above. All experiment counts here come from that synthetic build run.