The architecture behind harness-go. NATS JetStream, BadgerDB + Bleve, and hot-reload policy via atomic pointer swap.
Every “AI coding agent” demo you have ever seen is single-shot. One model, one prompt, one output, and a hope the user accepts it. 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 most pipelines skip 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.” 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 semantic recall — “have we tried this refactor before, and what happened?” Both embedded, single binary, no network.
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.