The fix is not a smarter model. It's writing the definition of done outside the agent, as a condition something else can check, and giving the agent a way to run that check before it hands anything back. Agents don't stop early or loop forever because they're confused, they do it because nobody told them, in verifiable terms, what finished actually means.
I learned that the annoying way. One of my agents rewrote the same outreach email 14 times in a single run, each version a little better than the last, none of them sent. Total cost was 38 minutes and about $9 in tokens for something a human does in four. It wasn't broken. It was unbounded.
What does an agentic workflow definition of done actually look like?
A definition of done for an agent is a condition a machine can check. Not a noun. Not a vibe. A test.
"Write the vendor summary" is not a definition of done. "A file named vendor-summary.md exists, contains all 9 vendor names, has a cost column with no blanks, and a validation script returns PASS" is.
Here is what I now put in front of every agent, as a spec file it reads at step one:
- The artifact: exactly what gets produced and where it lives
- The check: a script, schema, or checklist that returns PASS or FAIL
- The negative constraints: what it must not include
- The escalation: what happens if the check fails twice
- The stop log: one line written every time the agent stops, with the reason
Concrete tools for this: a DONE.md file in the repo that the agent reads with cat, or a Notion page pulled in as context, plus a small Python function using Pydantic to validate the output shape. Twenty lines of spec beats a thousand words of "be thorough." I go deeper on the spec format in the AI OS playbook if you want the full template.
Why does my AI agent stop early?
Because you asked it to help.
"Help with the report" implies partial work is acceptable. "The report is finished when it has these five sections and this data table" leaves no room. Agents mirror the shape of the request. A question gets an answer. A deliverable with a test gets a deliverable.
The second reason is the default loop limit. Most frameworks run an agent two or three times and then quit, so a task that needed six passes returns whatever it had at pass three, wearing a very confident tone.
The fix is a verifier pass. The agent produces the artifact, then a separate call checks it against the checklist and returns PASS, or FAIL plus the specific missing items. On FAIL, those missing items go back in as the only instruction. I cap it at three passes. Tools that do this well: a conditional edge in LangGraph, an IF node in n8n, or honestly a while loop with a counter in Python.
That one change did more for my agents than two years of prompt tinkering. Before, I was reading outputs and guessing whether they were good. Now the agent tells me whether it passed its own test, and I only read the exceptions.
Why does it over-deliver or loop forever?
Two failures, same root cause: nothing costs the agent anything.
Over-delivering comes from instructions like "be thorough" or "make it great." I had an agent researching wedding venues that kept going deeper. It burned 40 minutes and produced a 2,000 word analysis of one property when I needed three lines comparing prices. Nothing in the prompt said where to stop, so it kept finding more to say.
Looping is the opposite failure, and it usually means the check can never pass. If your rubric is "is this good writing," the agent keeps trying forever because the answer is always no. If your rubric is "does every row have a GL code," it either passes or it doesn't.
What works for both: negative constraints and a budget.
"Return only the CSV. No commentary. No headers beyond row one." Then max_iterations: 3, a token ceiling, and a wall clock. Every agent I run gets a kill switch, and it is not a safety net, it's a design decision. The people who get agents working are the ones who decide up front what the agent is not allowed to spend.
What are the AI agent stopping conditions that actually work?
Three kinds, and a real agent needs all three.
State-based. The artifact exists and passes validation. Tools: JSON schema validation, Pydantic models, a regex check, or a plain "did the file get created and is it over 400 bytes" test. This catches stopping early, because the artifact fails the check and the agent loops back.
Budget-based. Iteration cap, token cap, time cap. This catches looping. A concrete step: wrap every agent call in a timeout and write the loop counter to a variable you check inside the workflow. In n8n that's a loop node with a max value, in code it's a while with a counter.
Human checkpoint. When the check fails twice, or confidence drops below a threshold, the agent stops and writes a summary to Slack with what it tried and what's missing. That's an escalation path, not a failure. My rule is that an agent that escalates is working correctly.
Then log the stop. Every run writes one line: stopped because DONE, stopped because BUDGET, stopped because ESCALATED, plus a reason. That log is how you find the agent that has been quietly lying to you for a month.
None of this is exotic. It's the boring parts of software engineering applied to something that feels like magic. Bookkeeping absolutely bores me, and this is the same flavor of boring. It's also the entire difference between an AI that's busy and an AI that's useful.
How do you keep this straight across dozens of agents?
You stop treating each one as a separate art project.
Every agent gets the same spec format: job, definition of done, stopping conditions, escalation path. Because of that, I can audit stops instead of reading outputs. When 45 of them are running across venues, resorts, and the AI companies, the only thing I check daily is the stop log.
What's becoming clearer to me is that AI agent completion criteria are the whole game. Anyone can wire a model to a tool. The people who get ten times more out of agents are the ones who wrote down, in advance, what finished looks like and what to do when it isn't.
FAQ
What's the difference between a stopping condition and a prompt instruction? A prompt instruction is a sentence the model reads and interprets. A stopping condition is a test something else runs that returns PASS or FAIL. Instructions get negotiated. Tests don't.
How many loops should an agent get before it escalates? Three for most knowledge work. If a task can't pass its own check in three passes, the checklist is wrong or the job needs a human. More loops mostly buy you more tokens and a weirder artifact.
Can I build agentic workflows with no code? n8n or Make can handle the logic, the loop counter, and the escalation message, so you can get most of the way there without writing much. The one piece you usually still want a small script for is the validator, because that's the part doing the actual judging. A 15 line Python function that checks a JSON object is fine, and you do not need to be a developer to write one.
If you want the exact structure I use for this, I wrote the full playbook. How to Build Your Own AI Agent Operating System walks you through the architecture step by step, including the spec file, the verifier pass, and the stop log I read every morning. You can get it at a.mastermindshq.business/ai-os-book.