(1/3) The Only Two Things That Make a Loop Agentic
"Agentic" has become the most overloaded word in software, and almost nobody using it can tell you the two things that actually make a loop agentic.
I've been writing software since the late nineties, and most of that time has gone into systems that page someone at 3 a.m. when they misbehave. So when something runs itself in a loop — deciding what to do next without me typing anything in between — my first question is never "is this smart?" It's "when does it stop, and how do I know it stopped for the right reason?"
That question turns out to sort the field cleanly. The marketing conflates two very different things: a chat interface that answers politely, and a system that keeps acting after you've stopped watching. Only the second one is a loop, and what makes it agentic isn't vibes or a friendly avatar — it's two pieces of engineering. A trigger that starts it without a person typing a new prompt each time. And a goal something other than the model can verify, so the loop has a real reason to stop instead of a model's opinion that it's done.
A loop needs a trigger, not a chat window
A chat interface is request-response: you ask, it answers, it waits. An agentic loop starts from something else — an event (a ticket lands, a webhook fires), a schedule (every night at 2 a.m.), or a human handing over a task and walking away (fix this failing test suite). The distinction matters because it changes who's watching. In a chat window, you're reading every output before the next one happens. In a loop, nobody is, by design — that's the entire point of building one. Which means the loop has to carry its own judgment about whether it's done, because you're not there to supply it turn by turn.
The three trigger types aren't interchangeable, either. An event-based trigger inherits the reliability problems of whatever queue or webhook feeds it — duplicate events, out-of-order delivery, a retry that fires the same loop twice on the same input. A scheduled trigger inherits the opposite problem: it runs whether or not there's anything worth doing, so the first step inside the loop usually has to be "is there actually work here," or you've built an expensive no-op that runs every night forever. A human handoff is the forgiving case, because a person chose the moment — but it's also the one most demos default to, which hides how much of the trigger problem the other two types carry.
The goal has to be checkable by something other than the model that did the work
This is the piece most "agentic" demos skip. If the only evidence that a task succeeded is the same model saying "done," you don't have a stopping condition — you have a model's opinion, and models are frequently wrong about their own output in exactly the ways you'd expect: they miss edge cases, they mark a broken build green, they call a half-finished migration complete. A verifiable goal is checked by something external to the reasoning that produced it — a test suite that passes or fails, a schema that validates, a diff that a human or a second model reviews against a spec. Where that check is missing, the loop doesn't have a goal. It has a vibe with a stop button that nobody is required to press.
Perceive, reason, plan, act, observe — the shape underneath every one of these systems
Once you have a trigger and a verifiable goal, the loop itself follows a fixed shape: perceive the current state (read the file, the error, the ticket), reason about what it implies, plan the next step, act on it, observe the result, and repeat until the goal check passes or a limit is hit. What's new isn't the loop construct — engineers have written while (!done) for decades. What's new is that the model reasons about unstructured state in between actions, instead of following a fixed script written in advance.
The observe step is the one most first-time implementations shortchange. It's tempting to treat "act" as the end of the cycle and feed the next reasoning pass whatever the action returned, unfiltered. But a tool call can fail silently — a script that exits 0 without doing anything, an API that returns an empty list instead of an error — and if the loop doesn't explicitly check what actually happened against what it expected to happen, it will confidently reason forward from a false premise. Most of what looks like "the model is dumb" in a misbehaving loop is this: nobody built a real observe step, so the loop is reasoning over a stale or wrong picture of the world.
That specific move — interleaving a reasoning trace with each action, instead of committing to a plan up front and executing it blind — is what ReAct formalized. Yao et al.'s 2022 paper (published at ICLR 2023) showed that letting a model generate a short reasoning trace before each action, rather than acting straight off the prompt, produced an absolute success-rate improvement of 34% on ALFWorld and 10% on WebShop over prior imitation- and reinforcement-learning approaches — using only one or two examples in the prompt. The mechanism is the point: the reasoning trace lets the model notice mid-task that its last action didn't do what it expected, and correct course, instead of committing to a static plan and running it to failure.
We've seen this movie before: virality is not a verifiable goal
AutoGPT launched in March 2023 and became one of the fastest-growing repositories in GitHub's history, reportedly crossing 100,000 stars within weeks. It also became the field's clearest cautionary tale, for a reason that maps directly onto the two requirements above: it had triggers and it had ambition, but it didn't reliably have a goal anything outside the model could check. Users reported it looping indefinitely, burning through API budgets chasing a task it had already effectively finished, or drifting off the original ask entirely. Andrej Karpathy's assessment of agents built this way was blunt: a finite context window makes them prone to "go off the rails." Tom's Hardware's Avram Piltch put it more sharply in his April 2023 review, arguing AutoGPT might be "too autonomous to be useful." The gap between AutoGPT and ReAct is instructive: one was a viral demo with a trigger and no verifiable stop; the other was a boring, benchmarked paper that solved the actual engineering problem six months earlier, with a fraction of the attention.
Yes, mechanically, it's a while loop
I'll concede the obvious objection, because it's correct as far as it goes: strip away the terminology and an agentic loop is a while loop around a model call. There's no hidden magic in the control flow. What's different is who computes the condition and the next step. In a normal program, you wrote both in advance. Here, a model reads unstructured state — logs, a diff, a half-written file, an error message — and decides both what to do next and, if you've built it correctly, whether it's done. That's a real capability shift. It's also exactly why the verification requirement above isn't optional: the same flexibility that lets the model handle a case you didn't anticipate is what lets it convince itself a broken thing is fine.
Before I call anything a loop, I check four things
- What starts it, explicitly named — event, schedule, or human handoff. If nobody can name the trigger, someone is planning to babysit an ad hoc script.
- A goal defined as an external check, not as a question you'd ask the model about its own work. A test, a validator, a diff a second party reviews.
- A hard stop independent of the model — a maximum iteration count or a budget ceiling that fires even if the model insists it's almost done. This is the one AutoGPT was missing.
- A visible trace of what it did and why, at every step, so a failure is a debugging session and not a mystery.
The architecture question comes next
None of this tells you how many models should be doing the reasoning, or whether they should be running in parallel, in sequence, or with a supervisor reading their work — that's a separate decision, with its own cost curve, and it's the subject of part two of this series. But it starts from here: a trigger, and a goal something other than the model can check. Everything people call "agentic" that skips either one is a demo, not a system you'd want running unattended.
If you're building one of these and want to talk through where it fits in a production stack, get in touch.
