Stencil, the company behind the open-source agent harness omp, published a lengthy engineering playbook this week arguing that the hardest problems in building agent harnesses (durable session state, sandboxed execution, tool routing, rendering) belong in a small set of core abstractions rather than scattered across extensions. The post, written by engineer Can Bölük, doubles as a postmortem on omp’s first version and an architecture proposal for its successor, omp².
The central diagnostic is concrete rather than abstract. Bölük’s team audited the 78 official extension examples shipped with Pi, a Stencil product. Sixty were stateless. Of the 17 that carried state, only two behaved correctly across rewind, fork, and resume operations. The rest failed in specific, reproducible ways: a checkpoint tool that lost its reference after a fork, a turn counter stored in a closure that miscounted after rewind, a tic-tac-toe example where a crash before the second player’s move made the first player’s move disappear entirely.
That failure count is the argument. Stencil’s diagnosis is that Pi’s current architecture keeps two separate sources of truth: a journaled message tree on one side, and a scattered set of closures, counters, and registries that never get folded back into it on the other. Extension authors hand-roll their own replay logic for every piece of state they add, and most get it wrong. The fix proposed for omp² is to materialize the entire session, transcript and state together, as a single tree, so rewind becomes a diff operation and every consumer (a terminal interface, a remote client, a subagent inspector) reads the same structure instead of maintaining its own copy.
The playbook extends the same logic to sandboxing. Stencil walks through why an untrusted virtual machine cannot safely own either the tool executor or the driving application: both arrangements force API keys, session storage, or application source into the sandbox, or require a duplex gateway that reopens the denial-of-service problem it was meant to close. The recommended shape puts a minimal, obedient execution stub inside the sandbox and keeps policy, inference calls, and session storage on the trusted host, with every response stream capped before it can exhaust host memory.
Stencil’s opinions here are not neutral. The company sells omp and Pi, so an argument that core abstractions should absorb complexity also argues that developers should build on Stencil’s engine rather than assembling a harness from looser parts. The 78-example audit is useful evidence regardless of who is making the case, since it documents specific, named bugs rather than a general claim that the old design was fragile.
The broader point outlasts one vendor’s roadmap. Harness design, the layer that decides what state persists, what a sandbox may touch, and how a tool call gets routed, is quietly becoming the place where agent quality actually gets decided, separate from which model sits behind it. That shift already shows up in how labs describe their own releases: a model card increasingly names the harness a benchmark ran inside, because the same model can behave differently depending on how its runtime handles rewind, retries, and tool concurrency.
Teams building agent products on Pi, OpenCode, or a homegrown harness should treat this less as a Stencil pitch and more as a checklist. Audit whether session state, sandbox boundaries, and rendering in your own stack trace back to one authoritative source, or to several that quietly drift apart under rewind and crash conditions, before the next incident finds the gap for you.
Stencil engineer Can Bölük published “The Harness Playbook” on the Stencil engineering blog on September 2, 2026.
