Agents need operating systems, not longer prompts

01 · The prompt ceiling

Instructions are necessary. They are not an execution environment.

Teams often respond to an agent failure by adding another paragraph to the system prompt. The agent forgot a constraint, so the prompt gets a warning. It used the wrong tool, so the prompt gets a rule. It stopped before the tests passed, so the prompt gets a completion checklist. This can help for a while. Then the prompt becomes a fragile policy document that the model must reinterpret on every turn.

The failure is usually architectural. A prompt cannot make a stale document current. It cannot prevent a process from reaching the public network. It cannot roll back a migration, acquire a lock, preserve a transaction, or prove that the changed code satisfies the requirement. It can ask the model to do these things. Asking is not enforcement.

This distinction matters because an agent is not only generating text. It is taking actions across time. Once a model can read files, call APIs, change records, or run code, the surrounding loop becomes the product. The prompt is one policy input to that loop.

If a rule must hold every time, encode it at the boundary where the action happens.

02 · The application layer

A dependable agent needs six services around the model.

The useful analogy is an operating system, not because an agent harness must mimic a kernel, but because it must mediate scarce resources and unsafe actions. It schedules work, exposes capabilities, isolates execution, records state, and decides what happens after failure.

Anthropic separates predefined workflows from agents that direct their own process and tool use. That distinction is valuable, but both forms still need an augmented application layer. The more freedom the model receives, the more explicit that layer must become.

03 · State and context

Memory is a data design problem before it is a model feature.

A long transcript looks like memory, but it is only an ordered record of messages. It mixes goals, guesses, tool outputs, corrections, and obsolete facts. As the run grows, the model must infer which statements still apply. Compaction can reduce the volume, but it does not create a source of truth.

Use explicit state for facts that control execution. Store the current objective, accepted constraints, pending approvals, produced artifacts, verification results, and unresolved errors in structured records. When a value changes, record the new version and the event that caused it. The model can then reason over a compact view while the system retains the full audit trail.

Context should also be assembled, not dumped. Give the agent the relevant repository files, current issue state, approved design decisions, and recent failures for this step. Add source identifiers and timestamps. A small packet of current evidence is more useful than a large bag of plausible text.

This is where a knowledge graph can earn its place. It can connect people, systems, decisions, and events while preserving their origin. It should not become an expensive synonym for search. Use it when relationships and change history affect the decision.

04 · Tools and authority

The tool contract is part of the reasoning surface.

A model can only choose well among capabilities it can understand. Tool names, descriptions, parameters, return types, and error messages therefore shape agent performance. The Model Context Protocol formalizes this with named tools, input schemas, optional output schemas, and structured results. The protocol also tells servers to validate inputs, enforce access controls, rate-limit calls, and sanitize outputs.

Good tools express intent. Prefer create_release_candidate over run_arbitrary_shell with a paragraph of procedural instructions. Prefer issue_id and target_status over one free-form command string. Return the changed resource, its version, and the evidence needed for the next step. When a call fails, report whether it is safe to retry and what input can fix it.

Permissions belong beside those contracts. A code-review agent may read the repository and CI logs but must not merge. A release agent may create a signed candidate but must pause before production. A support agent may draft a credit but must not issue it above a threshold. These are product rules, not prompt suggestions.

OpenAI describes sandboxing and approvals as complementary controls: the sandbox sets the technical boundary, while approval policy defines when a request may cross it. That division is durable. It also gives operators a clear place to change policy without rewriting agent behavior.

05 · Verification and recovery

An agent should finish when the evidence says it is done.

The model's final message is not a completion signal. Completion comes from an independent check of the resulting state. For code, this may combine targeted tests, static analysis, security checks, and an artifact inspection. For a business workflow, it may require schema validation, policy checks, duplicate detection, and confirmation from the system of record.

Terminal-Bench makes this separation explicit. Its tasks are scored by tests over the final container state, not by the commands the agent prints. Its failure taxonomy includes premature termination, no or incorrect verification, weak verification, context loss, and repeated steps. These are not exotic research errors. They are common production failure modes.

Recovery must be designed before the first failure. Classify errors as retryable, correctable, blocked, or terminal. Cap identical retries. Preserve a checkpoint before external writes. Attach idempotency keys to operations that may run twice. If a verification fails, return the failed criterion and relevant evidence to the agent instead of the entire log stream.

A stopped run should be legible. An engineer must be able to see what the agent intended, what it changed, what check failed, and which authority boundary prevented further action. Without that record, every failure becomes a forensic exercise.

06 · Build order

Start with one bounded loop and earn more autonomy.

Do not begin with a general agent and a broad tool belt. Begin with one task that has a clear input, a valuable output, and an objective check. Keep the action space narrow enough that failures teach you something.

The following order keeps the system understandable while capability grows.

1. Write the task contract: inputs, acceptable outputs, forbidden actions, and stop conditions.
2. Build one deterministic path that completes the task without a model. This reveals the real interfaces and controls.
3. Insert the model only where judgment or synthesis is useful. Keep routine transitions in code.
4. Add typed tools and least-privilege credentials. Make writes idempotent before enabling retries.
5. Create an evaluation set from real cases, including failures and adversarial inputs.
6. Run in observe-only mode, then permit reversible actions, then add gated high-impact actions.
7. Review traces and failures on a schedule. Promote new failure cases into regression tests.

Autonomy is not one switch. It is a set of separately granted capabilities, each backed by evidence.