← All Posts

The Hype About Loops: How I Use Loops Today

If you've spent any time in the AI development space recently, you've likely seen the massive hype around "agent loops." Everyone is talking about building fully autonomous agents that run in a cycle—thinking, acting, and observing—until they magically solve a problem.

It sounds amazing in a demo. But when you try to take these autonomous agents and put them into a real production application, the hype crashes hard against reality.

Here is my take on why the common approach to agent loops fails in production, how I think about loops, and why strict boundaries and gates are the only way to build agentic features you can actually trust.

The "Toy vs. Production" Agent Problem

In a toy demo, you can afford to let an agent run in an unbounded while loop:

while (!agent.isDone()) {
  agent.think();
  agent.act();
}

If the agent takes 40 steps, consumes $50 in tokens, loops infinitely because of a minor syntax error, or makes a mess of your codebase, it's just a funny anecdote for a Twitter thread.

But in production software, this is completely unacceptable. You cannot ship a feature to users where:

  • The agent decides when it is finished. LLMs are probabilistic; they will eventually hallucinate success or miss a critical bug, then confidently declare they are "done."
  • The agent has unchecked access. Giving an agent a broad set of tools and letting it decide what to run, when to edit, and what databases to write to is a security and reliability nightmare.
  • The agent thrashes. When left to its own devices, a model that encounters an error will often repeat the same failing command, burning thousands of tokens while keeping you in the dark about what it's trying to fix.

If we want agents to automate real work in production apps, we have to stop treating them like magic autonomous creatures. We need to treat them like replaceable probabilistic workers operating within a highly disciplined, deterministic software harness.

My Philosophy: Code is the Control Plane

My understanding of a useful, production-grade loop is simple: the application must own the workflow, not the LLM.

Instead of letting an agent wander freely, we must design structured pipelines consisting of bounded nodes. Each node has a specific role, a restricted toolset, a dedicated model, and a hard timeout. The agent only executes task-specific logic inside these nodes, while the application code controls the progression, state, and permissions.

trigger (e.g., GitHub Issue)
  -> deterministic preparation (Code Node)
  -> LLM step with a narrow prompt, context, model, and tool set (LLM Node)
  -> code gate over output and execution evidence (Gate Node)
       | pass        -> next step
       | correctable -> bounded retry with structured feedback
       | uncertain   -> evaluator or human approval
       | terminal    -> fail safely
  -> final action
  -> completed run

Here is why this supervised architecture is crucial for production apps:

1. Hard Role & Tool Boundaries

In a production app, you need to restrict what an agent is allowed to do at any given moment.

  • During the Research phase, the agent should only be allowed to read files or search the web. It has absolutely no business editing code or writing to databases.
  • During the Implementation phase, it gets write permissions, but it has no web search tools, preventing it from getting distracted or leaking data.
  • During the Review phase, the agent is strictly read-only. It inspects the diff and runs tests, but it cannot modify the code.

By scoping tools per node rather than granting them globally, you build a sandbox that prevents runaway agent behavior.

2. Deterministic Validation Gates

You should never use a model call to verify something that simple application code can check. Before we pass an agent's work to the next step, a Gate Node runs deterministic checks:

  • Did the code compile?
  • Did the unit tests pass?
  • Did the browser smoke tests catch a React runtime error?
  • Did the agent actually run the required validation commands, or did it just claim it did?

The LLM output is untrusted until these programmatic gates say otherwise. If a gate fails, the system routes the agent back to a focused "fix" step, passing only the structured error output (e.g., "Test failed on line 45").

3. Timeouts, Budgets, and Active "Steering"

To prevent infinite loops and runaway token costs, the runtime must enforce strict timeouts and budgets. However, simply killing an agent mid-task is a frustrating user experience.

Instead, a production loop should actively steer the agent when it senses trouble:

  • Proactive Nudges: We can monitor the agent's behavior in real-time. For example, if the agent makes multiple file edits but fails to run the test suite, the runtime can inject a warning message directly into the context: "You have made code changes. Run validation tests now before proceeding."
  • Dynamic Failure Handling: If the agent ignores these nudges, gets stuck in a loop calling the same tool repeatedly, or approaches its timeout, the runtime intervenes. It can abort the step, reset the workspace to a clean state, swap the model to a higher-thinking version, or trigger whatever recovery logic is needed to save costs and redirect the agent toward producing real work.

4. Context Sanitization

Unbounded agents accumulate massive token histories containing dry terminal logs, directory listings, and old thoughts. In a production loop, we run a sanitize code node between every LLM step. We throw away the chat logs, the tool execution histories, and the fetch outputs, leaving only the clean artifacts (like a structured report or a git diff) for the next node. This keeps token costs incredibly low and stops the agent from getting confused by its own historical noise.

Putting it to Work: Pi Loops

To bring this philosophy to life, I built an extension for the Pi coding agent called Pi Loops.

Running Pi Loop

Pi Loops is an open-source framework that lets you build supervised loop workflows around the Pi agent. Instead of letting Pi run freely, you define a TypeScript-based state machine containing code, llm, gate, approval, and finalizer nodes.

As a reference, the repository includes a walkthrough for a GitHub Issue Automation Loop that handles the entire pipeline of fetching an issue, fast-researching, implementing the fix, running Playwright browser smoke tests, running code reviews using a high-thinking model, and opening a PR—all constrained under strict step-scoped permissions and a max 2-cycle review-fix budget.

You can install it for Pi today:

pi install git:github.com/Asm3r96/pi-loops

The Path Forward for Agent Developers

Agentic workflows are the future of software automation, but only if we design them with the same discipline we apply to traditional software engineering.

If we want to build AI systems that can run safely in production, we have to stop asking agents to control themselves. We must write the code that guides them, limits them, and validates their work every step of the way.