Three buzzwords

Harness is the engineering wrapped around the model: tools, permissions, sessions, persistence. The model supplies judgment; the harness supplies hands and memory. The Claude Code CLI is a harness. A model without one is just a chat box.

Loop is an agent that stays alive: wake → read state → do the work or delegate it → sleep, round and round. I run two loops: Nerve handles every project, Helm handles company operations. Each has run continuously for two months on cron wakeups, on-disk memory, and watchdogs that heal them. The interesting part is that Helm doesn’t even route through me — it receives WeChat messages and handles them itself. That is deliberate, because my own head really is short on capacity.

Graph is wiring several nodes — agents, deterministic code, human approvals — into an explicit topology: nodes doing the work, edges handling the routing, state flowing between them. In mid-July people on Twitter hyped it into “Graph Engineering,” but LangGraph has been doing it for over two years. What actually changed is this: a node used to hold nothing braver than a few parallel subagent calls, and now it can hold a complete, complex multi-agent flow.

Evolution wasn’t designed

In chronological order: first the harness (hands for the model), then people made agents live longer (loop), then work a single loop couldn’t finish had to be split across several agents (graph). Mapped onto my own stack: Claude Code is the harness, Nerve and Helm are the loops, Dynamic Workflow is the graph. There is a whiff of concept-chasing about that, admittedly. But by the time the community started arguing about the word in July, I had already run 356 graph runs in the previous 14 days, 93% completion, median execution time 7 minutes.

Claude Code’s built-in dynamic workflow is itself a graph, but only half of one: it is disposable — the loop mints one on demand, discards it after use, leaves a journal behind, and can replay it exactly from cache. What I think you want is the improved version: a named graph. That is the real one — long-lived, reusable, versioned (@vN, versions kept in git). Under a $200/month subscription where you cannot call the API freely, reworking DW is the relatively optimal way to do graphs at all.

A Spectator

Over the last couple of days I wrapped a larger observer loop around my several loops, called Spectator. Anyone who has played Minecraft gets it instantly: spectator mode — fly through walls, see everything, touch nothing. The reason is that a loop cannot notice its own problems; it cannot be Gödel-complete about itself. This is structural: when the referee and the athlete are the same person, the result usually disappoints.

Spectator is one independent session, waking every 3 days, reading only the exhaust pipes of the other two loops (transcripts, DW journals, logs, pm2). It has exactly one core move: take what the system claims it did and check it against what actually exists. It writes nothing to the systems it observes. Nerve and Helm don’t even know it exists.

So the system splits into three planes: control (me plus approvals), execution (loops plus graphs), observation (Spectator). Three planes, three tempos: execution runs in hours, observation in days, and I set direction on a slower beat than either. This is not a new invention — cybernetics calls it an observer, corporate governance calls it audit independence, aviation calls it the NTSB. The only new part is wiring it to an autonomous LLM system. Very few people in the agent world do this, for a very practical reason: most agents don’t survive an hour, so there is nothing to audit, and under per-API billing, keeping a non-productive observer alive is pure overhead. A Max-plan subscription flips that math — the marginal cost of the observer is roughly zero.

What it saw

Spectator’s first batch of data (14-day window):

• The long session went through 48 compacts (context compression restarts). In-cycle error rate, early/mid/late = 4.25% / 4.21% / 3.73% — the “35-minute performance decay” from the literature is not measurable in this architecture. Discretizing on wake plus on-disk memory really does hold off context rot.
• 35 graphs launched in the last 10% of a context window, right up against the compact, ran to completion anyway — straight across the compact boundary. Graphs survive independently of the context that launched them; this is the first time that architectural advantage has been quantified.
• The unflattering results too: only 63% of the artifacts a graph claims for itself can be verified; and the iron rule that “every dead run must be redone” has a measured compliance rate of 40%. A rule written in a document is not a rule that gets executed — which is exactly what the next step has to fix.

What I’m building

The direction in one line: compile the doctrine into mechanism. Rules written in markdown keep the direction only; anything that should happen every single time sinks down into schemas, templates, and driver scripts. Six concrete pieces: agent return values must carry an artifact manifest (a schema contract); dead runs revive automatically (turning that 40% into a mechanical guarantee); logs get schematized, with an author field; named workflows carry version numbers (@vN, versions tracked in git, the journal recording which one each run used); the publishing pipeline gets compensation logic (better to publish nothing than to publish to the wrong surface); and a fixed task set runs as a nightly regression bench. All of it fits inside the subscription constraint, because my harness already ships every tool required: the journal is the checkpointer, schema validation is the typed state transition.

The endpoint is letting the graph modify itself: the regression bench scores it → a new topology version gets drafted → anything that scores worse is blocked → anything better comes to me for approval. The precondition is that the brakes go in first — versioning and an independent observation plane are the brakes, and both are already in place.

Why I only built it once Opus 5 shipped

It isn’t that I only just thought of it; it’s that I only now think it’s worth doing. A model’s harness has to match the capability of the model itself. Opus 5 has now drawn level with Fable and Mythos on capability, and it is cheap enough to actually use — so changing the architecture follows naturally. Opus 4.8 could write a graph, but the cognitive load was heavy and it couldn’t use one well: a graph’s quality ceiling is its nodes’ quality ceiling. When the nodes aren’t stable enough, topology failures and node failures are indistinguishable, all the effort you spend on structure gets eaten by node noise, and you end up wrongly concluding the architecture was the problem. Once Opus 5 shipped, “one node = one complete agent” finally holds, and investment in structure starts to pay.

The community line is right: graph engineering isn’t new. What’s new is that the nodes are finally worthy of the graph.