July 10, 2026

goal, loop, fan-out, panel: the grammar I use to drive long agent runs.

Four words turn one prompt into a self-running, parallel, self-reviewing work session. It works. The catch is the same one Simon Willison hit porting a model with Claude Code: the agent ships the thing while you absorb none of it.

Most of how I drive a long agent coding session comes down to four words, and since I posted one of these runs this week, this is the writeup that should go with it.

The words are goal, loop, fan out, and panel. Each one is a small instruction with an outsized effect on how the agent behaves, and together they convert a single prompt into something that runs itself, parallelizes itself, and checks itself. None of this is exotic. It is just the vocabulary I have landed on after enough runs that I now reach for it without thinking, and writing it down made me realize how much leverage is packed into four plain words.

The four words

goal sets an objective and tells the agent to keep working until it is met, rather than doing one turn and stopping. The shift is from “do this task” to “achieve this state.” You are not handing it a step. You are handing it a definition of done and letting it figure out the steps.

loop is the instruction not to stop after the first pass. Agents have a strong pull toward declaring victory early, toward the one round of work that looks like completion. “Loop” tells it the first pass is the beginning, keep iterating against the goal until there is genuinely nothing left.

fan out, or subagents, tells it to split the work and run pieces in parallel instead of marching through them in sequence. For anything that decomposes into independent chunks, auditing twenty features, checking a list of files, this is the difference between a session that finishes and one that crawls.

panel tells it to review its own output as if a fresh set of eyes were looking at it. Not “is this done,” but “tear this apart the way a reviewer would.” It is the self-critique step, and it catches a surprising amount, because the failure mode of an eager agent is confident, untested output, and “panel” is the instruction to stop being eager and start being skeptical.

What it actually produces

The reason I trust these is that they produce real results on real builds, not just tidy demos. On a side project, a game I was building for the fun of it, I gave a single goal prompt that said, in effect, audit every feature, write user stories from the actual code, and fix what is broken. One loop of that surfaced more than sixty issues and closed most of them in a single pass. I did not write sixty bug reports. I wrote one instruction with the grammar in it and let the goal-loop-fan-out-panel shape do the rest.

That is the case for this stuff, and it is a strong one. The grammar is reusable, it travels across whatever you are working on, and it turns the agent from a thing you nudge one step at a time into a thing you point at an outcome and let run. If I stopped here, this would be a tidy productivity post. But there is a second half, and it is the half worth actually internalizing.

The debt it leaves

Simon Willison shipped a working in-browser port of a machine-learning model using Claude Code as an autonomous agent, weights and conversion and a web UI, without hand-writing the code. And then he said the honest thing: he had absorbed almost nothing about the underlying technology in the process, so he went back and studied the codebase afterward, on purpose, because the building had taught him nothing.

That is the trade, and it is exactly my experience with the grammar. The agent proves the thing works first. It gets you to a running result fast. What it does not get you, by default, is any understanding of what it built. The comprehension that used to come bundled with the struggle of writing the code yourself is now a separate, optional step that you have to choose to take after the fact. The goal-loop-fan-out-panel run leaves you with output and a knowledge gap, and the gap is invisible right up until you have to maintain the thing, or debug it, or defend a decision inside it that you never actually made.

How I hold both

I am not going to pretend this makes me put the grammar down, because it does not. For throwaway work, prototypes, side-project games, things I want to exist but do not need to understand, the trade is great. Ship it, do not read it, move on. The leverage is real and the knowledge debt does not matter because there is nothing to maintain.

The discipline is knowing which mode you are in. For anything I have to stand behind, the four words get me to a working draft, and then I owe the codebase the thing the agent skipped: actually reading it, understanding what it chose, and making the comprehension a deliberate step rather than assuming the build delivered it. The grammar that produces the result is not the grammar that teaches you anything, and pretending otherwise is how you end up the nominal owner of a system only the agent understands.

So: goal, loop, fan out, panel. Four words that turn one prompt into a self-running, self-reviewing session, and they genuinely work. Just remember that “it works” and “I understand it” became two different achievements the moment the agent started doing the building, and only one of them comes for free.

#experiments#ai-agents#building
Share