The agent stack

10 August 2026 Essay

When an AI agent fails, the model is not always the reason. I only understood this after asking Claude to explain how it actually works — a conversation that produced what we came to call ‘the agent stack’: ten layers — from the raw model, to the loop that makes it an agent, to the memory that survives between sessions. This page is that map. It's changed how I use these tools, mostly because it tells me where to look when something goes sideways.

The stack isn’t a ladder. L1, L0, L2 and L3 make up a single pass — assemble what it can see, think, ask for a tool, run it. L4 is the loop that repeats that pass until the model stops asking, which is the moment it becomes an agent rather than a clever autocomplete — a single reply can be dozens of laps. L5 is the little that survives from one lap to the next, and L6–L9 never run inside the loop — they shape it from outside. Click any box to jump to its layer.

Where it usually goes wrong

Three failures account for most of what goes wrong, and each has an address:

L1 Context — it was never shown the thing you assumed it knew
L5 State & memory — it lost track of something from earlier
L3 Execution — a tool quietly returned nothing, and it carried on anyway

Ask “what could it actually see?” first. Most of the time that's the whole answer — and it points straight at which layer to fix.

What this explains

“Can it do X?” is rarely a question about intelligence. It's almost always about what's connected (L2 Tools) and what hands it has (L3 Execution) — which is why the answer often changes with five minutes of setup rather than a better model.

Recent progress isn't mainly a smarter model. What changed how it feels to use is better handling of what it can see (L1 Context), what it's plugged into (L2 Tools), what it remembers (L5 State & memory) and what it can hand off (L7 Delegation).

What you actually control

Your two biggest levers are L1 Context and L5 State & memory. You can't change the model, but you decide what gets put in front of it and what gets written down for next time.

Nearly all the improvement available to you lives in those two — front-load the context, write things down, and push wide searching out to helpers.

Top to bottom: the bare model first, then one layer at a time.

The layer true of any agent

In Claude in the model's own words

The raw model

Inference

The trained model on its own. Text in, text out. No memory of a minute ago, and no ability to do anything — it can only produce words.

claude-opus-5. It was trained to work inside the control loop above (L4) — knowing when to reach for a tool and when to stop is part of the training, not something added afterwards.

Which is why a model built for conversation behaves badly as an agent even when it's given identical tools.

Real examplePaste in a clumsy paragraph and ask for it tightened. It comes back better, immediately — nothing searched, nothing run, no file touched. That's the model working alone, and for a great deal of everyday writing and thinking it's the whole job. The layers above only start earning their keep when the answer depends on something outside the conversation.

One pass — what happens in a single step

Context assembly

Everything the model is shown before it writes a word: your message, the conversation so far, its instructions, files it read, results from tools. It knows nothing else.

My instructions, our conversation, your project notes, and small reminders the software slips in as we go. Two things shape how this behaves:

Prompt caching. Everything said so far is kept ready to reuse, so it isn't re-read from scratch each turn — but only while the earlier part stays untouched. Carrying on at the end of a conversation is cheap; going back and editing an earlier message throws the saving away.

Deferred tools. About 150 tools are available to me, but only the descriptions of the ones I need get loaded, because those descriptions occupy the same space as your actual work. A session that wanders across five unrelated topics spends most of its room on setup rather than on you.

Real examplePaste in last quarter's report and spend twenty minutes asking questions about it — every answer grounded in the actual document, because it's sitting right there in view. Put your team's conventions in a project instructions file and the same thing happens automatically: every new session opens already knowing them, before you've typed a word.

Tool interface

The menu of things the model is allowed to ask for. Asking is all it does — it writes a request, and something else decides whether to carry it out.

Reading and writing files, running commands, searching. Plus MCP — a shared standard for plugging in outside services, which is how your Gmail, Calendar, Drive, Chrome and the link to your own computer all turn up as things I can use.

Why the standard matters: anyone can build a tool without Anthropic being involved. That's the whole reason the list of things I can connect to keeps growing.

Real exampleWith your calendar, Drive and Gmail connected: “find the pricing doc, check it against what I've got booked with Acme on Thursday, and draft a recap for their team.” Claude searches Drive, reads the file, looks up the meeting, and leaves a draft waiting in Gmail. Three services, one sentence from you — and each of those was an ordinary connection you switched on, not a feature that had to be built for you.

Execution / effectors

The part that actually does it — runs the command, opens the file, makes the call — then reports back what happened. Real-world friction lives here.

A real computer. Claude can create a file, run a shell command, install a package, execute a script, call an API — and, the part that matters most, see what came back: the output, the error message, the contents of the file it just made.

That second half is what makes this layer more than a remote control. Claude meets a wrong file path, a package that won't install or a service that's down the same way you would — reads the complaint, and usually works around it without asking.

Where the hands are matters too: this session works on a machine in Anthropic's cloud plus a granted link into folders on your own computer, and files don't cross between the two by themselves. Same brain, different hands is most of what separates Claude in a terminal from Cowork from Claude in Chrome.

Real example“Here's a messy CSV export — I want a clean spreadsheet with a chart of monthly totals.” Claude writes a script and runs it. It fails: the date column turns out to have two different formats in it. Claude reads the error, fixes the parsing, runs it again, opens the result to confirm the chart actually rendered, and hands you the file. Nobody told it the dates were broken — it found that out by running the thing and reading what came back.

Where it becomes an agent

Control loop the agent is here

Look at everything → decide the next move → do it → look at what came back → decide again. Round and round until the model judges the job done.

The loop ends when I reply to you without asking to use another tool. There's no fixed number of steps — I decide when I'm finished, which is also why I can occasionally stop too early or grind on too long.

When you interrupt me, or a permission prompt appears, you're pausing this loop part-way round.

Real example“This test is failing, can you fix it?” Claude reads the test, runs it, sees the error, edits the code, runs it again, hits a second problem, fixes that too, runs it a third time — green. Then it tells you what was wrong. One sentence from you; six trips round the loop before it came back.

State & memory

Anything that outlives a single step. A conversation has a size limit but a job might not fit inside it, so useful things get written somewhere they'll survive.

Four separate places, with four different lifespans — most people assume there's only one:

What we've said in this conversationdoesn't carry over
Files I create in the session's workspacegone when it ends
Project memory on your computerevery future session
Project docs on claude.aieveryone in the project

So: the default is that things disappear. Anything you'd hate to re-explain needs to land in one of the bottom two.

Real exampleYou mention once that your reports should open with a one-paragraph summary and never use the word “leverage”. Three weeks later, in a session that has never seen that conversation, the draft arrives with the summary already at the top and the word absent — because the preference was written down rather than left in the chat.

Scaling up — for bigger jobs

Planning

Breaking a big job into steps, ticking them off, and rethinking when a step fails. Useful on long jobs, overhead on short ones.

The checklist you sometimes see me build, and plan mode — where I write out what I intend to do and wait for you to approve before touching anything.

So: plan mode is the one to reach for when a mistake would be annoying to undo. For a single contained job it just slows things down — I skipped it for this page.

Real example“Reorganise this folder of 200 files by client and year.” Claude shows you the plan before touching anything: the folders it will create, what moves where, what it will leave alone. You notice one client should stay as-is, say so, and it adjusts — then works through the list ticking items off, so you can see at any point exactly how far it has got.

Delegation

Handing part of the job to a fresh copy of the agent that starts with a clean slate, then keeping only its answer.

I can send off helper agents — one each for different parts of a search — and get back short answers instead of forty files' worth of text.

The reason isn't teamwork, it's tidiness: the helper's mess stays in the helper. My main thread only ever sees the conclusion.

So: on anything broad — “check every file for X” — it's worth asking me to use helpers. It's faster and leaves more room for the actual work.

Real example“Which of these 200 contracts have an auto-renewal clause?” Claude sends out helper agents to read them in parallel and comes back with twelve, each with a page reference — in roughly the time it would have taken to read a dozen itself, and with the main conversation still clear enough to keep working in.

Making it usable for real work

Governance

The rules about what the agent may touch and when it has to ask first. Same abilities, different leash.

The prompts asking you to approve something, plan mode waiting for your sign-off, and the fact that I can only reach the folders you specifically granted — not your whole computer.

Refusals come from two different places: some are trained into the model, some are enforced by the software around it. That's why behaviour can differ between products running the same model.

Real exampleThe first time Claude wants to change a file on your computer, it stops and asks. You approve it, and tell it not to ask again for that folder. From then on routine edits run uninterrupted while anything outside that folder still comes back to you. You end up moving the line as trust builds, rather than choosing between all and nothing on day one.

Adaptation

The agent getting better at your work over time: saved instructions, reusable procedures, preferences it picked up.

Skills — folders of written-down instructions I load only when they're relevant. One of them decided the colours on this page. Also your CLAUDE.md, and memory notes that change how future sessions behave.

The catch worth understanding: using it doesn't train it. No session updates the model — for you or anyone. What improves is the written material around it.

So: if you want next month's session to know something, it has to get written down. There's no other mechanism.

Real exampleWrite your house style into a project instructions file once — tone, structure, the phrases you never want used. Every session afterwards drafts in that voice from the first sentence, with no reminder from you. Hand the same file to a colleague and their Claude writes in your house style too.