2026-08-06

The Agent Needs an Operating System

A clever agent loop can produce an impressive answer. A software factory has to produce the next right action, survive interruption, reject bad work, and remember why any of it happened.

A loop is not an operating system

The simplest agent architecture is seductive: give a model a goal, let it call tools, feed the result back, and stop when it says the work is done. That is enough to demonstrate motion. It is not enough to operate production work where partial progress, conflicting evidence, unavailable tools, and bad assumptions are normal conditions.
The missing layer is not a more persuasive prompt. It is an explicit machine around the model. The machine owns state, decides which role acts next, limits what that role may touch, records what changed, and determines whether the result may advance. The model proposes moves inside that system. It does not get to redefine the system while playing.
Our position is that this distinction will decide which organizations get durable leverage from agents. Teams buying isolated model interactions will keep supervising fluent improvisation. Teams building operating systems for agent work will turn the same underlying capability into machinery that can run, recover, and improve without a person translating every handoff.

State must outlive the conversation

A conversation history is a poor production database. It mixes instructions, evidence, guesses, tool output, and decisions into one growing transcript. Important facts disappear into compression. Rejected ideas remain nearby enough to return as if they were settled. When the run restarts, the factory either loses its place or replays an expensive story to reconstruct it.
Store operational state as operational state. The current objective, accepted plan, completed work, unresolved questions, produced artifacts, validation results, and remaining budget should have explicit homes. Each transition should name what it consumed and what it produced. Then a worker can receive the slice it needs instead of inheriting every thought that came before it.
Durable memory is useful only when provenance survives with it. A remembered claim should point back to evidence. A decision should carry its owner and the conditions under which it can be reopened. Otherwise memory simply gives old mistakes a longer life. The factory should retain process and proof, not accumulate folklore at machine speed.

Specialization needs contracts

Advanced harnesses split work among planners, researchers, builders, reviewers, and other focused roles because one context should not perform every kind of judgment. Specialization can improve the work, but names alone do nothing. Five agents with different role prompts and the same unrestricted tools are still one blurry authority wearing five badges.
Give each role a contract. Define the input it may trust, the output shape it must produce, the tools it may call, and the condition that ends its turn. A planner may decompose work without changing the repository. A builder may implement an approved unit without approving its own expansion of scope. A verifier may reject the artifact without quietly repairing it and grading the repair.
Those boundaries make failures legible. If research arrives without provenance, the research contract failed. If implementation exceeds the approved change, the build gate failed. If weak evidence passes, verification failed. Without contracts, every defect becomes a vague complaint that the agent behaved badly, and the only available fix is another paragraph of prompt text.

Concurrency is a governance problem

Agents make parallel work cheap enough to attempt constantly. That does not make the results cheap to reconcile. Two workers can edit the same boundary, research incompatible assumptions, consume the same finite budget, or each make a locally sensible choice that breaks the combined system. More motion can create a faster collision.
Parallelize work only where the dependency graph permits it. Give workers isolated scopes, immutable inputs where possible, and explicit merge rules. Reserve shared state through the harness instead of hoping every agent notices everyone else. When results return, reconcile them against the accepted plan and the current artifact—not against the stale world each worker saw when it began.
This is also where human coordination starts disappearing. Scheduling independent work, tracking completion, retrying a failed unit, and routing a conflict are repeatable operations. Machines will perform them more consistently than a person maintaining status across chats and tickets. Human judgment should decide which conflicts change the destination. It should not be the message bus holding the factory together.

Proof closes the system

A harness becomes operational when success is a state the system can establish, not a sentence the agent can generate. Tool calls need observable outcomes. Retries need budgets and changed conditions. Evaluation needs evidence from outside the worker's own narrative. A run that cannot prove progress should stop, escalate, or choose a bounded recovery path instead of producing confidence until the clock expires.
Trace the transitions, not just the final answer. You need to know which state selected a role, which evidence supported a decision, which tool changed an artifact, why a retry was allowed, and which gate admitted the result. That record is how you debug the factory and how the factory learns without turning every historical output into trusted instruction.
The model will keep improving. That helps, but it does not remove the need for this machinery. Better engines still need steering, transmission, brakes, and instruments. The companies that win will not be the ones with the longest autonomous demo. They will be the ones whose agent operating system can direct specialized work, absorb failure, preserve proof, and keep running after the person who assembled the first prompt has left the room.
In response to Building an Advanced Agentic Harness by Data For Science, Inc..