The Harness Playbook — Stencil

The Harness Playbook — Stencil

Before anything else: a thank you. Hundreds of thousands of you have used omp, reported what broke, suggested what was missing, and shaped what it became. This post and omp² itself exist because of you.

Upon hearing about omp², many of you jumped to ask, “but why?”

A while loop around a fetch sounds simple, but there’s a reason OpenCode, Pi, OpenClaw and omp are all
concurrently working on a complete refactor: this class of software did not exist before, and only by starting
with the simple version, we could see the cracks to work towards a better one.

Unavoidable complexity needs an owner. At the moment, the conservation of complexity
tips toward extensions and users, making it impossible to write reliable software on top of omp or Pi. I can already hear
the “whaaat, it is so simple and pleasant to extend.” Give me a few chapters to change your mind.

Dijkstra wrote that “simplicity is prerequisite for
reliability”
, and yet he is known for
algorithmically solving pathfinding. Why not just brute force? He was not, at all, making the claim
we now repeat as simple good, complex bad. The advice was to help implementers reason. We
shamefully use it to excuse the implementer from reasoning.

Ousterhout gives the missing half in the notes of his Stanford lectures. He tells module writers to
“embrace
suffering”
.
Take on hard problems, solve them completely, and make the result easy for everybody else to use.
Push complexity down into the module. Let a few implementers carry it instead of making every caller
carry a smaller, slightly different copy.


I am sure many readers remember the wave of memes from the tweet comparing Claude Code to a game
engine. The comparison sounds far-fetched, but if you list the responsibilities of a harness, putting rendering aside, it does match quite well.

It maintains an authoritative world, journals changes, runs untrusted actions, replicates state to
multiple views, schedules actors, interprets commands, adapts incompatible protocols, and renders a
real-time interface.

Sounds familiar? It seems game engines have spent decades owning the same categories of complexity.

What follows is both a postmortem and a playbook:

  • What omp taught us names failures we met in a system people actually used.
  • What omp² changes describes the replacement architecture—some of it already built, some still
    being worked through.

The design envelope

Before discussing any subsystem of an agentic harness, imagine that four very different products
will depend on it:

  • Multiplexed workspace
    A local environment with multiple agents and subagents in the same folder.
  • Remote driver
    A remote client driving a cloud agent—or the machine under their desk—from a phone.
  • Spectator
    A web client watching a Claude agent work.
  • Factorio
    An automated software factory using the SDK against untrusted input.

These are not market personas. They are architecture tests. Together they vary the dimensions that
make a harness stop being a chat loop:

A design that only works for the first case tends to smuggle the controller into the TUI, keep
state in closures, let extensions execute in the engine process, and assume a human can recover from
an unbounded call. A design that survives all four is forced into better boundaries.

The rest of the book follows five consequences:

  1. One authoritative session. Rewind, fork, resume, replication, and inspection must all derive
    from the same journaled state.
  2. A trusted control plane. Policy and session ownership stay on the host; sandboxes receive only
    bounded execution requests.
  3. Bounded work. Tool calls, subagents, and background jobs are all cancellable streams with
    central limits and observability.
  4. Explicit compatibility. Model and provider quirks are structured knowledge, not branches
    scattered through call sites.
  5. Views are projections. The TUI, web client, remote client, and subagent inspector render the
    same state instead of becoming additional authorities.

Those constraints are connective tissue for everything that follows. When a later section proposes
a DOM, a convar, a Director, a tiny VM stub, or a component renderer, it is solving one of these
five requirements—not introducing a clever subsystem for its own sake.

The first requirement is the foundation: before deciding where code runs or how it is rendered, the
harness needs to know what is true.

The state

What must survive

If you want something to be durable, rewindable, crash-tolerant, and forkable, you have three
choices:

  1. Preserve the history that produces it.
  2. Preserve the changes in the properties you care about.
  3. Preserve the machine itself.

The Source Engine uses a variant of the second option for networking. omp and Pi currently use…
none of them consistently. There are events, but state is not really sourced from those events,
violating the first principle of event sourcing: state must be derivable from the events alone.

What omp taught us: two authorities