An agent loop looks simple when it is drawn on a slide. Give the model a goal, let it take an action, check the result, and repeat until the work is done. The difficulty, however, hides inside the word “until.”
How does the system know that it is getting closer to the goal rather than repeating itself? Who decides whether the result is correct? What prevents the agent from changing the test until its own work passes? And if the model can continue taking actions, spending tokens, and modifying files, what finally makes it stop?
For this episode of the Agentic Engineering podcast, I spoke with Rick Hightower, a senior AI engineer and certified Claude architect who has spent more than 20 years building software across companies including Apple, Capital One, and the NFL. Rick now focuses on the less-visible parts of agentic systems: harnesses, context, state, verification, and loops.
Rick began working with AI before today’s command-line agents and coding harnesses were available. The models could suggest what to do, but he still had to move the output into the development environment, run the tests, inspect the result, and decide what should happen next. As he puts it, he was the loop.
Today, harnesses can take on more of that responsibility. But before we remove the person who was checking the work and deciding when to continue, we need to understand what will replace them.
So we began with the most basic question: what actually turns a series of prompts into a loop?
Editor’s note
We’ve tucked a subscriber-only perk into this edition. If Rick’s ideas resonate with you, keep reading… the private code is waiting below.
What turns a series of prompts into a loop?
Before command-line agents and coding harnesses existed, I was the loop. I would ask ChatGPT or Claude to research an approach or help port code, move the result into the development environment, run it, inspect what happened and then decide what to try next.
A real agent loop automates that feedback process. It has an expected outcome, a way to verify the result, and a mechanism for returning useful feedback when the result fails. It continues until the work meets the stated criteria or the system determines that it cannot complete the task with the information and tools available.
I use Mermaid diagrams as a simple example. The agent can generate a diagram, lint the syntax, and correct any errors. Once it renders, another model can inspect the image and compare it with the original requirements. The first check tells us whether the diagram is valid. The second tells us whether it actually represents what we asked for.
Without verification and feedback, we do not really have a loop. We have a sequence of prompts.
Who verifies the verifier?
If the same agent interprets the requirement, writes the code and creates the test, it may define success in a way that agrees with its own implementation. It may even change the test to make its work pass.
The harness should control what the agent is allowed to modify. Permissions can prevent it from editing protected tests, and hooks can detect when it tries. There may be legitimate reasons to update a test, but that change should be explained and, in higher-risk situations, reviewed by a person.
Wherever possible, I prefer deterministic verification: does the code compile, does the test pass, does the output match the schema, or does the file pass a linter? When that is not possible, I use a separate judge or adversarial subagent.
The judge should receive the requirements and the final output, but not necessarily the full context of the agent that produced it. If both agents share the same reasoning history and assumptions, the judge may inherit the same bias. I think of it as the difference between the person doing the work and the teacher grading it.
How does a loop know when it is stuck?
A loop can continue producing new output without making meaningful progress. It may repeat the same action, revisit an approach that already failed or improve one part of the result while breaking several others.
I have encountered this while tuning systems that extract structured information from documents. The loop may be working towards a target accuracy across several categories. One attempt improves one category but causes the others to fall. The next attempt reverses the change. The system is doing work, but the overall result has stopped improving.
The harness needs an exit condition for that situation. It might stop after four or five attempts without progress, after a fixed number of turns or after reaching a token or cost limit. It should also recognise when it cannot succeed because data is missing, a downstream system is unavailable, or the available tools are not enough.
Ideally, the loop stops because the work is complete. But production systems also need a responsible way to stop when completion is not possible. At that point, the agent should change strategy, ask for help, or hand the problem to a person.
If this conversation has you wondering whether your agent is a reliable system or just a prompt with permissions, Rick is teaching a live, hands-on workshop on August 29.
In Engineering Reliable Agentic AI Systems, you’ll spend four hours getting into the machinery behind production agents. And here’s something just for the Agentic Engineering circle: subscribers get 40% off the ticket price.
Your private code is AE40. Use it at checkout.
Are we blaming models for failures caused by the harness?
When an agent behaves badly, the model usually receives the blame. But many failures begin elsewhere in the system.
A team adds a feature and changes the prompt. That new feature works, but three older behaviours stop working. A model provider releases an update, the retrieval system starts loading different context, or someone changes the few-shot examples. The output becomes worse, and it looks as though the model has suddenly lost a capability.
The most common problem I have seen is drift. Agent systems have many moving parts, and changing one of them can create regressions somewhere else. That is why teams need a known set of inputs, expected outputs, and a way to grade them after every meaningful change.
I describe the principle as “slow down and go fast.” If you can detect regressions early, you can move quickly without repeatedly breaking the behaviours you already depend on. Otherwise, developing these systems can feel like nailing Jell-O to a wall.
The harness controls the context, tools, permissions, state, verification, and stopping conditions around the model. Before replacing the model or rewriting the prompt, inspect those layers.
Where does memory live when the model has none?
LLMs are stateless, but a useful agent needs to know what has already happened, what remains unresolved, and whether its latest action changed anything.
I separate memory and state into several categories. There is conversational memory, which may be compressed into a summary. There are important facts that should be stored explicitly because summarisation can lose them. There are instructions and procedures in files or agent skills. There is information retrieved from a database or RAG system when the task requires it. And there are plans, tickets, logs, and repository history that allow the work to continue beyond one session.
The goal is not to keep everything in the active context. If the context becomes too large, important information gets buried, and the model begins forgetting things it would normally handle correctly.
I prefer to keep the main agent focused and use subagents for narrow tasks. Once one task is complete, I can clear the context and begin the next one using the durable information stored in the specifications, plans, and tickets.
If you cannot clear the context because the agent would forget everything it has been doing, the important state probably needs to be written down somewhere outside the conversation.
Keep up with Rick
Rick publishes practical deep dives on harness engineering, loop engineering, agent memory, context, and production AI systems.
Find him on Medium as @richardhightower, or subscribe to Hightower’s AI Harness Engineering on Substack.
Is a specification more than a very long prompt?
A prompt usually tells the agent what to do next. A specification describes the system, the work that needs to be completed, the constraints, and the conditions that should be true at the end.
That makes the specification the fuel for a long-running loop. I have given agents several tickets, asked them to complete the work, launch the application, visit the relevant pages and compare the result with the agreed mock-ups. The agent can run for hours because it has both a roadmap and a definition of done.
But a long specification is not automatically a good specification. If the plan is incomplete or wrong, the agent may follow it perfectly and still produce the wrong result. Garbage in, garbage out does not disappear because AI is doing the implementation.
For important or complicated plans, I often ask another agent—sometimes a different model, sometimes the same model in an isolated context—to look for missing assumptions and unclear requirements. A second set of eyes usually finds something.
The specification should also be visible to the human stakeholders who understand the intended outcome. An agent can critique a plan, but it cannot recover business context that nobody gave it.
Can the same specification safely drive action and verification?
Using one specification to tell the agent what to build and then using that same specification to judge the result is efficient, but it creates a shared point of failure.
If the specification misses a requirement, both the builder and the verifier may agree that the work is complete. The agent has built exactly what it was asked to build, but the requested system was wrong.
I still use the specification as the basis for verification, but I try to support it with independent evidence. That may include sample inputs from product management, approved mock-ups, existing tests, business rules, or review from an agent that did not participate in writing the implementation.
The agent should also be able to question the specification. If it finds a contradiction or discovers that an acceptance criterion cannot be satisfied, continuing blindly is not useful autonomy. It should report the problem and bring a person back into the loop.
The specification guides the work. It should not become something the system is forbidden to challenge.
How do you verify an autonomous research loop?
Research does not have the same natural completion signal as code. There may always be another source to read, another reference to follow, or another direction to investigate.
The research loops I have built usually begin with an agreed outline and a defined artifact, such as a document, image or presentation. The system can then validate whether the artifact follows the outline, whether the facts have been checked and whether it meets the required grammar, style and quality standards.
In that case, the verification gate is the rubric agreed upon before the research begins. The loop is complete when the artifact meets those requirements—not when the agent has exhausted every possible source.
Some research and experimentation also have external signals. In marketing, an agent can test different advertisements, measure clicks or conversions, and use that result to decide what to try next. AI could run far more of those experiments than a human marketing team could manage manually.
Open-ended research is more difficult. A rubric can tell us whether an artifact meets its requirements, but it cannot prove that no useful information remains undiscovered. We should be honest about that rather than pretending every kind of research can be given a perfectly deterministic finish line.
What did production force you to change your mind about?
Verification is expensive. Once you add adversarial subagents, judges, and feedback loops, a workflow may cost five or ten times more than a single model call.
But the useful comparison is not between a verified system and the cheapest possible workflow. It is between the cost of verification and the cost of delivering the wrong result.
If I can verify something with a compiler, test, or linter, I will use that. When I cannot, I may use a rubric and another model. That increases inference costs, but it also produces much better results. A brand violation, a broken production change, or an incorrect high-stakes answer can cost far more than the additional model calls needed to catch it.
If I had only one hour to design a new loop, I would begin with the verifier and the stopping conditions. What does done look like? What evidence proves it? How many attempts can the agent make? What happens if it stops improving?
I would also define the permissions and boundaries before allowing the loop to run. I would not run an unfamiliar autonomous agent with unrestricted access to the same machine that holds my credentials, personal files, or business systems. Use a sandbox, virtual machine, or managed environment, and give the agent only the tools it genuinely needs.
Rick’s case for loop engineering is not that we should let agents run for as long as possible. It is that agents become more useful when the system around them can recognise success, detect failure and stop them safely when they are no longer making progress.
The model may perform the visible work, but the harness determines the conditions under which that work happens. It supplies the context, preserves the state, controls the tools and decides when a person needs to return.
Before giving an agent a longer task, a larger context window or more powerful tools, the most useful place to begin may be the end: decide what ‘done’ means, how you will recognise it and what the system should do when it cannot get there.
Enjoyed today’s podcast and want more honest engineering conversations?
Pull up a chair ↓
That’s it for this one. We’ll pick up the conversation next week.
Until then, keep building.
Tanya D’cruz
Editor-in-Chief
