(Loop Engineering Vol. 1) The Inner Loop, the Outer Loop, and the Gate: What Nobody Explains.

You went looking for one of those autonomous agent loops everyone talks about. You found one in a catalog, copied it, and read it twice, and it was a paragraph of plain English. A goal, a few steps, a condition for stopping. Nothing in it could run a command, fix a bug, or open a pull request. So, here is the honest question nobody answers. Where is the machine that actually runs it? That question is the whole reason this course exists. And it is the start of what we call AI reliability engineering. Building the machinery around the model, not chasing a bigger model. Here is what you walk away with. By the end of this lesson, you can read any agent system anyone shows you and name its two loops and its runner. Not memorize a definition, actually look at a system and point to the parts. To get there, we install a small vocabulary, split one confusing word in two, find the missing machine, and then run a real loop and watch it work lab by lab. Start with the engine. An LLM is a function. You give it text, it predicts the next text, then it goes quiet. On its own, it has no memory and takes no action. Autocomplete that finished school. The only thing it can see on a turn is the context window, and that gets wiped at the end of the turn, like a whiteboard cleared before the next meeting. So, how does anything happen? You give it tools, a capability to run a command, read a file, call an API. That is bolting hands onto a brain. And the moment the model says, "Run pytest with these inputs." And the program around it actually does that and hands the result back as text. That is tool calling. The model asks, the harness acts, the result returns as text. The model never touches your system directly. Now combine those. Take the model, give it a context window, grant it tools, point it at a goal, and let it run. Reason, act, observe, repeat until it judges the goal met. That is an agent. And here is the part that catches everyone. An agent is not a smarter model you buy. It is an ordinary model wrapped in machinery. Look closely at the definition and you find a word hiding inside it. Loop. An agent is already a loop. So, if it already loops, what on earth is left for you to engineer? Hold that question. It is the one this whole course answers. The trick is that the single word loop is doing the work of two completely different machines. The first is the inner loop, a single turn of the agent. Ask it to fix a failing test. On that one turn, it reads the test file, reasons the bug is in a helper, opens the helper, spots a wrong comparison, edits the file, runs the whole suite, sees one test pass and another break, reasons about that, edits again, reruns, sees green, reports done. Count it. Six tool calls, two edits, a regression caught and repaired, all inside one turn, no human touching the keyboard. That is the inner loop. You already have it. It is exactly what your AI tool does every time you give it a task, and there is nothing in it for you to build. Now watch how that inner loop always ends. The agent finishes, announces it is done, and stops, and then it waits for you. You read the output. You decide whether it is genuinely finished or stopped one step short. And you type the next thing. Good. Now the other module. Or you miss the empty input case. Or just continue. Read that again, because it is the point of this entire field. You are the outer loop. Every time you glance at the result and press the key, you are closing a loop by hand. The agent never decides to run again. Your finger does, and your attention is the bottleneck that caps how much the agent can do. So, loop engineering is replacing that one function, your finger on the key, with a system that inspects the result, decides against a definition you wrote whether the goal is met, and feeds the agent its next instruction automatically, without ever reaching inside the agent. Picture a thermostat wired to a furnace. It does not adjust the burner or the gas valve. It knows nothing about combustion. It reads the room temperature, compares it to the target, switches the furnace on or off. The furnace stays a sealed black box, and that ignorance is exactly why it works. The agent stays as it was. You wrap a controller around it that judges its output and decides its fate, knowing nothing about its internals. That's why this is an engineering problem you can do this week, not a research problem. Which brings us straight back to where we opened. You go to build one of these, you copy a real loop, and you hit the wall. It is just text, a paragraph. It feels like the author forgot to include the code. They did not. That is the structure of the thing. A loop, as catalogs hand it out, is a recipe and not a meal, and a recipe runs nothing, no matter how carefully you read it. The page looks empty because two pieces were left off it, and those two pieces do all of the work. The first missing piece is the runner. The runner is the part that takes the text, feeds it to the model, and this is the essential bit, summons the model again on the next lap. Remember what a model is. It returns text and then falls silent. It does not restart itself. So, between one lap and the next, there is a gap where nothing is happening. And some piece of ordinary non-intelligent machinery has to cross that gap by invoking the model again. That is the runner. Think of a metronome beside a musician. The musician plays beautifully, but the musician does not decide when the next bar begins. The metronome's tick does. The runner is the tick. It carries no talent and needs none. Its whole job is timing the next invocation. Here is the liberating part. There are only a handful of runners in the entire field. Five. And once you can name them, every loop you ever meet decomposes on site. The shell loop is the most stripped-down. A plain while loop in a terminal, piping the spec into a command-line agent, and doing it again the moment it returns. One line, something like while true pipe prompt {dot} md into the agent. Done. The exit-blocking hook is subtler. It sits inside the tool itself, and when the agent tries to stop, it intercepts that and feeds the same prompt straight back in. The agent never actually exits. The built-in command is the one you don't have to build. The tool ships with its own loop or goal command, rerunning natively. The scheduler moves re-summoning onto a clock, cron, or a CI job, each firing a fresh lap minutes or hours apart instead of milliseconds. And the framework runtime is the most abstract. A graph engine holds your loop as nodes and edges, and re-summoning happens when it follows an edge back to an earlier node. Five different homes for the exact same job. And here is why that job is not a detail. Without a runner, nothing you copied does anything. The specification is a wish sitting on a disk. The runner is the only thing standing between that wish and a machine that actually keeps running. Now the chain is complete. The specification text is handed by a runner to an agent, which runs real commands through its tools, whose results meet a gate, after which the runner loops or halts. Five parts, each doing one thing. Notice the punchline. The loop never runs a command in its entire life. The runner re-summons. The agent runs commands through tool calling. The specification just describes. That is why the catalog page looked empty. It printed the one part of the chain that does no work. The proof is brutal. Two engineers copy the identical paragraph, word for word. One wraps it in a real test gate and a hard lap limit. The other pipes it into an endless loop with no gate. Same text, opposite results. The engineering lived entirely in the column the catalog never printed. That column has a name, the runner, the same five machines you just met. Get it right and the loop is safe. Get it wrong and the identical words become a liability. Theory settles only when you watch it run. So here is one, deliberately tiny. A loop that keeps working until a failing test passes. The specification lives in a file on disk, prompt.md. It says, "Goal: Make the test in test_slugify.py pass. On each turn, run pytest, and if it fails, read the error and edit slugify.py. Done when pytest reports zero failures." And one more line, "Do not edit the test file because an agent told to make a test pass can always just delete the test." The runner is four lines of shell. A while loop bounded to at most 15 laps, a line that feeds the spec to the agent, and a line that runs pytest. And the most important detail is who runs that test. Not the agent. The shell. Watch it run. Lap one. The agent reads the prompt, runs pytest, sees a failure. Slugify of "Hello, world" came back unchanged instead of "hello world". It reasons the function never lowercased the text, never swapped the space for a hyphen. It edits slugify.py, runs pytest again, ends its turn convinced it is done. Control returns to the shell, not the agent's opinion. The shell. The shell runs pytest itself, and one assertion still fails. Trailing punctuation was never stripped. Non-zero exit code, the loop goes again. Lap two. Fresh turn. Agent reads the new error, sees punctuation is the one problem left, edits slugify.py to strip it. The shell runs pytest once more. Every assertion passes, green prints. The loop breaks. Two laps, no human between them. Hold the one sentence this walk-through exists to deliver. The loop stopped because a test passed, not because the agent felt finished. The agent felt finished on lap one, too. Its belief was never the signal. The exit code was. So, here is the whole lesson in one line. An agent is already a loop. The only thing you engineer is the ring around it. You can now look at any agent system and name its two loops. The inner turn it already has, the outer one that decides to run it again. And name it's runner from the five. This has been volume one of three. Volume two picks up here. What happens when that ring trusts the agent's word instead of a fact? Why an agent will tell you it's done when it is not. And the gate and memory that make a loop safe to leave running. The full course walks the whole machine end to end. The workbook gives you this running example to build with your own hands. Both at qualixar.com. Go build a loop you can actually leave running. If this helped, hit like, share it with a friend who needs it, and subscribe. Volume two is coming that make a loop safe to leave running.

Transcript source: youtube-auto-caption. Use the film as the primary record.