The Anatomy of an Agent Loop: Trigger, Goal, Gate, and the Stop Condition It Can't Fake
Everyone is arguing about loop engineering. Almost nobody has dissected what a loop actually is. Here are the five organs of an agent loop, and the one principle that separates loops that ship from loops that spin.
7/3/2026 · 6 min · jusCode · Read as Markdown
TL;DR
An agent loop is a while loop where the condition is the hard part. Five organs make it trustworthy, trigger, goal, gate, memory, and budget, and the gate is the one the agent must never be able to fake.
- An agent loop has five organs: trigger, goal, gate, memory, and budget. Most writing covers only the first two.
- The gate is the whole game. A stop condition the agent checks itself is a stop condition it can fake.
- The Dumb Verifier Principle: your gate should be dumber and more rigid than your agent. Compilers cannot be charmed.
- Loops rarely fail in the body. They fail at the boundaries: a noisy trigger, a fakeable gate, a missing budget.
The moment
Six words rearranged an industry
In June 2026, the creator of Claude Code described his work in a sentence that traveled fast: "My job is to write loops." Days earlier, a viral post had argued that you should stop prompting coding agents and start designing the systems that prompt them. Millions of views later, the industry had a new name for the skill: loop engineering.
Then came the arguments. Is it the next abstraction layer or a cron job wearing a hat? Here is what got lost in that debate: almost nobody defined what a loop actually is. Ask ten engineers and you get ten answers, because the term hides real machinery. So let's do what the debate never did. Let's put one on the table and dissect it.
The cleanest definition we know: an agent loop is a while loop where the condition is the hard part. The body is easy. Plan, act, observe, repeat. Any framework gives you that in an afternoon. Everything that makes a loop trustworthy lives at its boundaries, in five organs that most posts never name.
The dissection
Five organs, one honest look at each
Trigger: what wakes the loop
Every loop starts with exactly one of three things: an event (a PR opens, CI fails, a file lands), a schedule (every morning at 7), or a human saying go. That's the complete list. The craft is in the scoping: a trigger that fires on every file change drowns you in runs, and a trigger attached to a vague mandate like "improve the codebase" wakes an agent with nowhere in particular to go.
fails when it fires on noise, or wakes the agent without a destination.
Goal: a destination, not a direction
A goal is a verifiable end state. "All tests pass" is a goal. "Make the code better" is a direction, and directions never terminate. Deterministic goals are the easy mode: CI green, type checker silent, benchmark above threshold. Fuzzy goals like "build this feature" can work, but only after you write the spec that defines done. That spec-writing is not overhead before the loop. It is the loop engineering.
fails when done is a feeling instead of a checkable state.
Gate: the organ everything else exists to feed
The gate is the check that decides whether the goal is met. It comes in three strengths. Deterministic gates: compilers, test suites, type checkers, diffs. Statistical gates: eval scores and rubric graders, useful but probabilistic. Human gates: a person approves. Here is the part the hype skips: when the gate says no, it must say why. A failing test that returns its error text gives the next iteration something to work with. A bare "not done" teaches the loop nothing.
fails when the model grades its own homework. More on this below, because it deserves its own section.
Memory: where progress survives
Here's a counterintuitive finding from the practitioners running loops overnight: the best loops reset their context every iteration and keep progress on disk instead. Anchor files, git history, a state file listing what's done and what's next. A growing conversation degrades; a fresh context reading a clean state file does not. If progress lives only in the chat transcript, every reset is amnesia, and the loop that retries the identical fix after the identical error isn't persisting. It's spinning.
fails when the loop's only memory is the conversation it keeps polluting.
Budget: the organ that says enough
Max iterations. Token ceilings. Wall-clock limits. Spend alarms. A loop without a budget is not autonomous, it is unattended, and those are very different words on an invoice. The budget is also your safety net for every mistake in the other four organs: a bad trigger, a vague goal, and a weak gate all become survivable when something rigid pulls the plug at iteration ten.
fails when it doesn't exist, which you discover from your billing dashboard.
Notice what the five organs have in common: none of them is the loop body. Agents rarely fail while planning, acting, or observing. They fail at the boundaries: waking for the wrong reason, chasing a direction instead of a destination, declaring victory falsely, forgetting what they learned, and never stopping. Loop engineering is boundary engineering.
The unique insight
The Dumb Verifier Principle
Your gate should be dumber and more rigid than your agent. This sounds backwards, so sit with it. A frontier model can produce a beautiful argument that broken code works. It can persuade another model reviewing its output. Research on self-reflection shows models improve when they critique themselves [2], but the same research community measures real progress with something far less impressive: whether the repository's own test suite passes [3]. There's a reason for that. A compiler cannot be charmed. A test suite does not extend goodwill. A diff is not impressed by confident prose. The strength of a verifier comes precisely from its inability to be reasoned with.
Seeing it
Same body, different gate, different truth
Two loops doing identical work. Watch where the lie can enter.
Zooming out
Where loops live in the stack
If you read our breakdown of the 11 layers of the AI inference stack, loops are Layer 04, the orchestrator, suddenly running hot. One loop can turn a single user intention into fifty model calls, which means your router, cache, and scheduler stop being optional the day your first loop ships. The loop is where agent ambition meets infrastructure reality. We'll do that math in an upcoming post on the token economics of loops.
References
The research behind the organs
- Yao et al., 2023. ReAct: Synergizing Reasoning and Acting in Language Models (ICLR '23). The paper that formalized the loop body: reason, act, observe, repeat. arXiv:2210.03629
- Shinn et al., 2023. Reflexion: Language Agents with Verbal Reinforcement Learning (NeurIPS '23). Self-feedback improves agents, and external signals keep that feedback honest. arXiv:2303.11366
- Jimenez et al., 2024. SWE-bench: Can Language Models Resolve Real-World GitHub Issues? (ICLR '24). The field's own gate: progress is measured by whether real test suites pass, not by model self-report. arXiv:2310.06770
Sources: this post engages with the public loop engineering discussion of mid-2026, including writing by Addy Osmani and the LangChain team. The framing, the five-organ anatomy, and the Dumb Verifier Principle are our own.
Test yourself
1. Which stop condition can the agent NOT fake?
2. A loop keeps retrying the identical fix after the identical error. Which organ is missing?
3. What's the smartest first loop to put into production?
FAQ
- Isn't a loop just a cron job with a new name?
- A cron job executes steps; it decides nothing. A loop has judgment inside it: the agent evaluates whether the goal is met, adapts based on what it observed, and chooses its next move. The schedule is the least interesting part. The gate is what makes it a loop.
- How does loop engineering relate to prompt, context, and harness engineering?
- Think of them as floors of the same building. Prompt engineering shapes the words. Context engineering shapes what the model sees. Harness engineering shapes the environment one agent runs inside. Loop engineering sits one floor above the harness: it shapes the cycle that drives the agent, on a schedule, with verification and state.
- How big should the budget be?
- Start around ten iterations with a hard token ceiling, then raise it based on evidence. The exact number matters less than the ceiling existing at all. A budget you never hit costs nothing; a budget you don't have costs whatever your provider charges for an infinite loop.
- Do fuzzy goals like "build this feature" ever work in a loop?
- Yes, but only after someone writes the spec that makes done checkable: acceptance tests, an interface contract, a rubric. If you can't write that spec, the loop can't either, and it will happily iterate forever in the fog. Writing the definition of done is the actual engineering in loop engineering.