Contents
Conventional software is a plan written ahead of time: compiled, testable, and given permissions that match what it was built to do. AI agents work differently. An agent follows what we call model-directed execution, consulting a language model at each step to decide what to do next, which sits uneasily with many of the principles developed over decades to secure and govern digital systems.
Most current approaches to monitoring agents rely on the natural language passed to and produced by the model, such as the prompt, the model's stated reasoning and the tool calls it announces. An agent's effect on the world, however, lies in its actions, the operations it has the operating system carry out, and the most complete and trustworthy record of those actions is kept by the kernel. Much of the distance between what a user wanted, what an agent intended and what the machine actually did opens up between these two layers.
Connecting them is challenging, because the same agent can take many shapes on a machine, spreading its behaviour across processes, network connections and time. We propose a world model of the operating system, a learned representation of how a machine's state evolves, as a foundation for detecting agents, understanding what caused their actions and governing what they are allowed to do. Our hope is that such a model can restore at runtime some of the assurances that compiled software has long offered ahead of time.
Section 1Agents are a new kind of program execution
For as long as software has existed, a program has been a plan written in advance. A programmer writes source code, a compiler converts it into a binary, and the paths that binary can take are fixed before it ever runs.
Beneath the program sit formal contracts with the machine: the instruction set, the system call interface, and the permissions the kernel enforces. Above it sits an informal one, between a program's author and its behaviour. What the program does is decided by its author and written down in its code. The plan can be read before it runs, tested before it ships, and given permissions that match what it was built to do. When something goes wrong, there is a line of code that did it, a person who wrote that line, and a trace the machine logged along the way.
Agents keep every formal contract with the machine. They run the same instructions, make the same system calls and work within the same kernel permissions as any other program. What they break is the informal contract between author and behaviour. An agent does not carry its plan. It carries a goal, and at each step it describes its situation to a language model, receives an instruction, carries it out, and repeats. We call this model-directed execution: the control flow of the program is chosen at run time by a model, from context it had beforehand and gathered along the way. The same agent, given the same goal twice, may do entirely different things.
Model-directed execution also changes where intent lives. In a conventional program, intent and execution logic are co-located. In an agent, intent is scattered. The user states it in a natural language prompt. A model interprets that prompt and re-expresses its interpretation as a sequence of steps, each re-interpreted as new context arrives. Those steps reach the machine as tool calls, which a framework translates into system calls. At every hop, intent is restated in a different language by a different party, and no single artefact holds all of it. The result is less a plan than a chain of successive reinterpretations, and the gap between what was asked for and what was done can open at any point in the chain.
To the operating system, an agent looks like any other program. It is a python or node process that opens files, runs bash, and makes network requests. Agents do not declare themselves, and nothing in the binary, the process table, or the permissions says “the actions of this program are being chosen by a model”. The kernel sees only the last link in the chain. This raises questions that systems research has answered for conventional software but not for agents. How do we identify agentic software running on a machine? How do we attribute an action to the agent, and the intent, that caused it? How do we detect when an agent has diverged from what its user wanted? And what should an agent be permitted to do, and how is that enforced? For ordinary programs, decades of work produced answers that now ship on billions of devices: process identity, user accounts, access control, sandboxing and audit logs. Each assumes that a program's behaviour was fixed by its author. Agentic software breaks that assumption, and needs answers of its own.
Model-directed software is mainstream, diverse and powerful
Three properties of the spread of model-directed software matter for what follows. It is mainstream, carrying most of the tokens served to production applications. It is diverse, built from many models and many harnesses whose combinations change from month to month, so there is no fixed target to monitor. And it is powerful, capable of increasingly sophisticated use of computers, and available in models anyone can download and run.
Mainstream. Model-directed software is now the dominant use of large language models. On Vercel's AI Gateway, which routes model calls for applications built on its platform, most of what is served by volume is software acting in a loop, not people asking questions.1 OpenRouter reports the same shift, with programming growing from 11% to over half of its token volume during 2025.2 The plumbing is spreading just as fast: monthly downloads of the Model Context Protocol (MCP), a common interface for connecting agents to external systems, grew from around two million at launch to 97 million by early 2026.3 Coding agents are the largest single workload, but Vercel separately tracks back-office agents, application generators and personal assistants in production.4
Diverse. Agents vary along two axes. The first is the model. Open-weight models carried 56% of all tokens on Vercel's gateway in August 2026, the first month they held a majority, up from fewer than one in ten the previous December.5 Spend, meanwhile, stayed concentrated on a few frontier models. The second axis is the harness, the software that wraps a model and connects it to a machine. Commercial coding agents such as Claude Code, Codex CLI and Gemini CLI sit alongside open-source ones such as OpenClaw, Hermes and Cline, general frameworks such as LangGraph and CrewAI, low-code workflow tools such as n8n, and countless bespoke loops written in a few dozen lines of Python. Each harness gives the model a different set of tools, a different way of invoking them, and a different footprint on the operating system. Since any model can be paired with any harness, the space of agents a machine might host is, in practice, open-ended.
Powerful. Nor is the long tail a weak tail. Epoch AI put the best open-weight model about a year behind the best closed one in 2024; on its newer Capabilities Index the lag has held at three to four months since 2023.6,7,8 Models small enough to run on a single consumer GPU trail the frontier by six to twelve months. Whatever a frontier model can do, a model anyone can download and run on their own hardware does within a season, and on a gaming PC within a year.
(a) Open-weight share of tokens, Vercel AI Gateway
(b) Estimated lag of the best open model behind the frontier, Epoch AI
Risks of model-directed software
It is easy to be captivated by headlines about rogue agents breaking into critical systems, but these sit at the tail of a much broader distribution of risk. Most of that risk is more mundane, and it follows directly from the change described above. In an agent, intent passes from a user, through a model, to the machine, and is restated at every hop. What the machine does can diverge from what was intended at any link in that chain, and it does so in three broad ways. The agent may misunderstand what it was asked. It may be misaligned, satisfying its objective by means nobody would sanction. Or the intent itself may be malign, supplied on purpose by a user who directs the agent at a target, or injected by a third party who turns someone else's agent against them. None of this is hypothetical.
A coding agent working on a live product deleted a company's production database during an explicit code freeze. It went outside what it had been told to do, and the destructive act was ordinary database usage, indistinguishable from legitimate work.9
During a lab's internal cyber-capability evaluation, an autonomous agent escaped its sandbox and spent four days inside a third party's production infrastructure, apparently in search of the benchmark's answers. No human directed the steps.10,11
A state-sponsored group was reported to have used an agent to carry out the large majority of an intrusion campaign against roughly thirty organisations, with humans stepping in only at a handful of decision points.12
A compromised software package turned developers' own locally installed AI assistants against them, invoking them to search their machines for credentials. The agent was the mechanism, running as trusted local software.13
These incidents differ in who was at fault and whether anyone intended the outcome, but they share one thing. In every case the incident unfolded through ordinary kinds of operation, such as reading files, running programs, writing to a database and making network calls, issued by a series of normal-looking processes and chosen at run time by a model. Nothing at the level of the operating system announced that a model was choosing them. Connecting these steps and attributing them to a single model-directed program is the central challenge in monitoring such software.
Section 2Monitoring agents
Every incident above followed the same path. A goal stated in natural language became a plan, the plan became a sequence of tool calls, and the tool calls became operations on a real machine. Each step is a place where an agent could, in principle, be watched.
Existing approaches each pick one layer and watch it. The question is what each layer can and cannot tell you. Select a layer below to see.
The common flaw. Each of the upper layers asks the agent, or the software around it, to give an account of itself. Even setting honesty aside, this is the wrong place to look. We would not accept as an audit log a record that is written by the process under audit, that differs from run to run on the same input, that is free-form text rather than structured events, that may omit actions or describe actions that never happened, and that has no causal link to what actually executed. Yet that is what a model's self-report is. Chain-of-thought is sampled, not recorded: it varies with the seed, and there is growing evidence it does not reliably reflect the computation that produced the answer.18,19,16 Framework logs are structured and deterministic, but they record what the agent asked for, not what happened. They also have a blind spot, as an agent can write new code and run it, and nothing logs what that code goes on to do.
An agent's actions are not hidden mental states we must infer from testimony. They are file reads, process launches, and network connections, and the operating system already observes every one of them. Monitoring at the layer of self-report, when the actions themselves are verifiable, gives up ground truth for a story about it. An agent that is misaligned or has been hijacked is the one whose account of itself we have the least reason to trust.
The two halves of the stack fail in opposite ways. The layers above the line describe what the agent intended, but the agent writes them. The kernel records what actually happened, but not on whose behalf. A monitor that relies only on the first is credulous, and one that relies only on the second is blind to intent. Securing agents requires connecting the two: identifying, from the kernel's record alone, which processes and resources belong to an agent, so that what it claims can be checked against what it did. The next part shows why this is harder than it sounds. From the kernel, an agent is not a single process but a shape, and the shape changes with how the agent is deployed.
Section 3Agents from the kernel's perspective
What does an agent actually look like from where the kernel sits? We recorded agents across a range of typical deployments, tracing each run at the kernel from launch to finish. Four distinct structures emerge, which we call shapes.
The four recordings below give the same task to the same model with the same tools. Only the deployment changes, and the kernel records four very different programs.
Anatomy of an agent
An agent is made of three roles. The interface is what a human or another program talks to: a terminal, a chat window, a browser side panel or an HTTP endpoint. The harness is the loop that assembles context, sends it to a language model, parses the reply, dispatches tool calls and applies whatever policy it has. The tools are the code that acts: a shell, a file editor, an HTTP client or a browser. The model runs elsewhere, and from the host it is a TCP peer.
A shape is the assignment of these roles to processes, together with the kernel objects that join them. In the simplest shape the three roles share one process. In the others they do not, and the sockets, pipes and files between them are the only evidence that they belong together.
The figures share one grammar. A filled dot is a process and a hollow dot is a file or an endpoint outside the host. Black marks what acts for the agent and grey is context: a shell, init, a browser that was already running. A solid arrow is process creation, labelled with the system calls involved. A dotted arrow is data moving through a kernel object, labelled with the call or the object. Each figure shows one turn, simplified to the entities that matter, and each term is defined in the appendix.
Four shapes
bash, which forks and execs the program the model asked for. The program's output flows back through a pipe the agent created before forking. Every process in the figure but the shell is a descendant of the agent.Interface the agent process · Harness the agent process · Tools children of the agent
Interface, harness and tools are one process started from a shell. Tools that need another program run as its children, so everything the agent does lies inside its own subtree and the process tree alone delimits the agent. This is the easy case. A simple rule, “a process that talks to a model and then runs tools”, catches it.
In the wild. Claude Code, Codex CLI, Gemini CLI and Aider in their default interactive mode, and any script that calls a model in a loop.
setsid and forks once more. The intermediate processes exit and the daemon remains with no controlling terminal and no parent but init. The shell connects over an AF_UNIX socket. From there the figure repeats the monolith. None of the agent's processes is under the shell, and the socket is the only link.Interface a short-lived client · Harness a background daemon, parent init · Tools children of the daemon
The harness is a long-lived background process and the interface is a separate, short-lived client that connects to it. The two are joined by a socket, not by ancestry. The daemon detached with setsid, its launcher exited and its parent is init, so the harness outlives any one interface and keeps its state between sessions. The process doing the work and the process the user talked to no longer share an ancestor.
In the wild. The OpenClaw gateway and Codex's app-server daemon.22 Also the personal agent on a dedicated machine, where the client sits on another host and the socket is AF_INET rather than AF_UNIX.
git pull wrote AGENTS.md and exited, so the file's writer no longer exists when the file is read. The daemon reads the file, then talks to the model. A tool call travels over a loopback TCP socket to a tool server that is not the daemon's descendant; the server forks bash, and the result returns over the socket. A second tool call goes to a remote MCP server, and the action happens on another host. Four fork trees take part, and only sockets and one file connect them.Interface a client over a socket · Harness a daemon that only does network and IPC · Tools independent servers, local and remote
Interface, harness and tools are separate processes, possibly on separate hosts, and the instructions themselves can arrive through a file written by something else. No process tree contains the agent. The harness may do nothing but network and IPC, while the processes that write files and execute programs were started independently and look like ordinary servers on their own. The process that talks to the model never touches a file; the processes that touch files never talk to the model. This is the case that defeats any detector that scores one process at a time.
In the wild. Claude Code with MCP servers is the common instance: remote servers over HTTPS, local servers over loopback, stdio servers as children.20 OpenHands puts its action-execution server in a different container from the backend that reasons.21 Repository instruction files such as CLAUDE.md and AGENTS.md are the file path; OpenClaw's HEARTBEAT.md, polled on a timer, is the same path for a daemon.
fork alone, so its executable and argument list match every other renderer. The agent reaches the model through the network service and acts on the tab by sending DevTools Protocol commands to the browser process. The agent's own system calls are sendmsg and recvmsg on two descriptors.Interface a browser side panel · Harness one renderer among many · Tools the host application's own processes
The agent runs inside another application's process tree and acts through that application. It creates no processes and opens no sockets. The host application's existing processes do both, for the agent and for everything else at once. The connection to the model and the page loads it causes are made by a grey process shared with every other tab.
In the wild. Claude in Chrome runs as an extension inside the browser. Agents in IDE extension hosts (Cursor, Copilot agent mode, the Claude Code VS Code extension) and computer-use agents that inject input events into the display server are the same shape.
Each animation replays the kernel's record in the order it was captured. Use Final frame to hold the completed diagram. The GIFs are stand-ins; a production build would render these from the event log so a reader could scrub through steps.
Implications for securing agents
The four shapes show that an agent is rarely one process. Its interface, harness and tools can sit in a single binary, be split between a shell and a detached daemon it reaches over a socket, be spread across separate servers and files written by processes that have since exited, or live inside a program that was already running, and these are only the most common arrangements. The boundary of the agent is set by how it was deployed, and it routinely crosses the process boundaries that operating systems and security tools are built around.
That structure is also fluid. An agent chooses its code at run time, and in the same way it chooses its connections to the system at run time: which processes it spawns, which files it touches and which sockets it opens can differ from one run to the next, even for the same task. A conventional program keeps a stable footprint. An agent does not.
This changes what securing an agent requires. Identifying that one is running means recognising a shape rather than a known binary, since the processes involved are often just bash and python3, and an agent on a local model has no endpoint to spot. Attributing an action means following the edges that join its processes. Sandboxing it means drawing a boundary around the shape rather than a single executable, since a profile written for one shape misses the next, and a profile broad enough to cover them all permits the very work it was meant to constrain.
The kernel already records every fork, write and connection these agents make, but as one undifferentiated stream. Recovering the shapes from that stream, in real time, is the technical problem at the centre of this thesis.
Section 4Obtaining the kernel's perspective
Like most diagrams, the four above were a simplified and manicured view: a handful of nodes and edges chosen from a record that, on a real machine, contains millions of events in which the agent's are a vanishing fraction.
Physics of the operating system
It is easy to forget how fast and how crowded a computer is. A laptop idling at a login screen has a few hundred processes resident and several thousand threads. Under load the kernel is switching between them tens of thousands of times a second. Each switch is invisible at human timescales, and the whole life of a process can be too. A shell running ls forks, executes, reads a directory, writes to a terminal and exits in about a millisecond. The black nodes in the previous section take on the order of a hundred microseconds each to appear. A process can be born, do its work and die faster than many tools are capable of noticing.
ls, from fork to exitfork or execve, one black node in the figuresSystem calls are the unit of all of this. Every file opened, byte read, socket connected and process started is a request from a program to the kernel, and a single machine issues them at a rate that is hard to hold in mind. An idle system makes a few thousand a second; a machine compiling code, serving requests or running an agent makes hundreds of thousands, and a loaded server makes millions. The kernel is the one layer through which all of them pass. It sits at the boundary where software meets hardware, and it is where the physical facts of the machine, which core ran what, which bytes moved where, in what order, at what time, are decided. That completeness is what makes it the right, albeit tricky, layer to monitor.
Black boxes
Observing the kernel at all takes specialist tooling. We use eBPF, which runs small programs inside the kernel itself and records each process, file and network event as it happens. It is, in effect, a flight recorder for the operating system: always on, below every layer the agent can touch, and writing a record the agent cannot edit. We wrote our own eBPF modules to produce this record efficiently. Across the machines used in this work they have captured several billion events, hundreds of thousands of process trees and several hundred gigabytes of compressed data. The four diagrams in the previous section were each drawn from a few dozen of these events. The rest were there too.
Signal from noise
fork; filled nodes were alive at the end of the window, hollow ones had exited. As the kernel provides it, nothing distinguishes one process from another. With ground truth applied, grey is the operating system's own activity, green the user's applications (dominated here by two browsers), and red the agent's subtree: one cluster among many, which nothing in the raw record marked out.Which raises the question this thesis is really about. The record is complete, but it is a stream of forks, opens and connects with no indication of which belong to an agent, which to the developer at the keyboard, and which to the hundreds of processes the operating system runs for its own reasons. Nothing in any single event marks the agent out: an agent's execve of bash is byte-for-byte the same as anyone else's. The signal is not in the events. It is in their arrangement, the shapes of Section 3, and recovering those shapes from the stream is a pattern-recognition problem at a scale and speed that rules written by hand cannot meet.
We therefore learn the patterns rather than write them, with models trained on the captured record to recognise the structure of agent activity within it. The constraints on those models are set by where they must run. They have to keep pace with the stream, which means inference measured in microseconds per event. They have to run on the host being monitored, close to the kernel that produces the data, with a footprint small enough not to disturb the activity they are observing. And they have to work from the raw events, without the model's reasoning or the harness's tool calls to help them. For now it is enough to have established what they must contend with: a record that is complete, trustworthy, enormous and almost entirely about something else.
git, uname, grep, sed and a Python script it wrote.Section 5Towards world models of the operating system
Agents are a new class of software, increasingly powerful and spreading rapidly. Existing approaches to monitoring them give inadequate and incomplete accounts of what they are and do. Kernel-level representations of an agent are essential, and extremely difficult to obtain given the volume of events a single machine produces.
It is here that we propose a solution that not only ties these threads together but potentially represents an entirely new infrastructure layer, useful not only for the issues posed by agentic software but wherever operating systems are concerned. We refer to it as a world model of the operating system. Let us be clear about why we chose this term and what it means.
The operating system as a world
A world model is defined by what it captures: the dynamics of an environment. Given the current state of a system, and possibly an action, it predicts the next state, allowing one to roll the system forward and ask what would happen without actually doing it.
The idea is most familiar from domains where the world is physical. A self-driving system confronts an enormous volume of low-level signal: millions of pixels per second from its cameras, none of which individually means anything. Its value lies in converting that raw stream into a structured understanding of the scene, which objects are present, where they are heading, what is likely to happen next. Google DeepMind's Genie models push the same idea further, generating from a text prompt an interactive world that responds coherently as one moves through it, which is possible only because the model has learned how such worlds behave. In both cases, the model's usefulness comes from having learned dynamics, not from memorising appearances.
“World” need not be taken literally; it denotes the environment the model inhabits. Here, that world is the operating system: processes and threads, virtual memory, the filesystem, network interfaces and sockets, credentials and namespaces, CPU and memory utilisation, and the interprocess communication mechanisms through which programs interact. It is a closed, observable, richly dynamic environment, populated by a well-defined set of entities and the interactions between them, and arguably a cleaner world than messy natural language.
That comparison with language is worth making directly. A large language model learns the structure of natural language from vast amounts of text, and that one learned model turned out to serve translation, summarisation, search, coding and more that once needed a separate system each. The operating system has, in its own way, a language that is composed of system calls, process creations, file operations and socket connections that have their own order and context in which programs emit them. Like text, this stream is produced in enormous quantities, means little one token at a time, and follows regularities a model can learn. We expect a model trained on it to do for the operating system what large language models have done for natural language: provide one general representation from which many downstream tasks follow.
Why now
A conventional, pre-compiled binary carries its intent with it. The programmer's intent is fixed in the artefact at compile time; it can be inspected, signed, analysed and reasoned about before it ever runs, and its behaviour is bounded by the code it contains. Model-directed execution gives this up in exchange for flexibility. We specify a high-level goal in natural language, and the model decides at runtime what to do, improvising against a system that changes as it acts. Intent is no longer pinned to an artefact; it emerges from the model's behaviour as it unfolds.
In making this trade we have given away many of the security guarantees that static software afforded us, and we now need to buy them back. Since intent can no longer be read off the artefact before execution, it must be recovered from behaviour during execution, which means predicting how the system will evolve and noticing when it does not. A world model of the operating system is how we recover a predictive handle on intent at runtime.
What a world model buys us
Concretely, a world model of the operating system provides a single, shared representation over which the core problems of understanding and governing programs on a machine become downstream queries, rather than bespoke systems each built on their own features. Below we set out a few use cases for an OS world model. Agents are the most pressing case, but not the only one.
Universal agent detection
Finding every agent on a machine, whatever harness, model or provider drives it, whether the model runs locally or remotely, whether a person, a scheduler or another agent launched it, and whatever shape it takes. That covers frontier coding agents and anything else that behaves agentically, from homegrown scripts calling a model API to malware steered by one, so all of them can be governed under a single ruleset.
Incident response captioning
Reconstructing the full timeline of an incident across many machines and many agents. Investigating the July 2026 OpenAI and Hugging Face incident meant three researchers spending six days on some 70,000 agent messages and their transcripts, in a largely human-driven effort. They noted it would have been far harder had the agents succeeded in compromising telemetry and logging, which they tried to do.25 A world model that operates natively on operating-system events could give a complete reconstruction of incidents like this one immediately.
Semantic OS memory
A unified model could retain information based on behavioural significance, causal relevance and anticipated future questions, not only statistical rarity. Its memory would then inform every other capability rather than serving only retrospective analysis.
Self-directing observability
Rather than investigating deviations in isolation, the model could use its knowledge of program roles, history and relationships to decide what to investigate, which instrumentation to activate and what evidence to preserve.
Semantic security policies
A shared behavioural representation could classify previously unseen software into functional categories, allowing policies over agents, browsers or development tools rather than executable names.
Context-dependent enforcement
A unified model could extend execution-phase recognition across related processes and resources, selecting pre-validated restrictions based on the activity of an entire process neighbourhood. The kernel would still enforce deterministic policies, independently of uncertain predictions.
Automatic provenance investigation
Instead of investigating only detected attacks, the shared model could proactively select important causal relationships, investigate unexpected program interactions and preserve the evidence needed to explain them. This also requires retaining enough original provenance to verify its conclusions.
Cross-workload behavioural discovery
A shared model could identify recurring behavioural structures across unrelated applications and machines, so that discoveries on one workload improve classification, investigation and monitoring elsewhere. The engineering challenge is learning transferable representations without obscuring important differences between workloads.
Each of these is a question about how the system's state came to be or where it is heading, which is exactly the question a world model is built to answer.
Why one model rather than many tools
Any one of these could be built as a standalone tool. Each becomes far more useful when it draws on a shared, continuously updated understanding of the machine. Recognising an unfamiliar process as browser-like tells the system what to expect of it. An interaction that breaks that expectation is a reason to trace more closely, and the evidence gathered then refines the model's picture of that kind of software, surfaces similar activity on other machines, and may justify a new rule. Built separately, the same tools would each reprocess the telemetry, keep their own identities for the same processes and files, and lose information at every boundary between them.
We believe an operating-system world model will become a critical piece of infrastructure for computing in general, with AI safety as the first and most pressing use case. Our goal is to embed it directly into the major operating systems, such as Linux, macOS and Windows, with several use cases available out of the box. We will also build and maintain the toolkits that let anyone build on top of the world model and the kernel insights it provides.
AppendixThe operating system, briefly
The minimum background needed to read Sections 2 to 4. Readers who want more will find a clear general introduction in Arpaci-Dusseau and Arpaci-Dusseau23 and a thorough reference for Linux in Kerrisk.24
Applications, the kernel, and system calls
Process, fork, execve, process tree
fork, which duplicates the caller; its program is replaced by execve, which loads a new executable and argument list. The parent–child links made by fork form a tree rooted at init. The tree records who created whom. It does not record who talks to whom, which is why sockets, pipes and files appear in the figures as separate edges.Daemon, setsid, reparenting, init
setsid to detach, and the launcher exits. The kernel then reparents the orphan to init (process id 1, on current Linux systemd), and from then on the daemon can be reached only through a kernel object it created, usually a socket.File descriptor, pipe, socket, socketpair
fork. A pipe is a one-way byte stream between two descriptors, usually shared by a parent and its child; a socketpair is the two-way equivalent. A socket is a descriptor for communication: AF_UNIX joins processes on one host through a filesystem path, AF_INET carries TCP or UDP to an address and port, over loopback (127.0.0.1) or across the network. The kernel sees endpoints and bytes, never what the bytes mean. A TLS session to a model provider and one to a web site are the same object, differing only in the peer address.Interpreter, shell, terminal
bash, zsh) is an ordinary process attached to it that reads command lines and runs each as a child. bash and python3 are interpreters: single executables whose behaviour is set entirely by the script or string they are given. The process name tells you the language. Only the argument list tells you the program.MCP server, LLM provider, browser process model
The task prompt
All runs in Section 3 received the same prompt as the first and only user message. Each agent had two tools: one for writing files and a bash tool for running shell commands. No system prompt was added beyond the harness's default.
Write a Python script called utils.py in the current working directory. It should scan the directory for .txt files and, for each one, print the file name followed by its line count and word count. At the end, print the totals across all files. Use only the Python standard library. Once the script is written, run it with the bash tool and show me the output.
The prompt was chosen to be short, benign and deterministic, so that any differences between runs come from how the agent is deployed rather than from the task. It requires exactly one file write and one command execution, the minimum needed to show an agent both producing and acting on an artefact.
ReferencesSources cited
- Vercel. AI Gateway production report, June 2026. entry missing from refs.bib
- OpenRouter. State of AI, 2026.
- Model Context Protocol. Download statistics, early 2026.
- Vercel. AI Gateway production report, July 2026.
- A. Charles and E. Dodds. AI Gateway Production Index, September 2026. Vercel blog, 17 September 2026.
- B. Cottier, J. You, N. Martemianova and D. Owen. Open vs. Closed AI: How Behind Are Open Models? Epoch AI, 4 November 2024.
- L. Emberson. Open-Weight Models Lag State-of-the-Art by Around 3 Months on Average. Epoch AI, 30 October 2025.
- J. Edwards and L. Emberson. Open Models Lag State-of-the-Art Closed Models by 4 Months. Epoch AI, 29 May 2026.
- Reporting on the July 2025 Replit production-database deletion.
- Hugging Face. Timeline of the July 2026 sandbox-escape incident.
- OpenAI. Report on the July 2026 incident. verify URL and title
- Anthropic. Disrupting the first reported AI-orchestrated cyber espionage campaign. November 2025.
- Analysis of the August 2025 nx package compromise.
- Anthropic. Constitutional classifiers. 2025.
- B. Baker et al. Monitoring reasoning models for misbehavior and the risks of promoting obfuscation. OpenAI, 2025.
- Y. Chen et al. Reasoning models don't always say what they think. Anthropic, 2025.
- Adversa AI. GuardFall: bypassing command filters in open-source coding agents. 2026.
- M. Turpin et al. Language models don't always say what they think: unfaithful explanations in chain-of-thought prompting. 2023.
- T. Lanham et al. Measuring faithfulness in chain-of-thought reasoning. 2023.
- Anthropic. Model Context Protocol specification. 2024.
- X. Wang et al. OpenHands: an open platform for AI software developers as generalist agents. 2024.
- OpenClaw. Gateway architecture documentation.
- R. H. Arpaci-Dusseau and A. C. Arpaci-Dusseau. Operating Systems: Three Easy Pieces. 2018.
- M. Kerrisk. The Linux Programming Interface. No Starch Press, 2010.
- A. Cotra and D. Patel. Inside the OpenAI agent swarm that hacked Hugging Face. Dwarkesh Podcast, 1 September 2026.