The Agent Is a Loop, Not a Person

The first time a model used a tool on my machine, I felt the old science-fiction reflex: something in the room had become a someone. It opened a file, wrote a function, ran a test, and apologized when the test failed. The apology was the tell. I started talking to it as if it could be disappointed in itself.

That reflex is expensive. It leaks into product copy, into architecture reviews, into the way we name folders. We build dashboards called “team members.” We write evals that ask whether the agent was “helpful.” We staff a human to “manage” a fleet as if the fleet could be mentored. Meanwhile the thing that actually ran was simpler, and more useful, than a person: a loop.

An agent is a loop with three privileges: it may observe, it may act, and it may decide to stop. Everything else is costume.

The loop, named plainly

You can draw it on a napkin. A goal arrives. The model proposes a next step. A harness executes that step against a bounded set of tools. The result is written back into context. The model looks again. At some point a stop condition fires — success, failure, budget, or a human interrupt — and the loop ends. That is the whole animal.

Personhood is what we project onto the pauses. The model writes in the first person. It hedges. It uses our idioms for doubt. None of that is a self. It is a style of next-token prediction that happens to be trained on a corpus of people talking about themselves. If you design as if there is a self in there, you will hide the only parts of the system you can actually improve: the tools, the memory, the stop rules, and the evaluation.

What the metaphor breaks

• Accountability. A person can own a mistake overnight. A loop owns nothing unless you log the trace and assign a human.
• Continuity. A colleague remembers Tuesday. A loop remembers what you stuffed into the window, the store, or the fine-tune.
• Motivation. People get bored, ambitious, political. Loops get longer contexts and worse attention.
• Consent. You do not “ask” a loop to work late. You raise a budget.

I am not arguing that the writing should be cold. Warmth in the interface is fine. Warmth in the architecture is how you lose the plot. The product question is never “what would a good employee do.” It is “what observation, action, and stop condition would make this task cheaper and safer than a human doing it once.”

Design from the stop condition backward

The most neglected part of the loop is the end. Teams spend months on planners and personalities and then ship an agent that cannot tell when it is finished. It keeps editing. It keeps searching. It keeps “just checking one more file.” Users experience this as either magic that never quite lands or a bill that never quite stops.

A good stop condition is specific enough to grade. “The test suite is green and the diff is under 200 lines.” “The invoice fields match the PDF and a human has clicked accept.” “Three retrievals returned nothing useful.” Vague stop conditions — “when the user is happy,” “when the task is done” — are how loops become rooms you cannot leave.

A more useful vocabulary

I have been trying, in reviews, to retire a few words. I say “trace” instead of “thought.” I say “tool policy” instead of “judgment.” I say “budget” instead of “effort.” The room gets less romantic and the design gets sharper. People stop asking whether the agent is smart and start asking whether the loop is closed.

That is the work I want this site to do. Not to deflate the excitement — the loops are genuinely new — but to keep our hands on the parts that exist. An agent is not a person who happens to live in your repo. It is a loop you are responsible for turning off.