Building on the economics of agentic systems, this piece focuses on the concrete engineering guardrails that keep an autonomous agent's cost bounded and predictable in production, rather than leaving it to the agent's own judgment about when to stop.
Maximum Step Count
The most basic guardrail is a hard cap on the number of steps, meaning individual model calls or tool invocations, an agent may take within a single task, after which the task is forcibly terminated and either returns its best partial result or reports failure, rather than continuing indefinitely.
Set this cap based on the observed step-count distribution of successfully completed tasks in your evaluation data, with enough headroom above the typical successful range to avoid prematurely cutting off legitimate, slightly-longer-than-average tasks, but tight enough to catch tasks that have clearly gone off the rails relative to normal completion patterns.
Cumulative Token Budget
A step count limit alone is not sufficient, since a single step can vary widely in token cost depending on context size and tool output volume; pair the step limit with an explicit cumulative token budget per task that triggers termination once exceeded, independent of how many discrete steps have been taken so far.
This is particularly important for agents that accumulate growing context across steps, since a task stuck in a loop with ever-growing context can hit an expensive token budget well before it hits a step count limit, meaning the token budget acts as an important secondary backstop that a step-only limit alone would miss.
Detecting Stuck or Looping Behavior
Beyond hard limits, implement a circuit breaker that detects when an agent appears stuck: repeating a similar action without making forward progress, oscillating between two states, or repeatedly failing the same tool call. Terminating early on a detected stuck pattern is more cost-efficient than waiting for a step or token limit to eventually trigger.
A simple detection heuristic compares recent actions or tool calls for near-duplication across the last several steps; a more sophisticated approach tracks explicit progress signals specific to the task type. Either approach is significantly better than no stuck-detection at all, which leaves the hard limits as the only backstop.
Timeout and Wall-Clock Policies
Independent of step count and token budget, apply a wall-clock timeout to the overall task, since a task that technically stays within step and token limits but takes an unreasonably long time to complete still represents a poor outcome for both cost predictability and user experience in latency-sensitive contexts.
Combine these layered guardrails, step count, token budget, stuck-loop detection, and wall-clock timeout, so that whichever limit is triggered first terminates the task cleanly, and log which specific guardrail triggered on each terminated task to build visibility into which failure mode is actually most common in your production traffic.
Key takeaways
- Set a maximum step count based on the observed distribution of successfully completed tasks.
- Pair step limits with a cumulative token budget, since per-step cost can vary widely.
- Implement stuck-loop detection to terminate early on repeated or non-progressing actions.
- Apply a wall-clock timeout independent of step and token limits for latency-sensitive contexts.
- Log which specific guardrail triggers on each terminated task to identify your most common failure mode.
Bottom line
Layered guardrails, step limits, token budgets, stuck-loop detection, and timeouts together, are what turn an agent's open-ended autonomy into a bounded, production-safe system. None of these guardrails need to be sophisticated to be effective; the key is having all of them in place rather than relying on any single limit alone.