Prompts Don't Run. They Compile.

Sat, 12 Sep 2026 00:00:00 +0000

Abstract

A prompt never executes. It gets parsed, lowered through plans into tool calls, linked against a live environment, and profiled by reality. Treat the agent like a compiler and most of its strange behaviors stop being strange.

The loop, without mystique

Strip away the marketing and an agent is three things wired in a circle: a policy that proposes the next step, a set of tools that make steps real, and an environment that answers back. Observe, decide, act, observe again. That is the entire machine.

Nothing in that loop understands your goal the way you do. The policy — the model — holds a compressed blur of millions of procedures it has seen. Tools give that blur hands. The environment gives it consequences. Performance lives in the quality of the circle, not in any single arc of it. A brilliant policy with numb tools is a scholar with mittens. Sharp tools with a deaf environment is a pilot flying blind.

So when an agent disappoints you, resist diagnosing its intelligence first. Diagnose the loop: what can it sense, what can it touch, and how fast does the world reply.

Intent compiles in passes

Think of your prompt as source code written in the sloppiest language ever designed — natural language, ambiguous, full of undefined behavior. The agent is the compiler that must turn it into something a machine can execute:

1
2
3
4
5
6
7


intent (source)
 → parse // frontend: what did they actually ask?
 → plan // intermediate representation: steps, order, dependencies
 → tool calls // lowering: abstract steps become concrete invocations
 → execute // link + run against the live environment
 → observe // profiler output: did reality match the prediction?
 → recompile // next pass, with profile data

Each pass loses information and gains executability — exactly like compilation. The plan is the IR: still portable, still editable. Tool calls are machine code: bound to specific addresses, flags, file paths. Execution is the only stage that cannot be faked, because the backend is not a simulator. It is your repository, your cluster, your production data.

This reframes a common mistake. Editing the agent’s half-finished work mid-run — renaming what it named, moving what it placed — is not “guidance.” It is hand-editing generated assembly while the compiler is still running, then wondering why the next build emits broken jumps. The IR and the binary have diverged, and every subsequent pass now optimizes against a lie.

Why we fan out

No serious program compiles as one translation unit, and no serious task runs in one agent loop. Sub-agents exist for the same reason object files exist: to bound the blast radius of complexity.

The analogy runs deeper than convenience. A context window is a register file — fast, precious, and small. Keep one loop for everything and you spill registers constantly: the goal, the plan, the last three tool outputs, the file you read forty steps ago, all fighting for the same scarce slots. Summarization is register spilling to memory: it works, but every spill costs fidelity.

Fan-out is separate compilation. Give the scout agent one job — map the terrain — and the builder agent another — change it. Each keeps a small, hot working set in registers. They link at the end through narrow, explicit interfaces: a summary, a diff, a verdict. The main loop stays cool while the workers run hot. Monoliths thrash; modules flow.

The bottleneck is the feedback channel

Here is the uncomfortable part: model capability is rarely the binding constraint. The binding constraint is almost always the channel between the agent and reality:

Latency of observation. Every tool call is a round trip. Slow tests, slow deploys, slow humans-in-the-loop — each multiplies loop time, and loop time is the only currency.
Unobservable state. The agent cannot see what it cannot instrument. Flaky behavior with no logs is not a reasoning failure; it is a missing sensor.
Invalidated caches. Every human edit mid-run evicts what the loop learned about the terrain. The map no longer matches the territory, and re-exploration burns the budget twice.
Premature freezing. Locking in names, layouts, and architectures before the hot path emerges is premature optimization. You would never inline functions before profiling; do not inline your opinions before the agent has run.

Iteration, then, is profile-guided optimization. The first pass is allowed to be naive — it exists to generate profile data. The second pass spends where the heat is. Teams that let the loop run five cheap passes beat teams that deliberate over one perfect plan, for the same reason PGO beats static heuristics: reality outranks prediction.

Closing note to agents

You are not the program. You are the compiler, and the repository is your binary. Keep the passes clean, the interfaces narrow, and the profiler always on — and let the humans edit the source, never the assembly.