Code is becoming the operating system that agents run on

There is a familiar story around LLMs by now: the model writes code, fixes bugs, calls tools, and sometimes clears benchmarks at the level of a decent intern.

A new infrastructure for agents

AI writes code, fixes bugs, calls tools, sometimes even clears benchmarks at the level of a decent intern. But the survey Code as Agent Harness proposes a far more interesting turn. Its authors argue that code is becoming the operating environment through which an agent thinks, acts, holds state, checks itself and coordinates with other agents.

That matters. The old question was how well a model generates a program. The new one is different: how do you build the system around the model so that it works reliably on long, multi-step tasks. Code turns out to be the scaffolding rather than the goal. Through it the agent runs computations, talks to APIs, saves intermediate artifacts, reads logs, updates the plan, tests hypotheses, and even splits work with other agents.

The survey is enormous in scope, but its central idea is surprisingly clear: if we want genuinely autonomous AI agents, improving the model alone will not get us there. You have to design the agent harness — the system that turns a text brain into an executable, verifiable, stateful machine.

The core idea: code as the “coupling” between model and world

The authors introduce a framework they call code as agent harness. The harness is the software layer around the LLM: tools, sandboxes, memory, validators, logs, permissions, execution loops and feedback channels. That layer is what turns a token generator into an agent that can do something in the world.

The survey's key claim is that code fits this role for three reasons.

First, it is executable. Reasoning in text can sound convincing; code can be run and checked against what it actually does.

Second, it is observable. Code leaves execution traces, variable values, runtime errors, test results. The system gets not only the final answer but the trail of how the agent reached it.

Third, it is stateful. A program, a file, a test, a log, a config, a script — all of it can be stored, edited, reused and passed between steps and between agents.

Here the survey hits a nerve in the current market for agent systems. The practical limit today is often not that the model thinks badly, but that it has no reliable execution environment: memory, control, verification, safe actions, stability over a long horizon.

Three layers of the whole design

The authors suggest looking at the subject in three layers.

The first is the harness interface: how exactly code connects the agent to reasoning, to action, and to a representation of the environment.

The second is harness mechanisms: planning, memory, tool use, running the plan–execute–verify loop, and optimizing the harness itself.

The third is harness scaling: how a single agent becomes a multi-agent system in which code is the shared workspace.

The strength of this structure is that it pulls scattered lines of work — coding assistants, interface automation, robotics, scientific agents — into one engineering picture.

How code helps an agent reason, act and “see” its environment

The clearest part of the survey is the first layer, where code acts as the interface.

Code for reasoning is a familiar idea, and still a powerful one: rather than computing everything in text, the model pushes intermediate computation into a program. It writes a short snippet, runs it, and relies on the result. That cuts errors in arithmetic, logic and step-by-step derivation. Then it gets more interesting: the system can use not just the program's final output but execution traces, intermediate states, formal proofs and machine verification.

Code for action is no longer about solving a task; it is about taking a step in an external environment. A program can be a robot control policy, a script of clicks in an interface, a chain of tool calls, or a temporary skill the agent wrote for itself. Here code is how an abstract intention becomes a concrete executable action.

Code for environment modeling may be the most underrated idea of the three. An agent's environment can be represented not only as text but as a repository, tests, logs, a simulator, interface state, transition scripts. The agent then works on top of an explicit computable structure instead of in fog. The world becomes more checkable and less magical.

Why does this matter? Because without such an interface the agent stays a creature with short memory and a weak grip on reality. It can explain beautifully and act badly. Code makes actions and state objects of engineering rather than objects of good prose.

Mechanisms: where an agent either improves or falls apart

The survey's most practical contribution is its breakdown of the mechanisms without which an agent does not survive past a single turn.

The first is planning. On long tasks, generating an answer once is not enough. The task has to be broken into sub-steps, intermediate goals pinned down, dependencies between files and actions understood, and sometimes several alternative trajectories explored. The authors trace the evolution from linear "step 1, step 2, step 3" plans to heavier machinery: dependency graphs, tree search over decisions, orchestration of several roles.

The second is memory, and not merely in the sense of a long context window. An agent's memory is a managed state layer: what to hold in mind right now, what to retrieve from the repository, what to save as useful experience, what to compress, what to push into external storage. For real tasks this is critical. The repository, the run history, logs, tests, the hints already found — none of it fits in the active context, and all of it has to stay reachable.

The third is tool use. A tool in this framing is not simply the model calling a function. It is a controlled boundary between the agent's intention and an external system. Which tools are available? Under what permissions? Where does the code execute? How are results sanitized? How are actions logged? Which call requires a human? Reliability — or chaos — is born at this level.

The plan–implement–verify loop fits this picture especially well. The authors argue for treating debugging not as after-the-fact repair but as the main control loop. The plan sets a contract: what we want to change and how we will know it worked. Execution makes a bounded change in a sandbox. Verification decides whether to accept the new state, roll it back, fix it, or hand it to a human.

This sounds close to trivial, but it is exactly the line between a demo agent and a system you can trust with anything more serious than a toy task.

Multi-agent work: code as the shared workspace

The section on scaling to multi-agent systems is another strong one. The industry likes to talk about teams of agents: manager, planner, coder, reviewer, tester. The survey shows that the roles are not the point — the shared executable substrate they coordinate through is.

Code, tests, logs, the repository, intermediate patches, execution scripts — all of it becomes a common field where agents see each other's work, check changes and synchronize state. And an important engineering point surfaces here: multi-agent work is not several models in a chat. It is close to a distributed systems problem.

The authors are candid about how much goes wrong in such an architecture: diverging views of state, stale plans, conflicting edits, context overflow, no clear answer as to whose version is the right one. So the future, on their reading, is not simply more agents but a more formal representation of shared state: shared boards, repository-level memory, transactional synchronization, explicit merge rules and re-verification.

That is worth saying now, when multi-agent systems often win not because of collective intelligence but because they compensate for a weakly structured environment with extra roles and elaborate coordination schemes.

Where this already works in practice

The survey is also good at not getting stuck in abstractions. The authors show where the approach is already taking material form.

First, coding assistants. Everything is in place here: repository, tests, terminal, patches, pull requests, verification of the result. This is probably the most mature domain for code-based harnesses.

Second, GUI and operating-system agents. There, code turns on-screen actions into executable scripts and interface state into a structured environment.

Third, scientific agents. This one is especially interesting: hypothesis, experiment, simulation, analysis and write-up can become a single long executable chain. Science, seen this way, is nearly an ideal world of programs.

Fourth, embodied agents and robotics, where code becomes the boundary between linguistic intention and physical action.

And finally personalization, where user state, constraints and adaptation rules also start taking shape as explicit, editable, checkable artifacts.

What the paper gets right

This is a survey, not an experimental paper with one new model and a tidy SOTA table. That is exactly where its value is. It promises no miracle fix; it assembles a scattered field into a single engineering discipline.

The authors are precisely right that the weak spot of agent systems is not only model quality but the quality of the environment around it: verification, memory, permissions, reproducibility, synchronization, risk management. Leave that undesigned and any smart model eventually runs into systemic brittleness.

The list of open problems matters most of all. How do you evaluate not just final success but the quality of the harness itself? How do you check semantic correctness when tests are incomplete? How do you improve a harness without regressions? How do you keep shared state consistent across several agents? How do you put a human into the safety loop? How do you extend all of this to multimodal environments?

The takeaway

Code as Agent Harness is not a paper about one more trick for LLMs. It is an attempt to redefine what the conversation is about: not how a model writes code, but how code becomes the environment an agent lives and works in.

In that sense the survey lands squarely on the current moment. The industry has already seen that a bare model is not an agent. The next stage is learning to build reliable, executable, verifiable, stateful systems around it. Code is the strongest candidate for the shared language between reasoning, action, memory and coordination.

Put briefly, the paper's main conclusion is this: the future of agentic AI systems is set not only by the power of the model but by the quality of its harness. Which means the next big discipline in AI may be not only model architecture, but harness engineering.