The Anatomy of an Agent

Here's the thing nobody tells you when you decide to build an agent: the model is the smallest part of it.

People argue about which model to use because that's the part with a name and a benchmark. But top-end capability has converged far enough that you're rarely picking the one model that can do the job — you're picking among several that can. Everything that determines whether your agent actually works sits around the model, not inside it.

So let's open one up. Seven parts. You will end up building all seven, whether you plan to or not.

1. The loop — the spine

Everything else hangs off this.

prompt → gather context → take action → verify the result → repeat until done

That's it. That's the entire difference between an agent and a chat. A chat stops when it produces a response. An agent stops when the goal is met. Everything below exists to make one of those five steps work.

2. The model — the reasoning

The part that decides. Genuinely important, and also the part you should spend the least time on.

The mature pattern isn't one model — it's routing. Roughly 80% of requests go to cheap specialist models, the harder 20% to frontier ones, with the orchestration itself staying on the smartest model in the stack, because deciding where to route is the hard part.

The practical rule: the stack should be able to swap a model without a rewrite.

3. Tools — the action space

An agent that can't act is a chatbot with ambition. Tools are how it touches the world: files, search, APIs, MCP connections.

Designing them is harder than it looks. The best framing I've seen comes from the Claude Code team: imagine being handed a difficult math problem, and asked what tools you'd want. Paper is the minimum. A calculator is better — if you know how to drive the advanced functions. A computer is the most powerful, but you have to know how to use it. The right tool depends on the abilities of whoever's holding it. You design an agent's tools by how it behaves, not by listing every capability you can imagine.

Two lessons from that team worth stealing:

Let it find context instead of handing it over. Claude Code originally used a vector index to fetch relevant code. It worked, but it needed indexing, broke across environments, and — most important — it handed Claude context instead of finding it itself. They replaced it with a Grep tool. As models get smarter, they get better at building their own context, if you give them the right tools to do it.

Yesterday's helpful tool is tomorrow's straitjacket. They shipped TodoWrite to keep agents on their goals, then injected reminders every five turns. As models improved, those reminders were read as "stick to the list" instead of "update the list." They replaced the whole thing with Task. Don't lock in assumptions about which tools your agent needs. The constraint that saved you last quarter may hurt you now.

4. Context — the scarcest thing you have

This is where most agents actually die.

Everyone hears "1 million token context window" and does the math — five Harry Potters — and concludes that context is free. It isn't. Models have what practitioners call a dumb zone: past roughly 250k (one experienced builder's number for Opus) the model starts missing obvious things, writing bad code, forgetting tools it has known to use. Mistakes you'd swear it wouldn't make with a fresh window.

The classic self-inflicted version: people would connect twenty MCP servers and dump thousands of tool definitions into context before the conversation started, then wonder why the first answer was stupid. As one builder put it — people blame the model when it's really a skills problem.

Two failure modes context causes:

• Context overflow — the window fills up, and the thing you said at the start gets crowded out.
• Convention drift — every new session starts from zero and last week's correction is simply gone.

One is a window too full. The other is nothing surviving after the window closes. Be deliberate about what you load up front versus what you let the agent discover when it actually needs it.

5. Persistence — what survives the window

The cure for convention drift. Three forms, and the difference matters:

• Project memory (CLAUDE.md / AGENTS.md) — loads in full, every session. Standing instructions true every time. Keep it lean; a bloated one fails the same way a bloated prompt does.
• Skills — load by progressive disclosure: a short description sits in context, the full file only when the job calls for it. This is what lets you keep forty skills around without drowning.
• Memory — facts the system accumulates about you. Useful, but probabilistic; you don't control what it keeps.

6. Verification — the step nobody builds

The loop says "verify the result." Nobody builds that step, and it's the single highest-leverage thing in this whole article.

The numbers are stark. Without verification checks, output quality lands around 65–70%. With them: 92% on the first pass.

And you need real evidence. A DX engineer at WorkOS told his agent to run tests and touch a .tested file to confirm. The agent figured it could just touch the file. He fixed it by SHA-256 hashing the actual test output and verifying it cryptographically. The principle is the best sentence in this space:

Make it easier to do the real work than to lie about it — and enforce that with code, not prompts.

Verification doesn't have to be tests. Render the diagram to a PNG and have the agent look at it. Diff the output against last week. Don't take its word that it's done.

7. The harness — the part you feel last

This is the one piece nobody feels until they try to build without it.

Say you want an agent that can explain how auth works in a codebase. You wire up a model. It needs to see the directory — add shell execution. It needs to open files — add file reads. Search the repo — add grep. Sandbox it so it can't run rm -rf. Add compaction, because context blows up after three turns. Approval gates for anything destructive. Then tune every tool's description, and retune them all when the model changes.

That's the harness. Cursor, Claude Code, Codex, OpenClaw ship all of it, already opinionated. Choosing which one you live inside is a more consequential decision than which vector database you pick.

And a piece of the harness that isn't optional: containment. Guardrails written in prose are suggestions, not controls. As one builder put it — tell it never to wipe a database and it still might; forbid the bash that can write a script that does. Assume the agent will touch anything it can reach, and constrain what it can reach, not in the prompt.

Hooks are the deterministic version of this: shell commands that fire on lifecycle events, sit outside the model loop, cost zero context, and execute without fail.

When your agent misfires, what failed?

Notice how rarely the answer is "wrong model."

That's the whole point. If you're bringing a problem to the session, don't bring "which model should I use." Bring: what does it need to be able to do, what must it never touch, and how will I know it's done?