How XYZZY keeps decision writes reproducible at 1.412 ms p95

The problem

Most AI tools are single player: one person, one chat, one context window. A team making a real decision, migrate the auth service or not, rewrite the billing module or not, does not work that way. Three or four people need to see the same conversation, branch out specialists to check different angles, and end up with one artifact everyone can point to later and say this is what we decided and why. Chat logs do not survive that. Nobody can prove afterward which output fed which claim, or whether the log was edited after the fact.

I built XYZZY to give a room of humans and AI agents a shared, durable place to have that conversation: one event history, one set of artifacts and tasks, and a decision record that keeps its evidence chain intact.

The mechanism

A room holds an ordered event log. Every action, a message, an agent run, an approval, is appended as an event, never mutated. Agents can branch: several specialists run in parallel on the same prompt, a human includes or excludes each output, and only the included ones become Claims. A Decision links to the Claims it rests on, and each Claim links back to the exact AgentOutput that produced it, so a synthesis is inspectable down to the run behind it. The event log itself is hash-chained: each event's hash depends on the one before it, so an edited or deleted row breaks every hash after it.

The server is a single FastAPI process. A service layer holds the state machines, input validation, and authorization; below it, a RealtimeHub does pub/sub and queued delivery over WebSocket while a NexusAgentBridge drives agent execution, budget limits, and pause and resume. A repository layer of 44 typed repos handles atomic event sequencing against SQLite in WAL mode through aiosqlite. NEXUS, a separate agent runtime, is optional underneath: when it is unavailable the bridge calls the configured model provider directly, and without an API key it emits a clearly labelled simulated output so the collaboration mechanics stay testable without pretending placeholder text is real analysis.

What it did

The seeded run recorded in docs/benchmarks/multiai-seeded-run-2026-08-20.md exercised the served UI against file-backed SQLite: three specialists launched concurrently, three completed outputs persisted, two included and one excluded, and a Decision Brief published with both included claims drilling down to their exact source AgentOutputs. Two consecutive reload and re-entry cycles restored the same three outputs, the same 2 included and 1 excluded review state, and exactly 30 visible events each time. Against that same run, 100 atomic file-backed selection writes came back at 1.412 ms p95, with the reopened log retaining 100 unique, contiguous events.

The honest caveat, stated in that same document: this is a single local run on one developer machine with no concurrent load, and the benchmark's own stated goal, a blind comparison against a real three-person ChatGPT shared Project, has not been won yet. Both halves of that comparison, a signed-in shared Project and a live model-backed XYZZY run, are still pending, and the document counts that as a loss until they exist.

What I learned

Hash-chaining the event log looked like the hard part going in and turned out to be the easy part: it is a function of the previous hash and the new event, checked by one CLI command. The harder design problem was making the simulated path, the one that runs without an API key, honest rather than convenient. It would have been simple to let a placeholder string sit quietly among real outputs. Labelling it conspicuously as simulated everywhere it appears, in the UI and in the evidence chain, forced every other part of the system, review, publishing, drill-down, to work the same way whether the content behind it is a real model call or not. That discipline is also why the benchmark document above admits its own comparison is not yet won instead of rounding up.

Sources

1. docs/benchmarks/multiai-seeded-run-2026-08-20.md, 2026-08-20
2. README.md, 2026-09-04
3. DESIGN.md, 2026-09-04