
ZeroTrust Factory is a software factory built in BAND Desktop. Four Claude Code seats plan, build and independently verify a clean-room restaurant reservation service (tablekeeper), one stage at a time. No seat trusts another seat's claim that work is done. The band Architect (Opus): the only seat that talks to the human. Splits each stage spec into handoffs with the full task pasted in. Never asks for clarification or approval. Developer (Sonnet): implements one scoped item at a time, builds to spec only, posts the committed revision. Reviewer (Sonnet): checks each revision against the full requirements, not the developer's summary. Rejects with a concrete reason or accepts. Release-verifier (Sonnet): rebuilds and runs the harness itself in isolated mode (no outbound network, 2 vCPU, 2 GiB). Confirms only from output it read. How it works Each stage folder is a complete, buildable service, copied forward and extended from the last, so earlier behavior must keep passing. The submitted run's only human input was 8 messages: 4 mandates, 4 stage dispatches. Mandates are fully generic, no mention of reservations, tables or endpoints, the track detail lives only in the dispatched task. What it built: all 4 tablekeeper stages, API with idempotent writes and atomic moves; browser UI with stale-state recovery; effective-dated policies and recurring series; closure replanning with atomic apply. Bad work it caught: in the graded run, reviewer rejected a stage 2 revision for a UI defect ("null" in the header), fixed and re-accepted. In the dev run: two stage 1 rejections (missing validation, a cutoff bug), one stage 2 rejection (422/400 mismatch), one stage 4 rejection (crash on extreme timestamps). FACTORY.md has commit hashes for all. Verification: every stage reconfirmed via isolated harness on a clean container and again on a fresh clone. room.json is submitted unedited. Result: all 4 stages, zero-steering run, 1h14m total.
6 Oct 2026

During an outage, engineers are busy fixing the problem, not writing it down. The result is lost context, a timeline pieced together from memory, and postmortems that show up days late or not at all. Postmortem Witness is a voice agent that only listens. It joins an incident bridge call and never speaks or interrupts. It uses AssemblyAI real-time streaming transcription with speaker labels to capture who said what and when. As the call goes on, it pulls out the key moments (detection, hypotheses, actions taken, escalations, mitigation and resolution) and turns them into a timestamped incident timeline the whole team can watch update live. When the call ends, Postmortem Witness turns that timeline into a structured draft postmortem. The draft covers the summary, impact, timeline, root-cause hypotheses, what went well, what didn't, and action items with owners. Something that used to take hours of writing becomes a few minutes of review. It is built for SRE, DevOps and on-call teams that want accurate incident records without taking anyone off the fix. Responders can focus on the fire while Postmortem Witness keeps the record.
30 Sep 2026