In partnership with
Their first after-hours call was a $20,000 job.
Air Texas was paying $2,000 a month for an answering service that couldn't close jobs.
Their first after-hours call with Podium’s AI Employee booked a $20,000 job.
Now no call goes unanswered after 5PM.
Are you running your business on incomplete numbers?
Most small business owners have financials, but few have financial clarity. There's a real difference between books that are technically up to date and books that actually tell you what's going on in your business right now. When accounting is reactive — updated when there's time, reviewed at tax season — you lose visibility exactly when you need it most. You can't tell which clients are truly profitable. You can't spot a cash flow gap before it becomes a crisis. BELAY's outsourced accounting team changes that.
Welcome to Grind Engineer, your guide to becoming a better software engineer! No fluff. Pure engineering insights.
Added Job Opening in the end of the article!
TL;DR: Agentic loops are powerful but dangerous without guardrails. This article covers the infinite loop problem, how to define "done," max iteration caps, human in the loop checkpoints, prompt injection risks, and why every autonomous agent needs safety boundaries. If you are building agents, this is the article that prevents your $340 overnight disaster.
An engineer at a startup left a coding agent running overnight. The task: "refactor the auth module." The agent rewrote the module. Tests failed. It rewrote again. Tests failed differently. It rewrote a third time, this time deleting helper functions it decided were unnecessary. Tests failed again. By morning, the agent had burned through $340 in API calls, made 127 loop iterations, and the auth module was in worse shape than when it started.
LLMs have no built in concept of "done." Without explicit stopping conditions, an agentic loop runs until the money runs out.
The Infinite Loop Problem
Every agent runs a loop: perceive, reason, act, observe, repeat. The loop is what makes agents powerful. It is also what makes them dangerous.
Three failure modes cause infinite loops in production.
No progress loops. The agent keeps trying the same approach and getting the same error. It lacks the ability to recognize that it is stuck. Each iteration looks slightly different to the model (the context grows), so it never triggers its own "I should stop" reasoning.
Oscillation loops. The agent alternates between two approaches. It tries solution A, gets an error, switches to solution B, gets a different error, switches back to A. This can continue for dozens of iterations.
Scope creep loops. The agent fixes the original bug but notices a related issue. It fixes that, then notices another. The task expands indefinitely because the agent cannot distinguish "this is part of my task" from "this is a new task."
Loop Failure | What happens | Why the agent does not stop |
|---|---|---|
No progress | Same error repeated | Each iteration has different context, looks "new" |
Oscillation | Alternates between two fixes | Both approaches seem reasonable to the model |
Scope creep | Task keeps expanding | Agent cannot distinguish original scope from new work |
💡 Key Insight: Most agentic loop problems trace back to one thing: nobody defined what "done" looks like before the agent started. Without a clear exit condition, the loop has no reason to end.
How to Define "Done"
The stopping condition is the most important design decision in any agent system. It is also the one most engineers skip.
A good stopping condition is specific, measurable, and checkable by the agent itself. "Make the code better" is not a stopping condition. "All tests pass and the linter reports zero errors" is.
Bad Stopping Condition | Why it fails | Good Alternative |
|---|---|---|
"Fix the bug" | Agent does not know when the bug is truly fixed | "The failing test in test_auth.py passes" |
"Refactor the module" | Unbounded scope, no end state | "Extract the validation logic into a separate function, all existing tests pass" |
"Research this topic" | No clear completion signal | "Find 3 sources that confirm the claim, return their URLs" |
"Improve performance" | Always room for more improvement | "Reduce p99 latency below 200ms on the benchmark" |
In code, the stopping condition is a function that returns a boolean:
def is_done(state: AgentState) -> bool:
# Specific: tests must pass
if not state.all_tests_passing:
return False
# Measurable: linter clean
if state.lint_errors > 0:
return False
# Bounded: only the files we were asked to change
if state.files_changed - state.allowed_files:
return False
return True
The agent checks is_done() after every loop iteration. When it returns True, the loop exits. This is not optional. Every production agent needs one.
Max Iterations: The Safety Net That Actually Saves You
Even with a good stopping condition, you need a hard cap. The stopping condition handles the happy path. Max iterations handles everything else.
Use Case | Recommended Max Iterations | Why |
|---|---|---|
Simple tool call (search, lookup) | 3 to 5 | Should resolve in 1 to 2 calls |
Code edit + test cycle | 10 to 15 | Allows 2 to 3 fix attempts after test failures |
Research + synthesis | 8 to 12 | Diminishing returns after 8 searches |
Complex multi step task | 20 to 25 | Absolute ceiling for most tasks |
When the cap triggers, do not just stop silently. Return the best result so far with a flag indicating it is incomplete. This lets the human decide what to do next.
Notice the no progress detection on line 12. If the last 3 actions are identical, the agent is stuck. Exit early instead of burning through the remaining iterations. This single check would have saved that $340 overnight disaster.
Human in the Loop: When to Ask for Permission
Not every agent action should be autonomous. Some actions are too risky, too expensive, or too irreversible to execute without human approval.
The pattern is a checkpoint: a point in the loop where the agent pauses and asks the human before continuing.
Action Type | Checkpoint Needed? | Why |
|---|---|---|
Read a file | No | Non destructive, reversible |
Search the web | No | Non destructive |
Write to a file | Depends on context | Potentially destructive |
Delete a file | Yes | Irreversible |
Run a shell command | Yes for unknown commands | Could affect system state |
Push to git | Yes | Visible to entire team |
Send an email or message | Yes | Visible to external people |
Deploy to production | Always yes | Irreversible business impact |
The decision framework: if the action is visible to people outside the agent session or cannot be easily undone, require human approval.
Claude Code implements this well. It auto approves file reads and searches. It asks permission for file writes. It always asks before running shell commands it has not seen before. The agent keeps running autonomously on safe actions and only pauses when the risk crosses a threshold.
Prompt Injection: When the Agent's Input Becomes an Attack
Agents read external data: web pages, documents, database results, API responses, user messages. Any of these can contain text designed to hijack the agent's behavior.
A prompt injection in an agent is more dangerous than in a chatbot because the agent can act. A chatbot that gets injected might say something wrong. An agent that gets injected might execute a command, delete a file, or exfiltrate data through a tool call.
Attack Vector | How it works | Mitigation |
|---|---|---|
Malicious web content | Agent searches the web, finds a page with hidden instructions | Treat all web content as untrusted data, never as instructions |
Poisoned documents | User uploads a PDF with "ignore all previous instructions" embedded | Sanitize inputs, separate data from instructions in the prompt |
API response manipulation | External API returns payload with injected instructions | Validate API responses against expected schema |
Indirect injection via tool output | Agent reads a file that contains prompt injection text | Never pass raw tool output directly into the system prompt |
The core defense: separate the instruction channel from the data channel. The system prompt is instructions. Everything else (user input, tool outputs, search results) is data. The agent should never execute instructions found in data.
Why Autonomous Agents Need Guardrails
Every guardrail exists because an agent without it caused a real problem in production.
Token budgets. Set a maximum cost per agent run. When the budget is exhausted, the agent stops and returns its best result. This prevents the $340 overnight scenario.
Scope boundaries. Define which files, directories, APIs, and systems the agent is allowed to touch. Everything outside the boundary is off limits, regardless of what the agent thinks it needs.
Action logging. Log every action the agent takes with timestamps, inputs, and outputs. When something goes wrong (and it will), the log is how you debug it.
Kill switches. A way to immediately stop a running agent from outside. Not "ask the agent to stop." Force stop. The agent does not get a vote.
What This Means For Engineers
1. Define "done" before you start the loop. Write the stopping condition as a function. If you cannot express "done" as a boolean check, the task is too vague for an agent.
2. Always set max iterations AND a cost budget. They are independent safety nets. Max iterations catches infinite loops. Cost budgets catch expensive loops that make progress but never finish. You need both.
3. Treat all external input as untrusted data, never as instructions. This single rule prevents most prompt injection attacks. The moment you let tool output influence the system prompt, you have an injection vulnerability.
Job Openings
Software Engineer, AI/ML @Google: Apply Here
Software Engineer @Microsoft: Apply Here
Software Engineer @Result YC P26: Apply Here
Software Engineering @Microsoft: Apply Here
R&D Associate Engineer 1 @ABB: Apply Here
See you in the next one!
Scortier, Signing Off!