/loop and /goal
at depth

A prompt teaches you to talk to AI. A loop teaches you to control it. That is the jump this chapter is about. So far you have run the model by hand, one exchange at a time. Now you meet the thing that runs it for you: a model using tools in a loop, working toward a goal, until it is done or you stop it.

That phrase, a model using tools in a loop, is not a metaphor. It is the actual definition of an agent, and it is worth seeing the mechanism plainly, because once you have, a lot of intimidating words like agent and automation collapse into something simple you can reason about.

Here is the whole thing. The model is given a task and a set of tools it is allowed to use. It thinks, and either it answers and stops, or it asks to use a tool. The tool runs, the result comes back to the model, and it thinks again with that new information. That cycle repeats until the model decides the job is done. That is the loop, and it is genuinely all there is to it.

That division of labour is the safety rail for everything in this part of the course. The loop and the tools are yours: you choose the goal, you choose what the model can reach, you decide when to step in. The reasoning is the model's: how to actually get from here to done. Trouble almost always comes from blurring that line, either handing the model reasoning you should have kept, or handing it tools you should not have given it. Keep the line sharp and a loop is a servant. Blur it and it is a liability.

A loop is only as good as the goal you point it at, because a loop will pursue what you actually said with a persistence a single answer never does. A vague goal followed once gives you a vague answer you shrug at. A vague goal followed in a loop gives you a machine confidently doing the wrong thing, over and over. So the goal comes first, and you lock it before the loop starts.

Locking a goal means writing down, clearly enough to check against, what done looks like. Not a direction, a destination. This is the same discipline as the founder-mode gate you will meet later: name the goal, name what finished actually means, and keep that written somewhere you can hold the work against it. Then, as the loop runs, you are not asking "is it busy?" You are asking "is it still heading at the locked goal, or has it drifted?"

The difference between running the model by hand and building a loop is the difference between doing a job and building the thing that does the job. A run happens once, when you are there. A loop can run on a trigger, when you are not: on a schedule, or when something happens. That is what turns a task into a system, and it is the real subject of this chapter.

The pattern that makes big loops manageable is to break the goal into phases. Instead of "do the whole thing," you have the loop work in named stages, each with its own small done-check, so you can see progress and catch drift at each boundary instead of only at the end. A loop that reports "phase one complete, here is what I have, moving to phase two" is one you can steer. A loop that goes dark for an hour and hands you a finished mess is one you cannot.

How much rope you give a loop is a dial, not a switch, an idea Andrej Karpathy describes as an autonomy slider. At one end, the model asks before every action and you approve each step. At the other, it runs the whole job untouched and reports at the end. Neither end is correct in general. The right amount of autonomy depends on how reversible the work is and how much you trust the loop on this particular task.

The honest rule of thumb, and this is ours rather than Karpathy's: start a new loop near the cautious end, watching closely, and slide toward more autonomy only as it earns your trust on that specific job. A loop that only reads and reports can run freely from day one, because the worst case is a wasted run. A loop that can change or send or delete things stays on a short leash until you have watched it behave, because there the worst case actually costs you. Match the rope to the stakes.

Building a real triggered loop, one that runs on a schedule and touches your actual tools, needs the terminal and the connections you set up in the next chapters. This chapter is the thinking that makes those safe: lock the goal, break it into phases, give it only the tools it needs, and set the autonomy to match the stakes. The mechanics come next.

A prompt is a sentence. A loop is a system. The moment you lock a clear goal and let a model pursue it with the right tools and the right amount of rope, you stop operating AI one answer at a time and start running it. That is the whole climb of this course, made mechanical.