The architecture behind harness-go. NATS JetStream, BadgerDB + Bleve, and hot-reload policy via atomic pointer swap.
A single model given one prompt, asked to just produce an output, and trusted to be right the first time has no step that catches its own mistakes before the result lands. That does not survive contact with a real codebase.
harness-go splits the work across three roles with separate memories and separate failure modes. Proctor plans. Coders implement in isolated git-worktree generations. Reviewers score, and the Reviewer is allowed to reject. Rejection feeds back into the Proctor with structured rationale, and the generation regenerates. This is the part a single-pass pipeline cannot do and it is the part that matters.
NATS JetStream is the substrate. Durable, ordered, replayable work queues with ack-nak semantics that map cleanly to “this generation produced a valid candidate / needs regeneration.” Delivery is at-least-once — a NAK or a missed ack redelivers up to a bounded retry count (MaxDeliver). JetStream tracks that count and can raise an advisory event when it is exhausted, but the redelivery loop is as far as JetStream itself goes: once a message exhausts MaxDeliver, delivery to that consumer simply stops — the message itself stays in the stream, subject to the stream's own retention policy. Forwarding it to a dead-letter subject is our own consumer handler's job, on the final attempt, before it terminates the original delivery. Duplicate execution is a separate concern: an ack or a work-item lookup alone doesn't rule out a duplicate external effect, so it's handled with an explicit idempotency check keyed off the work item before a Coder or Reviewer step runs, at the application layer, not assumed away by the transport. We evaluated Kafka and ruled it out on operational weight; we evaluated Temporal and ruled it out on ergonomics for this shape of work.
Memory is two stores. BadgerDB for structured episodic memory — run artifacts, decision trees, per-agent scratchpads. Bleve for full-text recall — keyword and phrase search over past sessions, so “have we tried this refactor before?” finds prior runs that used similar words. It is lexical search (Bleve's standard analyzer), not embedding-based semantic similarity. Both stores are embedded in the same binary, with no network dependency of their own.
The policy hot-reload is the unlock. Scoring weights and reviewer thresholds sit behind an atomic.Pointer. A new policy graph builds, validates, and swaps during a safe compaction window. In-flight work holds the old pointer until it completes. No drain, no stop-the-world, no dropped tasks during iteration.
The full write-up — with the case study that motivated every choice — is in the harness-go case study.