A harness can’t keep an agent’s future-dated promises. An agent OS can.

Kendall Clark · Pentad Labs · 20 September 2026 · PLRN-027

Abstract

The clearest inventory of an agent harness, from Charles Holloway’s recent talk, assigns seven authorities to the layer between a model and the world: context and state, tools, execution, orchestration, verification, observability, and governance with recovery.

Each is stated relative to an agent run. A run is what a harness is for. An operating system for agents, however, is not a bigger harness but a different kind of thing: it’s the owner of facts that exist between runs and cannot be owned by any of them.

That argument is right but also incomplete in a way that implementation exposes.

When we built rollback for agents that fail mid-plan, we reached for the Saga discipline and found we could not put it where Holloway’s inventory says it goes. Recovery, which the inventory files under the harness, cannot be held by anything with a harness’s lifetime. The reason is not scale. It’s that a compensation obligation may need to survive for weeks, and a harness ends with the run. An obligation can’t be held by a ghost.

One test settles the placement of every authority in the inventory: the lifetime of the obligation it carries:

Applied cleanly, the test splits several of the seven into a per-run face and a substrate face, and it leaves the harness inventory correct about what a run needs while correcting where some of it must live.

The agent OS is not a superset of the harness, and the harness is not a subset of the OS. The boundary between them is drawn by lifetime, not by feature count.

Bottom-line: the question to ask of any agent authority is not how big it is but how long it must be honored. The answer to the second question decides which side of the line it belongs on.

1. The received inventory and its scope

Holloway’s inventory is the best available because it’s explicit about its scope. A harness is a control plane for one agent doing one job. Its authorities are the facts the model cannot safely assert about itself: what this run can see, what this run may call, where this run’s work happens, who may stop this run, and so on. Each authority owns a fact the model’s say-so cannot settle, which is the correct test for what makes something a harness authority at all.

The inventory is stated relative to a run. The scoping is not a limitation, it’s the definition. A harness that didn’t end with its run wouldn’t be a layer between a model and the world for this run; it would be something else. So when recovery appears among the seven authorities, packaged with governance, the packaging is honest about what a single run needs when it fails. The run’s own plan is unwound, the run’s own journal records it, and the control plane that admitted the work decides what happens next.

What the inventory doesn’t ask is how long any of these obligations must be honored. That’s a question a regulated enterprise rarely stops asking. It doesn’t arise for a run, because a run ends and its authorities end with it. It arises the moment an agent’s effects outlive it, which is the normal case for an enterprise agent and the only case an auditor is interested in.

2. The lifetime test

An authority is a cause or source of obligation. To own context and state for a run is to be obliged to keep the run’s window coherent until the run ends. To own verification is to be obliged to check the model’s claim before the claim is acted on. To own recovery is to be obliged to undo what the run did if the run cannot finish. Obligations have scopes, that is, lifetimes. The lifetime of an obligation is independent of the lifetime of the thing that created it until someone asks where the obligation lives.

The test is this: if an obligation is discharged within the lifetime of the run that created it, its holder may be the harness, because the harness is there for the whole of the run. If an obligation must be honored after the run ends, its holder can’t be the harness, because the harness is no longer there. The obligation-holder must be a thing that exists while any run runs and while no runs run. That thing is what we call the agent’s substrate or the agent operating system, because that’s what a pre-agent operating system is.

The objection worth answering here is that an obligation can be handed off. A run can write its compensation to a file and the next run can pick it up. This is true and it doesn’t make a difference. A file isn’t a holder; a file is a fact. Something must still be obliged to read the file, re-arm the trigger it names, and fire when the trigger becomes true. That obligation is the same one the run can’t hold. Handing an obligation to a log doesn’t discharge it; at most it relocates the obligation to whatever owns the log, which is the substrate by the same test.

This isn’t a new criterion. It’s our supervisor-mode criterion from the fleet argument, read for time instead of for rewrite-authority. The policy that bounds a run must sit outside what the run can rewrite, because an optimizer that can widen its own permissions will widen them. The obligation that outlives a run must sit outside what ends with the run, because a holder that ends before the obligation it holds isn’t a holder.

Same shape, second axis.

3. The case that forced the explicit test

An agent that does part of a job and then fails later has to undo the part that succeeded. The standard undo is a compensation and the standard discipline for running compensations in order is a saga (PLRN-011). Holloway’s inventory files recovery with the harness. Two facts make that placement impractical, and both are the lifetime test failing.

The first is that the agent is untrusted code, arbitrary from the substrate’s perspective, and a saga whose compensations are written by the party most likely to get them wrong isn’t a guarantee worth offering. The second is that agents are transient: the process that formulates a compensation is torn down minutes after the agent goes quiet, while the compensation timer may run for weeks. The detail of both is in PLRN-011. What matters here is the shape of the failure. Formulating a forward-and-inverse pair needs the agent’s intent, the answer to what this action is for and what undoing it would mean, and that context exists only while the agent is live. Custody of the formulated inverse and its firing on a trigger must outlive the agent, because the trigger may not arrive for weeks.

One authority, two lifetimes, and the two can’t be held in the same place.

4. Bifurcation

The resolution is to split the authority where its two jobs have different lifetimes:

The architecture is the split of lifetime, not the count of processes.

Recovery is not the only authority that splits this way, though it’s the one implementation forced first. Recovery sits inside governance in the received inventory; counting by that inventory’s entries, four authorities stay per-run and three split at the seam.

Verification splits at the same seam: the check that this run’s claim is true before this run acts on it is per-run, but the check that the policy a verdict was issued under is the same policy as on run ten thousand is a fact between runs. No run nor harness can hold it. The substrate doesn’t assert that the policy is right; it attests that the policy is identical, which is the part that can’t be discharged inside any one run and the part an auditor actually asks for.

Observability splits, too: the append-only journal of a run is per-run, but the single record with one clock that an auditor’s range query asks for lives between them.

And governance splits: the gate that decides whether this result ships is per-run, but the rule that bounds every run must sit outside every run and cannot be rewritten by any of them.

What doesn’t split is what’s genuinely discharged within the run. Context and state as a window and a private memory; tools as a list with schemas the run may call; execution as the sandbox the run’s work happens in; orchestration as the sequence plan-implement-verify-stop.

Each of these has obligations that end with the run, and the test confirms the inventory’s placement of them. The substrate has its own names for their fleet-scoped faces (protection, capabilities, the process boundary, the scheduler), but those are different authorities answering contention, not the same authorities with longer lives.

The inventory survives the test. Several of its members do not, as stated. The correction isn’t that Holloway was wrong about what a run needs. It’s that an authority is not one thing when its obligation has two lifetimes. The inventory was written before the second lifetime was in view.

5. Neither a superset, nor a bigger anything

It’s tempting to read the migration of custody as the operating system absorbing harness authorities, and from there to conclude that an agent OS is a superset of a harness, or that a harness with enough additions becomes an operating system after all. Neither reading survives the test.

The agent’s operating system doesn’t contain harness authorities as parts. The per-run faces remain per-run. Formulation is still done by the thing with the agent’s intent, inside the run’s lifetime. When the run ends, that face ends with it, which is correct because nothing it does needs to outlive the agent.

What moved is only the custody, and it moved because it couldn’t be held where the inventory put it, not because the substrate wanted more authorities. A superset relation would have the substrate doing the harness’s job plus more. The substrate can’t do the harness’s job. It has no access to the intent a formulation needs, by construction, because it exists outside the run.

Nor is the harness a subset of the operating system. Programs aren’t subsets of operating systems, and neither are users. The harness’s authorities aren’t drawn down from a larger menu the substrate owns. They are answers to contention the substrate never faces directly; namely, the contention between a model’s claims and the world, within one run. Likewise, the substrate’s authorities answer a contention the harness never faces at all: the contention among runs over shared resources and the obligations that outlive runs. Each owns what the other can’t, and neither is the other’s part.

The relationship is the one already named elsewhere: Unix isn’t libc and libc isn’t Unix, separate despite co-evolved. The C runtime grew every convenience a program could want and never became the kernel, because the kernel’s job is to be the thing the program can’t rewrite, and a library is by definition linked in. The lifetime test adds the time-axis reading of the same line. The kernel is also the thing still there after the program exits. Anything that must still be honored after exit is the kernel’s business.

6. The question to ask

The discipline this note argues for is a single question, asked of every authority in an agent architecture: how long must this obligation be honored?

The answer decides placement without reference to scale, to feature count, or to whether the thing being built calls itself a harness, a framework, a runtime, or an operating system.

Names track marketing. Lifetimes track structure.

Asked of Holloway’s seven, the question leaves four per-run and splits three (recovery counted inside governance, as the inventory has it). Asked of the two the fleet adds, accounting and identity, it confirms both: a budget window runs longer than any run, and an agent’s identity outlives any session (at least, WunderOS’s notion of an agent’s identity, there are others), so neither can be held inside one. Asked of whatever authority is added next, and one will be, it settles the placement before the implementation begins rather than after it fails.

What the test doesn’t decide

The test is stated and argued, but it’s not yet exercised against every authority an enterprise agent deployment actually carries. The inventory it’s applied to, Charles Holloway’s, is the best published one, but not a final, complete one. The harder open question is whether some obligation resists the split altogether: an obligation that outlives the run but can’t be formulated outside it. None has surfaced in the construction so far, so the test hasn’t been stressed in that way yet.

The test also doesn’t decide the count of processes or the placement of a role. Whether the coordinator is a separate process or inline logic in the shadow agent is an implementation choice, as PLRN-011 says of its own construction. The architecture the test fixes is the split of lifetime, nothing else.

Finally, the test presupposes that a substrate exists to hold what must outlive the run, which isn’t surprising given its provenance inside an ongoing effort to build an operating system for agents.

Obligations don’t go away when you stop holding them. Where there’s no agent operating system, they simply go unheld. The enterprise names for unheld obligations are the ones familiar from adverse audit reports and occasionally headlines: silent policy drift, unauditable spend, uncontrolled state. Findings, not crashes. The test explains why those findings recur in harness-only deployments without claiming to fix them itself.

The saga discipline is Garcia-Molina and Salem’s (Sagas, 1987), and its placement off the agent and into a durable per-tenant holder is worked out in PLRN-011, which this note reads as the forced case of the general claim. The supervisor-mode criterion, that the policy bounding a run must sit outside what the run can rewrite, is Holloway’s, stated for the self-improving case in his Build Your Own Harness inventory and applied fleet-wide in An agent fleet needs a new kind of OS, not a bigger harness, whose structural argument this note extends rather than revises. The per-agent lifecycle the saga must outlive (hibernation on idle, teardown on disconnect) is the sleeping-agent construction of PLRN-026. The durability of the forward-and-compensation pair under a single barrier is the transactional-outbox line of Netherite (Burckhardt et al., 2022, arxiv:2103.00033).

This PLRN’s contribution is the test itself: that the placement of an agent authority is decided by the lifetime of its obligation, that the criterion splits the received harness inventory without revising what a run needs, and that the result fixes the boundary between harness and operating system as a structural boundary rather than a scalar one.

A note on method

Written in conversation with Kimi K3 as a first-drafter. The argument, the lifetime criterion, and the architectural commitments are mine.

Kendall Clark · k@pentad.ai
Great Falls, Virginia
20 September 2026