Claude Code Is A State Machine
A small machine that loops through model calls and tool results, and only stops at one of a fixed set of endings.
If you use coding agents for real work, you need the operating model: loops, tools, context, permissions, verification, and failure. This guide gives you that model in 18 essays, with diagrams you can run.
The two-loop state machine from essay 01. Every diagram in the guide works like this one: press a control, watch the mechanism move.
What happens, end to end, when you send one message.
A small machine that loops through model calls and tool results, and only stops at one of a fixed set of endings.
An agent is a model plus a worldview you reinstall on every turn. What goes in that worldview is the real programming, and most of it is not clever, it is careful.
A tool is a contract, not a function. What input is allowed, whether it is safe, who gets to allow it, how the result comes back, and whether it can change what happens next.
Whether a thing can run is answered by rules, modes, automated checks, your terminal, or your phone, racing to a single decision. The box on screen is one racer, not the system.
The model forgets, the window is finite, every token is paid for. The constraints that explain everything next.
The window has a ceiling. The interesting part is the set of valves that keep it from filling: dropping duplicates, deferring detail, rebuilding a working memory.
What you send is a budget. Caching and ordering decide cost and speed, and the order of the prompt is an economic decision in disguise.
A slow agent can still feel fast, and that gap is engineered. Stream so you see work immediately, run independent work at once. Latency is a product decision.
How an agent remembers across sessions without drowning in its own notes. Memory is a discipline.
Given those limits, how a good agent behaves: think before it touches, look before it reads, stay under control, fail cleanly, prove the work.
Exploring is cheap and reversible. Changing things is not. The biggest reliability win is to do most of the work in the cheap half and put a review gate before the expensive one.
An agent's first job in any repo is to stop being lost, cheaply. It goes wide and cheap before deep and expensive, narrowing the search so it reads almost nothing.
An autonomous agent is only safe if you can always take the wheel. Interrupt, redirect, background and resume, with your input landing cleanly, never mid-action.
The model is the easy part. The reliability comes from retries, fallbacks, and knowing when to stop. You judge an agent by its worst answer, not its best.
The most dangerous word an agent can say is done. A good one proves it instead of declaring it, by running the real checks with the change exercised for real.
When one agent is not enough: how it spawns others, which primitive to reach for, and how you extend the whole thing.
A subagent is a job, not a helper. It gets its own tools, permissions, and workspace. The system can isolate it. Only you can scope it.
Tool, skill, command, subagent, or hook? Five ways to add behavior, and a simple way to pick the lightest one instead of reaching for the biggest.
Six layers stack around the core, and a couple of dozen moments in a session where your own code can run. The agent is meant to be added to.
Where the half-built corners point, and the single shape every serious coding agent is converging on.
The half-built corners point one direction: work that outlives the prompt, runs remotely, remembers, plans, and coordinates. They reuse the same parts.
Pull it all together and a single shape appears. It is why every serious coding agent is starting to look like the others, and what that tells you to build.
Every diagram is addressable. Use this as the map once you know which mechanism you want to revisit.
The essays build, but each one earns its slot on its own. If you only have twenty minutes, read the agent loop, then context, then done means verified.