How Claude Code Actually Works (It's Just a Loop)

0:00Read

The model never touches your files. The model writes a note, and ordinary code does the rest. You ask an agent one question: the checkout test is failing, why? That question is the example for this whole video. Start with the model, the part everyone assumes does the work. The model is a piece of software that takes text in and writes text out. The model does not open files. The model does not run commands. The model does not touch your machine. Every turn the model writes one note, and that note is all the model produces. A note can be an answer: the test is failing because the test times out. Done, and nobody needed a loop. But the model has never seen your test file, so the model cannot write that answer yet. So the model writes a second kind of note, a request: read this file, and here is the path. That request is still only text the model wrote, and nothing has happened to your machine. Hold on to that, because that is the whole video: the model writes notes, and a note is not an action. That was step one of four, and the four have names. Step one is read, where the model reads the pile of notes so far and writes one note. The remaining three are about where that note goes. Ask, where the note names a tool. Act, where something runs that tool. Return, where the result lands on the pile and the model reads again. Read, ask, act, return. One chapter each, and by the third one you will see why the model is not the one doing the work. You already use one of these agents. Look at Claude Code: subagents, hooks, skills and permission modes, and not one of them is the loop. Take all of them away, and what is left is these four steps.

2:29Ask

Step two is ask, and a request works only when the model knows what can be asked for. So before the conversation starts, the program around the model hands the model a list. Each entry is a name, a description of what the tool does, and what that tool needs to be told. The model never sees the tools themselves. The model sees only the names and the descriptions that somebody else wrote. That list is the model's entire reach, so a tool missing from the list is something the model can never ask for. To get your test file, the model copies one name off the list onto the note, and writes the path beside that name. Now the program has to tell that note apart from an answer meant for you. The model solves the problem by marking the note. Watch that mark stamp into the note's corner. The mark is the whole signal. It says: do not print this note to the user, this note is addressed to the list. Answer, or ask. That single choice, made fresh on every turn, is the only decision anything in this system makes. In Claude Code the list arrives already written, carrying names like Read, Bash and Edit. You wrote none of that list.

4:08Act

Step three is act: the note says read your file, and something still has to open that file. That something is the program around the model, the code that reads the name on the note and runs the matching tool. This is the step people skip: the model did not read your file. The model asked, and the program read your file. Now watch what happens when the model asks for something not on the list. The model writes a note: send this report by email. The program reads that name and looks down the list for a match. There is no email tool on the list, so the program has nothing to run and nothing happens. The model was not stopped by any lack of ability. The model was stopped by the list somebody handed the model. So what an agent can do is whatever the program was built to do, however clever the model is. Here is the one exception, and it is about who runs the tool. A few tools, like web search and code execution, run on the machines of the company that made the model, not on yours. For those tools, the result simply arrives. For ordinary tools, reading a file or running a command, the program on your machine is what executes, every single time. The program runs the read, catches what comes back, and writes a note of its own saying what the file said. That note joins the conversation as a tool result, as if you had typed it. This is why Claude Code stops and asks your permission before running a command. That prompt only makes sense because the model has not run anything on your machine yet. Nothing would be left to approve if the model could act by itself.

6:20Return

Step four is return, and the conversation is a pile of notes stacked in order. On every turn the program sends the model the whole pile. The request was turn one. Turn two, and here is what the model reads: your question, the model's own request, and the file the program pasted in. In that file the model finds a three-second limit, but not what the test is waiting for. So the model writes another request: run the test. The program runs the test, and the failure output joins the pile as another note. Turn three, and the model reads the pile again: your question, the test file, and now the output. This time the model writes an answer instead of a request: the test waits three seconds for the service to answer. The service now takes four seconds. No request sits on that note, so the program has nothing to run, and the loop stops there. That is the entire loop: the model writes a note, and the program acts on the note. The result joins the pile, and the model reads the pile again. Read, ask, act, return: four steps, and step three was never the model's. The model gets its facts from outside itself, one turn at a time. Anthropic's wording for it: the agent gains ground truth from the environment at each step. Those were turns two and three of a Claude Code session. Every session ends the same way. The model decides it is done by writing an answer with no request on it. The program sees nothing to run and hands that answer back to you. The same four steps run wherever a model is given tools. Cursor, Codex, Copilot: different names on the list, the same loop.

8:40The Loop

That order looked like a plan: the model asked to read the file first, then to run the test. No plan was ever written down anywhere, and nothing in the system holds a plan. At turn two the model read the pile and picked the request that made sense there: run the test. Then the model read a longer pile at turn three and picked again. Planning is this loop running with more in front of the model each time. Memory is the same trick: the model does not remember your question by turn three. Your question is still sitting in the pile, and the program sent your question again. So the pile only ever grows: nothing leaves the pile unless the program takes a note out. The pile is also what you pay for. Every turn, the program sends the whole pile, and the whole pile is charged again. And the program hands the model that same list again on every one of those turns. Handing the model a list adds two hundred and eighty-six tokens of text before anyone has said a word. So a five-turn session is not five requests of the same size. It is five requests, each one bigger than the one before it. The loop buys a better answer with time and money. Anthropic names that trade outright: "agentic systems often trade latency and cost for better task performance." And the growing pile carries mistakes forward exactly the way the pile carries facts. A wrong turn early is still in front of the model on every turn after it. Watch the context bar creep up through a long Claude Code session: that bar is the pile getting longer. So look at what this loop needed. A model that writes notes, a list of tools, a program that acts, and a pile that grows. Only one of those four parts is the AI. The other three are ordinary code someone wrote around it. The intelligence is in the model. The agent is in the loop.