research-stack · research.devclusterai.com
MVP · records to 2026-09-23 · every number is from the project's records, listed at the end
solutionsmany agentsread 2026-09-23

Many agents. One record.

Six things break when a fleet does the research, not one careful person. Each has an answer that is on main today — and one number we do not have.

six things that break one table · one writer per run replay 79 of 79 at $0 7 ceilings · 2 outside the process n agents at once: not measured
seq 1Questionthe premise

Six things break when a fleet does the research.

  • unverifiableClaims nobody can check: prose comes back, and the sentence it rested on is gone.
  • paid five timesFive agents reach the same sub-question and five agents pay for the answer, separately.
  • nothing compoundsNo shared memory between runs: the thousandth starts knowing exactly what the first one knew.
  • cost invisibleSpend is unbounded and unseen until the invoice, by which time the run is over.
  • no recordTwo agents disagree and there is no record of what either of them actually read.
  • dies emptyA run that dies leaves nothing behind — not even the pages it already paid to fetch.

Every one is a property of the store the agents share, not of the model they call — which is why this is a ledger and not a prompt.

seq 2Kernelthe shared store

One table, one writer per run, and three things it hands back.

n agents · one run lease each · one append-only table agents separate processes, separate machines run lease one writer per run R5 refuses the rest owner lock kill · quota · key events one append-only table · thirteen ledgers sequenced — one writer · mergeable — any node scarce — coordinated, because it is money rows are content-addressed: nothing is updated, nothing is deleted, an owner append needs no run memo key the same question, the same unit and prompt — no call 5 hits · 531 paid calls replay the recorded run re-derived with the network refused 79 of 79 calls · $0 knowledge what one run established, the next run resolves 10 of 136 charter lines what any one agent pays for, every later agent has — that is the whole of the architecture source: docs/SPEC-kernel.md §1–§2 (the ledgers, R5, the owner lock) · docs/GATE-MVP.md · docs/GATE-POC.md check 3
what breakswhat the architecture doeson the record
n at onceOne append-only events table, one writer per run: a batch under another executor's lease is rejected class.sequenced_writer (R5). The owner's lock is a different file, so a quota or a kill lands beside live runs.16 concurrent producers, dense seq, zero BUSY, 5,375 events/s — BENCH-POC K-2
unverifiableEvery claim is anchored to a quote re-read byte for byte inside the commit transaction (A1) — a quote not in the stored body is refused, not flagged afterwards.490 of 490 resolved anchors re-read, 0 mismatches, 0 at a non-ok fetch — GATE-POC check 4
paid five timesA memo key over the input, prompt, dated model slug and parameters, looked up before the budget reserve — a hit costs no call and no reservation.531 paid calls · 5 memo hits over 53 runs — GATE-MVP
nothing compoundsThe Knowledge ledger is mergeable — doc versions, chunks, entities and linked claims cross runs and machines, so a charter line the next run can resolve is not searched again.10 of 136 charter lines resolved from knowledge; 7 of 33 later runs resolved at least one; 708 of 723 live claims ingested — GATE-MVP
cost invisibleEvery call is reserved before it is sent and settled from the response's own usage, in integer micro-USD — the total is what was spent, not what was estimated.$8.271496 settled over 53 runs · 0 over-cap refusals · 0 runs halted for budget — GATE-MVP
no recordEvery fetched body is stored with its hashes, every response's raw bytes are committed before validation, and each call records the byte range of every body in its prompt.6,130 refs with 0 dangling; 1,984 of 1,984 fresh fetch and search rows carrying the policy version they ran under — GATE-POC check 8 · GATE-MVP
dies emptykill -9 at any point: the run resumes from its last admitted event and repeats no call; replay re-derives it with the network refused.20 random kills: 0 repeated calls, report hash-equal (O-1) · replay 79 of 79 calls served from the ledger at $0 — GATE-POC checks 2 and 3

The store is the only place a run's state exists, so sharing it is the default rather than an integration — none of this is a cache bolted on afterwards.docs/SPEC-kernel.md §1–§3 (the ledgers and their classes, R5, the memo key, the owner lock) · docs/GATE-POC.md checks 2, 3, 4, 8 · docs/GATE-MVP.md (calls, memo hits, knowledge hits, spend, policy coverage) · docs/BENCH-POC.md (K-2, O-1, U-4)

seq 3Budgetthe ceilings

Seven ceilings. Two of them outside the process that spends.

The ceiling cannot live in the process doing the spending — the rule an unattended agent left behind on 17 September, after it spent a shared key's balance. Six of the seven are in the ledger; the edge limit and the key's own credit limit are not.

where a paid call can be stopped · in the order it meets them outside the process that spends a row in this ledger the edge 429 past 600 requests per key or 120 per IP in 60 seconds the ingest app, before a request reaches the kernel at all outside the process quota runs per day, dollars per day and a maximum depth, per user refused before anything is written and before any paid call a row in the ledger kill the owner's switch, read before every unit invocation the run ends halted; a call already on the wire completes a row in the ledger memo the same question under the same unit and the same prompt no call and no reservation — the look-up precedes the reserve a row in the ledger reserve unit cap × run $0.40 × day $20.00 × or_in_flight ≤ 10 live Σ(live) + Σ(settled) ≤ cap, checked inside the reserve a row in the ledger the key the key's own credit limit, leased per user and environment the provider refuses; the run ends halted, with no retry outside the process settle the response's own usage, converted once to integer micro-USD the ledger's total is what was spent, not what was estimated a row in the ledger two of the seven are outside the process that spends — the rule the runaway of 17 September left behind measured: 0 reservations refused over cap, 0 runs halted for budget, over 53 runs under contention: 8 clients demanding 400 against a cap of 100 admitted 0 over it, 30 refused source: docs/RUNBOOK.md · bench/sets/gold-8/caps.toml · docs/GATE-MVP.md · docs/BENCH-POC.md G-2

The kill switch takes the owner lock, not the run lease, so it lands while runs are live; every worker reads it before its next unit invocation. Exercised against three concurrent runs on one ledger: all three halted within one unit, nothing sent after the flip — against a mock provider, so a correctness test and not a timing.docs/RUNBOOK.md “A user's money” · docs/SPEC-kernel.md [C-340]–[C-347] · docs/TESTPLAN-POC.md T-BS-1 … T-BS-12 (T-BS-4 is the three concurrent runs) · bench/sets/gold-8/caps.toml (run $0.40 standard, day $20.00, or_in_flight 10) · docs/GATE-MVP.md (0 refusals over 53 runs) · docs/incidents/2026-09-17-openrouter-runaway

seq 4Evalmeasured · not measured

Why Rust — and the one number we do not have.

A fleet's bottleneck is the store every worker writes to. Each row below is a bench.result whose verdict is recomputed when the report renders.

whatnumbermeasured overstatus
event admission, p990.342 – 1.703 ms10,000 seeded drafts per kind, ten kinds, end to endMEASURED · target ≤ 2 ms
ledger throughput5,375 – 5,648 / s1, 4 and 16 concurrent producers for 10 s; dense seq, zero BUSY — synthetic drafts, not agentsMEASURED · target ≥ 500 / s
budget under contention6,101 reserves / s8 clients demanding 400 against a cap of 100: 0 over-cap admits, 30 refused, the cap reached, the sum within it at every prefixMEASURED · p99 1.713 ms
guard evaluation, p500.002 – 0.009 mstwelve guard and ledger-size rows, 10 k and 100 k eventsMEASURED · target ≤ 10 ms
the whole derived state rebuilt4.166 s100,000 events, 29 tables, hash-equal to the incremental viewsMEASURED · target < 60 s
peak memory, a headless run37.3 MBone run at the depth table's concurrency of 8MEASURED · target ≤ 60 MB
the console's worst screen, p9524.5 msa 95 MB ledger of 53 runs, release build, the pod to itselfMEASURED · bound 500 ms
one research run, p50 wall93.6 s52 finished runs of the MVP gate — the network and the model, not the kernelMEASURED
n agents researching at once—never run — no wall time, throughput or contention number for concurrent research runs against one ledgerNOT MEASURED

The kernel is not where a run's time goes: 93.6 s of wall against a worst screen of 24.5 ms. But we have never run n agents at once and measured it — the nearest thing on the record is a correctness test over three concurrent runs against a mock. That measurement is the next one to make, and until it exists this page claims no scale number.docs/BENCH-POC.md (K-1, K-2, K-3, K-5, K-6, O-1, G-2 with their POC targets) · docs/CONSOLE.md (the render times, release, 53-run 95 MB ledger) · docs/GATE-MVP.md (p50 93.6 s over 52 finished runs) · plans/audit-first.v2.toml (the depth table) · bench/sets/gold-8/caps.toml (or_in_flight = 10) · docs/TESTPLAN-POC.md T-BS-4, T-G1-1, T-G0-9

next: the reference — what is merged, with the file it is read from · how it works — the same machine, drawn.