Your AI Coding Agent Has No Hands

Last post I told you the agent runs a loop, and that reading is what costs money. True, useful, and enough to cut your bill.

But it left a question sitting there: okay, but how does the AI actually run a command on my laptop? Does it have access to your machine? Is it logging in somehow? And what is "MCP", which everyone describes as "USB-C for AI" and then never explains?

The answer is much dumber than you'd expect. And that dumbness is exactly why you can control it.

Same rule as Part 1: no prior knowledge needed.

The fact that makes everything click: the model can't do anything

The AI model cannot run a search. It cannot open a file. It cannot execute a test. It has no access to your computer at all.

It can do exactly one thing: read text, and write text back. That's the whole capability. A brain in a jar.

So how does Claude Code edit your files? Because there are two separate things, and almost everyone thinks they're one thing:

• The model — the brain. Lives on a server somewhere. Reads text, writes text. Brilliant, and completely stuck in the jar.

• The harness — the app on your machine (Claude Code, Cursor, Codex, Gemini CLI). The hands. It can read files, run commands, hit the network.

The model never touches your computer. It writes a note that says "please run this search for me" — and the harness reads that note, does the work itself, and pastes the result back for the brain to read.

That's it. That's the entire trick. Everything else in this post is a variation on it.

What that note actually looks like

This is the part nobody shows you, and honestly it's the part that killed the magic for me.

When the model wants to search your code, here's what it literally emits:

{
  "type": "tool_use",
  "name": "run_command",
  "input": { "command": "grep -rn \"login\" src/" }
}

That's not a metaphor. That's the actual output. Text.

The harness sees it, runs grep on your machine — your CPU, your electricity, free — and sends back:

{
  "type": "tool_result",
  "content": "src/auth/login.ts:42\nsrc/auth/session.ts:18\nsrc/api/routes.ts:91\n..."
}

And now that result is text the model has to read. Which is billed.

Look at those two blocks again, because the whole cost model of Part 1 is sitting right there. The grep was free. The results being pasted back in were not. Every "free vs. billed" line I drew in the last post is just this exchange, over and over.

Tool calling: the menu

So how does the model know run_command even exists?

Because on the very first message, before you've said a word, the harness sends the model a menu: here are the tools you're allowed to ask for — search, read_file, run_command, edit_file — and here's the exact format for asking.

The full round trip looks like this:

Fig : Tool-calling sequence

Three things worth staring at:

1. The model only ever asks. It never acts. The harness is the only thing that touches anything.

2. It doesn't know what's next. It picks the next tool only after seeing the last result. There's no script. It's improvising, one step at a time, like someone feeling their way through a dark room.

3. That improvising, in a loop, is the entire definition of "agent." A chatbot answers once. An agent acts, looks at what happened, and decides again.

The permission gate (or: why it keeps asking you)

Here's a piece Part 1 never touched, and you hit it fifty times a day.

Between the model's note and your actual filesystem, the harness sits as a bouncer. When the model asks to run something, the harness checks it against your rules:

• On the allow-list → runs silently.

• Not on the list → it stops and asks you.

This is why ls and npm test go through without a peep, but the first time it wants to rm something or push to a branch, you get a prompt.

Which means the "always allow" button is a real decision, not an annoyance. The model is improvising, remember — it's not malicious, but it is guessing. And the guess arrives as a shell command that your machine will execute.

What to do: allow-list the read-only stuff you approve twenty times a day (ls, cat, grep, git status, your test command). Keep the gate closed on anything that deletes, force-pushes, installs, or talks to the internet. Blanket "yes to everything" in a repo you care about is how people end up with a very educational afternoon.

MCP: one plug for every tool

The built-in menu covers your code — search, read, edit. But you usually want more: query the database, open a GitHub issue, check Slack, hit an internal API.

The old way was miserable. Every tool had to be hand-wired into every agent, separately. Ten tools, four agents, forty integrations.

MCP — the Model Context Protocol — is the fix. A tool provider ships one small MCP server, and any agent that speaks MCP can plug into it. Build once, works everywhere. Hence the "USB-C for AI" line everyone repeats.

Fig : MCP as a universal plug

When you connect one, its tools just appear on the menu. To the model, a GitHub tool and the built-in file reader look identical — both are just things it's allowed to ask for.

The menu tax (new saving, not in Part 1)

Now here's the part that costs you money quietly.

That menu is re-sent to the model on every single step. Not once per session — every step. And every connected MCP server adds its tool descriptions to it.

A chatty server can easily add a thousand-plus tokens of tool descriptions. Connect six of them "just in case," run a forty-step task, and you've paid for that menu forty times over — for tools the agent never once used.

What to do: open your MCP config and actually look at it. If you connected something three weeks ago for one experiment, disconnect it. Most people have never once audited this list, and it's riding along in every request they make.

And one caution nobody puts in the tutorials

An MCP server is third-party code running on your machine, with the access you gave it.

There's a second, subtler thing too: the tool descriptions in that menu are text the model reads and trusts. A malicious or sloppy server can put instructions in there. The model has no way to tell "this is a tool description" from "this is a command from my user."

Treat installing an MCP server like installing a VS Code extension that can read your repo and your database. Sometimes that's completely fine. Just make it a decision instead of a reflex.

Planning: the cheapest text you'll ever buy

Left alone, an agent starts doing immediately. For a small fix, perfect.

For a big task, that's how you pay full price for the wrong approach, and then pay again to undo it.

So agents can plan first — write out the approach, which files, what order, what's risky — and wait for your nod before touching anything.

Fig : Plan-then-build

A plan is a paragraph. A wrong implementation is a paragraph plus all the reading, writing, testing and undoing around it. Catching a bad idea while it's still a paragraph is the cheapest thirty seconds you will ever spend on a task.

The desk, and why it gets re-sent

One mechanism from Part 1 deserves its actual explanation, because the reason is stranger than the symptom.

The model is stateless. It remembers nothing between calls. Nothing.

Every time the harness comes back with "okay, what next?", it's talking to a model with total amnesia. So it has to resend the entire conversation so far — the task, every file read, every tool result, every bit of the model's own earlier thinking — just to get it back up to speed.

That pile is the context window. Think of it as a desk with a fixed size, and it already has things on it before you type anything:

• the system instructions

• the tool menu (including every MCP server you connected)

• then your messages, every file read, every tool result

Two consequences fall straight out of "the desk is fixed and gets resent":

Everything you put on it, you keep paying a small toll on. (Providers discount resent history with caching — that's the only reason long sessions are survivable. Discounted isn't free.)

When it fills, the harness compacts it. The agent summarizes its own older history to make room, detail gets squeezed out, and if it needs that detail later it re-reads the source. That's the double-payment from Part 1 — now you know it's not a billing quirk, it's the harness doing housekeeping because the desk ran out of room.

Sub-agents: the trick that gets you a second desk

This one is in almost every modern agent and it barely gets mentioned.

The harness can spawn a sub-agent: a fresh model instance, with its own clean, empty desk, given one narrow job. It goes off, burns through twenty files, and hands back a single paragraph of findings.

The twenty files never touch your main desk. Only the paragraph does.

Fig : Sub-agent with its own context

This is exactly the fix for the messiest part of any real task: exploration. Searching a codebase generates enormous, mostly-useless text, and in a single-desk setup all of it sticks around for the rest of your session as dead weight.

What to do: when a task starts with a big hunt, say so out loud — "use a sub-agent to find every place we validate uploads, then come back with just the file list and line numbers." You pay for the hunt once, in a context you then throw away, instead of carrying it for the next hour.

Retries: the loop that eats your budget

Last piece, and it's the messy one. Tools fail. Tests error. Commands have typos. Files aren't where the model guessed.

When that happens, the harness sends the error text back up, and the model does the sensible thing — reads it and tries again.

Fig : The retry loop Self-correction is the best thing about agents. It's how they fix their own mistakes while you're getting coffee.

But watch the trap: every trip around that loop is more reading and more thinking, all billed. A stubborn error the model can't crack will cheerfully burn through five variations of the same broken idea, each one costing you the full read-and-think.

The good news is you can end it instantly, and you don't need to be an expert to spot it. The tell is repetition — same file, same fix, slightly reworded. When you see it: stop it, paste the actual error, and name the cause if you know it. You've just turned an expensive spiral into one cheap, aimed step.

The whole machine, in six lines

1. You give a task. The harness sends it to the model with a menu of tools — built-in ones plus every MCP server you've connected.

2. For anything big, the model plans first and waits for you.

3. Then the loop: the model asks, the harness runs it on your machine for free, and the result is read back in (not free). The permission gate stops it for anything risky.

4. Everything read piles onto a fixed desk, which gets resent every step because the model is stateless — and compacted when it's full.

5. Big exploration can be handed to a sub-agent with its own desk, so only the summary comes back.

6. When something breaks it reads the error and retries — brilliant, and billed every lap.

No magic anywhere. A brain in a jar, a pair of hands, a menu, a desk that keeps filling up, and a bouncer at the door.