The Agent Harness as an Operating System: Capabilities, State, Execution, and Lifecycle

The demo agent works. It reads the file, runs the test, patches the bug. Then it ships to a second tenant, the session runs for six hours, the process dies at hour four, and nobody can tell you which layer owned the checkpoint. The model was never the problem.

The default mental model for an agent is a while-loop around a model: call the model, dispatch a tool, append the result, repeat. That model is correct for a chat session and quietly wrong for everything else. It assumes single-tenant execution, a crash-free process, unbounded context, and permissions that never need to be revoked. None of those assumptions survive contact with long-horizon work.

I have spent enough years building systems to trust one diagnostic: when a design keeps failing in the same place, the abstraction is missing, not the code. The missing abstraction here is the harness as an operating system. Not because the metaphor is flattering, but because an OS designer is forced to answer the questions the loop model hides: who owns state, who may mutate it, who schedules the next step, and what happens when the process dies mid-write.

Why the Loop Model Breaks Down

The action/observation loop treats the harness as plumbing. The model decides; the harness routes. That division of labor is real, and it is also incomplete, because it silently assigns four concerns to nobody:

• Capability boundaries. Which tools exist, which are granted to this session, and which actually ran.
• State ownership. What lives in the context window, what lives on disk, and which one is the source of truth.
• Scheduling. Who decides the next step, when to stop, and when to spawn a subagent.
• Lifecycle. How a run initializes, checkpoints, recovers, and tears down.

The loop model does not fail because it is wrong. It fails because it is silent. Silence is fine until two engineers disagree about where the approval gate lives, or until a crash reveals that the only copy of the plan was in a context window that no longer exists.

The invariant to carry forward: every harness decision is a decision about who owns state and who is allowed to change it.

The OS Analogy: What Maps and What Does Not

The analogy earns its keep when it forces ownership questions. It maps cleanly in four places:

Then it breaks, and the break matters more than the mapping. A process executes instructions deterministically; a model reinterprets its instructions on every call. There is no hardware trap. When a CPU executes a privileged instruction, the trap fires whether the program wants it or not. When a model attempts a privileged action, nothing fires unless you built the gate. Enforcement in an agent harness is not a hardware guarantee. It is application code, and application code has bugs.

The second break is subtler. An OS kernel is stable across programs because the instruction set is fixed. A harness co-evolves with the model it wraps. Tuning that helps one model can hurt another, which means the boundary between model-specific tuning and durable runtime contracts has to stay visible in your code, not just in your head.

Use the analogy when it forces you to answer "who owns this state and who can mutate it." Drop it when it tempts you to name modules after kernel internals and call that architecture.

Capability Boundaries: Tools, MCP, and the Permission Surface

Capabilities are the harness's syscall table. Every tool, MCP server, or skill is a boundary where policy, authorization, and audit attach. The useful discipline is to separate three things that teams routinely collapse into one list:

• Declaration — what capabilities exist in the system.
• Grant — what this session is permitted to use.
• Invocation — what actually ran.

MCP standardizes the interface and discovery layer. It does not standardize trust. Authorization still lives in the harness, and that is where it belongs, because the harness is the only layer that knows the tenant, the session, and the approval history.

The failure mode is capability sprawl. Every added tool consumes context budget and expands the blast radius of a confused model. Deferred loading — keeping unused tool schemas out of the context window until they are needed — is the countermeasure, and scoped grants are the second one.

Concrete check: can you enumerate, per session, every capability that was reachable and every one that was invoked? If not, you do not have a permission surface. You have a function list.

State: Working Set, Durable Artifacts, and Context as a Cache

Three kinds of state live in a harness, and conflating them causes the most common long-horizon failures.

The working set is the live context window: expensive, volatile, and lossy. Treat it as a cache, not a database. It will be compacted, and compaction is lossy by design.

Durable artifacts are the source of truth: filesystem, git, checkpoints, session stores. They survive compaction and crashes. The filesystem is not just storage; it is the collaboration surface where multiple agents and humans coordinate through shared files.

The compaction contract is the agreement about what must be preserved verbatim, what may be summarized, and what must be re-derivable from artifacts. Without that contract, compaction is a coin flip on whether the agent remembers the constraint it was given an hour ago.

The failure mode is state that exists only in context. When the window is compacted or the process dies, the work evaporates, and the agent restarts from a summary that lost the one detail that mattered.

Design question: for every piece of state, name its owner, its lifetime, and its recovery path. If you cannot name all three, you have not designed the state layer.

Scheduling and Control Flow: Who Decides the Next Step

Orchestration is a scheduling problem, and the control-flow spectrum is a tradeoff between expressiveness and controllability:

• Single agent loop — simplest, hardest to bound, fine for short tasks.
• Event-driven — reacts to external signals, good for long-running work.
• State machine — explicit transitions, testable, less flexible.
• Graph/flow — declarative structure, strong for known decompositions.
• Hybrid — model-directed inside deterministic boundaries.

The harness, not the model, owns the stopping condition, iteration limits, and handoff rules. This is the part teams get wrong most often: they try to bound loops in the prompt ("stop after five attempts") when the bound belongs in the scheduler, where it is enforced rather than suggested.

Subagent spawning is process creation. It should have isolated context, explicit inputs, and an explicit return contract. A subagent that inherits the parent's entire context is not a process; it is a copy, and copies drift.

Decision rule: choose the least expressive control flow that still handles your uncertainty. Escalate to model-directed control only where the branch is genuinely unknown.

Lifecycle: Initialization, Execution, Recovery, Teardown

Make the agent's life cycle explicit, or it will be implicit and wrong.

Initialization provisions the environment, sets up tooling, grants capabilities, and loads system instructions from versioned files. Versioned matters: instructions that live only in a database row are instructions nobody can diff.

Execution defines checkpoint cadence, approval gates, and the boundary between resumable and non-resumable work. That boundary is a design decision, not an emergent property.

Recovery is checkpoint-and-resume versus restart-from-scratch. Resume is only safe when the work between checkpoints is idempotent. A tool call that charges a card or sends an email is not idempotent, and a resume that replays it is a bug with a billing address.

Teardown destroys sandboxes, revokes credentials, and decides artifact retention. This is the part everyone forgets until it costs money or leaks data.

Failure mode: non-idempotent tool calls that make resume dangerous, forcing full restarts and wasted budget. The fix is at the tool contract level, not the retry logic.

Observability and Evaluation of the Harness Itself

Most teams evaluate the model and instrument nothing else. That is backwards, because the harness is the layer you actually control.

Trace the harness, not just the model: tool dispatch, approval decisions, compaction events, checkpoint writes, retries. Then track harness-level metrics — capability invocation counts, context pressure, recovery frequency, cost per completed task, stuck-loop detection.

The payoff is diagnostic. Many failures that look like reasoning failures are interface mismatches, missing tools, or bad state handoffs. A model that "forgot" a constraint may never have received it after the third compaction.

Evaluation question: if this run failed, could you tell from traces alone whether the model, the tool, or the state layer was at fault?

Where the Analogy Stops Paying Rent

The OS lens is a tool, not a religion. It stops paying rent in specific cases:

• Short-lived, single-session, low-stakes tasks do not need process isolation, checkpointing, or a scheduler. A loop and a few tools are correct, and adding more is overhead.
• Do not build a general capability system before you have two real capabilities that conflict.
• Do not adopt multi-agent scheduling to solve a problem that is actually a missing tool or a bad prompt.

And keep the co-evolution warning in view. Harness choices and model behavior shape each other. A harness tuned to one model's quirks may not transfer, so keep the boundary between model-specific tuning and durable runtime contracts visible in the codebase.

The gaps you find are your harness backlog, and they are almost never in the model.