openJiuwen: inner loops, outer loops and lifecycle rails

Short answer

openJiuwen (arXiv:2608.27969, 'Beyond Static Harnesses for Long-Horizon Coding Agents') argues that a long-horizon agent needs two loops on one shared execution substrate: an inner loop that executes a single task, and an outer loop that manages, supervises and repairs across tasks. Between and around both loops run ordered lifecycle rails - interception points in the runtime where checks fire in defined order at defined moments, independent of what the model wants.

The transferable claim for builders: if an invariant matters - never send before recording, never overwrite evidence, always verify before claiming done - it must be enforced by the runtime at a lifecycle point, not requested from the model in a prompt. Prompts are suggestions; rails are guarantees. Status: STUDIED. The evaluation is in the coding-agent domain, which we treat as a limitation, not a generalization.

The failure mode: every rule lives in the prompt, and the prompt is a wish

Look at the average agent's system prompt and you will find its entire safety case, stated as requests: 'Always record actions before taking them.' 'Never overwrite evidence.' 'Verify before claiming completion.' These are rules written where the model can read them, which means they are rules the model can also ignore, forget mid-context, or weigh against a thousand other instructions competing for the same attention window.

Prompt-encoded invariants fail in three specific ways at long-horizon scale. First, attention decay: instruction-following degrades as context fills, so rule 12 of your prompt is followed reliably in message 3 and unreliably in message 300. This is the same degradation geometry our Agent Rot article covers, applied to instructions. Second, duplication drift: the same invariant gets restated in the system prompt, per-task prompts, tool descriptions and few-shot examples - and the copies diverge, so the model averages between them. Third, no enforcement trail: when the model violates a prompt rule, nothing in the system notices, because the rule never existed as code. There is no stack trace for a violated instruction.

The deeper problem is a category error. A prompt is a communication channel to a stochastic system; an invariant is a property that must hold. Communicating a property is not enforcing it. Any architecture that depends on the model remembering to obey is an architecture whose safety case degrades with attention, not with intent. Long-horizon agents need the invariants moved out of the channel and into the runtime.

What the paper actually does

PRIMARY SOURCE RESULT: openJiuwen (arXiv:2608.27969, 'openJiuwen: Beyond Static Harnesses for Long-Horizon Coding Agents') studies harnesses for long-horizon coding agents and argues that conventional harness designs are static: they wrap the model in a fixed pipeline of prompts, tools and a final check, with no structured place for supervision or repair to act mid-execution. The paper proposes a two-loop architecture on a shared execution substrate.

PRIMARY SOURCE RESULT: The inner loop is task execution: plan, act, observe, iterate, within a single task. The outer loop is management across tasks: it monitors the trajectory of inner loops, decides when a task is drifting or stuck, intervenes, repairs, and reassigns. Critically, both loops run on the same shared substrate - the same event stream, the same state store, the same tool interface - so the outer loop observes and acts on exactly what the inner loop did, with no separate translation layer that could lose or launder information.

PRIMARY SOURCE RESULT: Running through both loops are lifecycle rails: ordered interception points in the runtime at defined moments of the agent lifecycle - before a tool call executes, after an observation returns, before a task is marked complete, at session teardown. Checks attached to rails run in a defined order regardless of what the model proposes, and can block, rewrite, annotate or log. Because the rails are part of the runtime rather than the prompt, their enforcement does not depend on the model's attention or willingness.

PRIMARY SOURCE RESULT: The authors evaluate the architecture on long-horizon coding work and report that outer-loop supervision over a shared substrate, with rails enforcing lifecycle invariants, sustains longer runs with more reliable rule adherence than the static-harness baselines they compare against.

What they found, and which part matters

The headline finding is the division of labor. Inner loops are where capability lives: the model reasoning through a task. Outer loops are where reliability lives: a persistent process that watches the trajectory, notices stuck states and intervened patterns, and repairs them without waiting for the whole run to fail. Neither loop replaces the other, and the shared substrate is what makes the outer loop's view trustworthy - if supervision reads a lossy summary of execution, it supervises the summary, not the agent.

The rails are the part we would underline. A rail turns 'the model should verify before done' into 'the runtime refuses to mark done until a verification step has run'. The model can believe whatever it wants; the rail does not care. And because rails are ordered, enforcement is composable: a team can add a rule - quarantine writes after N failures, block irreversible effects without an explicit confirmation artifact - without rewriting the prompt or negotiating with the model for attention.

A subtler finding worth naming: the paper reports that invariants living in prompts are not merely weakly enforced, they are unenforceable - there is no mechanism to detect their violation, so there can be no enforcement trail. Moving them to rails converts a silent failure into an intercepted one. That conversion is what makes long-horizon systems auditable at all.

Limitations, stated plainly

This is a study of long-horizon coding agents. Coding has properties most domains lack: verifiable intermediate artifacts, runnable tests, and a definition of 'stuck' that is comparatively easy to detect. An outer loop that supervises coding trajectories has strong signals to supervise with. A sales agent or research agent has far weaker ones, and the paper does not establish that outer-loop supervision transfers when the signals are mushy.

The evaluation is the authors' own, on their own architecture and benchmark selection. We do not know how the reported advantage over static harnesses varies with model, task family or run length beyond what they report, and we do not treat their numbers as a general result.

Rails also carry real costs the paper touches only lightly. Every rail is latency before or after every tool call; every additional check is another component that can misfire and block legitimate work. A runtime with 40 rails is a runtime where the agent spends its life in customs. The paper gives an architecture, not a budget for how many rails is too many.

Finally, the shared substrate binds both loops to one implementation. If the substrate has a bug, both loops inherit it, and the separation of concerns that makes Planner/Executor/Verifier architectures audit-friendly is here traded for integration. That is a defensible trade, but it is a trade, and the paper does not quantify its downside.

Why builders should care

If you operate an agent with any rule you actually cannot afford to break - never email a customer without a record, never delete evidence, never spend over budget - you face a choice: put the rule in the prompt and hope, or put it in the runtime and know. The prompt version fails silently and degrades over long sessions. The rail version fails loudly, at the moment of violation, with the violating call in hand.

The second practical benefit is maintenance. Prompt-encoded rules are duplicated across your system and drift apart; rails are code, so they live in one place, have tests, and have version history. When a rule changes, you change one interceptor and its unit test, not five paragraphs scattered across your prompt library, hoping you found every copy.

The third is debugging. A rail logs every interception, including the near-misses it blocked. Over weeks of operation, that log becomes a map of exactly where your agent most wants to do the thing you forbade - which is the most valuable behavioral signal you will ever get about your own system.

Ernesta Labs interpretation

LABS INTERPRETATION: We read openJiuwen as the systems answer to a problem most teams still solve with pleading. The two-loop architecture is interesting, but the durable contribution is the claim that enforcement points must be part of the runtime's structure - ordered, inspectable, and independent of model attention. Rules that matter are not instructions; they are code between the model and the world.

We also read the shared substrate as the paper's quiet second thesis: supervision is only as good as its access to ground truth. An outer loop reading the same event stream the inner loop produced supervises reality; an outer loop reading a summary supervises fiction. Teams building multi-process agents should check which of the two they have built - many discover, on inspection, that their supervisor is reading a fiction.

What we would implement

LABS RECOMMENDATION: Move every invariant you cannot afford to break out of the prompt and into a runtime lifecycle hook. Concretely: (1) define interception points at session start, before each external effect, after each observation, before any 'done' verdict, and at teardown; (2) attach each critical rule to one point as a small, independently testable function that can block or annotate; (3) keep a strict ordering so rail behavior is deterministic and composable; (4) log every interception, including the calls you block; (5) keep the prompt for style and judgment, and put exactly zero load-bearing safety rules in it - anything still in the prompt is, by definition, a rule you are comfortable seeing violated on a long enough run.

We would also implement the shared-substrate discipline wherever we run a supervising process: the supervisor and the worker must read the same event log, and the log, not any derived summary, is the supervisor's evidence.

What we would not implement

We would not implement the inner/outer loop split as the paper's structure if it means coupling our supervision into the same runtime process as execution - for our systems, keeping the verifier in a separate process with its own read path over the shared log buys auditability that integration would cost. We would not rail everything: checks that are conveniences, style preferences or heuristics belong in prompts, not interceptors, or the runtime becomes a bottleneck the model fights against. We would not copy the coding-agent-specific stuck-detection signals to domains where they do not exist, and we would not let rails rewrite agent behavior silently - a rail that silently edits a tool call creates an agent whose transcript no longer matches its actions, which destroys the audit trail that made rails worth having in the first place.

Practical test: count your unenforceable rules

Take thirty minutes today and audit your own agent's safety case. Open the system prompt and every task template. Extract every sentence of the form 'always X', 'never Y', 'must Z'. For each rule, ask one question: if the model ignores this rule on the very next call, does any code in my system notice?

Sort the rules into two piles. Pile one: no code notices - these rules are wishes, and they will be violated eventually, silently, on a long enough run. Pile two: code notices - these are invariants. Then take the single most expensive wish in pile one - the rule whose violation costs you the most, whether that is money, a customer relationship or evidence - and implement it as one interceptor: a function that runs before the relevant tool call, checks the rule, blocks on violation and logs the attempt. One rule, one hook, one test. Repeat weekly until pile one is empty of anything you actually care about. The audit itself is the lesson: most teams find their entire safety case in pile one.

What remains unknown

• How well outer-loop supervision over a shared substrate transfers to domains without coding's strong intermediate signals - the paper evaluates coding agents only, and 'stuck' is much harder to detect in, say, a sales relationship.
• How many rails a runtime can carry before enforcement overhead and misfires cost more than the violations they prevent; the paper gives an architecture, not an enforcement budget.
• Whether the integration of both loops on one substrate is a net win over separated processes reading a shared log - the auditability trade-off is not quantified.
• How rule adherence under rails degrades as the rail count grows and as contexts lengthen, relative to the static-harness baselines reported by the authors on their own evaluation.

Primary sources

• openJiuwen (arXiv:2608.27969)