Runaway Agents, Tool Loops, and Budget Overruns: The Incidents Cycles Is Designed to Prevent

Most infrastructure gets adopted after a painful incident.

Not because the idea was unclear.
Because the failure became expensive enough to matter.

Cycles exists for a specific class of incidents:

• runaway agent execution
• recursive tool loops
• retry storms that multiply spend
• background workflows that drift out of bounds
• tenant over-consumption
• side-effecting systems that keep acting longer than intended

These are not hypothetical problems.

They are what happens when autonomous systems are allowed to keep executing without a clear budget authority.

The common pattern behind these incidents

The root problem is usually not one bad model call.

It is uncontrolled accumulation over time.

A system begins with a reasonable action:

• answer a question
• call a model
• retrieve context
• invoke a tool
• retry a failed step
• continue a background workflow

Then one of several things happens:

• it loops
• it retries repeatedly
• it fans out across tools
• it recurses into additional steps
• it continues after the initiating request is gone
• it stays within request limits but exceeds intended total spend

The incident is rarely obvious at the start.

It becomes obvious only after enough exposure has already accumulated.

That is exactly the gap Cycles is designed to close.

Incident type 1: Runaway agent loops

This is one of the clearest failure modes.

An agent is given a task.
It plans.
It reasons.
It calls a tool.
It reevaluates.
It calls again.
Then again.

Each step may look individually valid.

The problem is the total chain.

The agent may stay functionally “alive” long after it has stopped being useful.

What makes this dangerous

• cost grows with each iteration
• the loop may not violate request-per-second limits
• the workflow may appear healthy from a latency perspective
• the failure is often logical, not infrastructural

By the time someone notices, the system has already consumed real budget.

What Cycles changes

Cycles introduces a run-level budget boundary.

That means a run can be given a bounded execution envelope before it starts.

If the run exhausts that envelope, the system can:

• stop
• degrade
• switch to a smaller model
• disable expensive tools
• exit gracefully

Instead of hoping the loop ends on its own, the platform enforces that it cannot continue indefinitely.

Incident type 2: Recursive tool loops

Many agent systems now use tools as part of normal execution.

That is powerful, but it also creates a new failure surface.

A tool call may trigger:

• another model step
• another tool selection
• another retrieval pass
• another external API call

Sometimes this is intentional.
Sometimes it becomes accidental recursion.

A common failure shape

An agent tries to achieve a task by alternating between planning and tool invocation.

The tool result is incomplete or ambiguous.
The model decides to try again.
The same or similar tool path repeats.

This may not look like a classic software infinite loop.
It may look like a sequence of plausible, locally valid decisions.

But operationally, the effect is similar.

What Cycles changes

Cycles allows tool-calling paths to operate inside bounded budgets.

That means expensive or risky tools do not merely rely on agent judgment. They also rely on budget availability.

If a recursive chain keeps consuming exposure, it can hit a hard ceiling before becoming an open-ended incident.

Incident type 3: Retry storms that multiply spend

Retries are necessary.

They are also dangerous when execution is expensive.

A transient error occurs.
The system retries.
Then retries again.
Then downstream components retry as well.

Each retry may appear operationally justified.

But collectively they can produce:

• duplicate model usage
• repeated external API charges
• repeated side effects
• budget consumption far above the original intent

Why this is tricky

Retry behavior often emerges across layers:

• client retries
• worker retries
• message redelivery
• provider-level transient failures
• workflow-level retry policies

A team may believe it has only one retry path when in reality several are active at once.

What Cycles changes

Cycles is built around reservation, commit, release, and retry-safe lifecycle handling.

That creates a stronger basis for budget control under repeated attempts.

Instead of treating every retry as disconnected spend, the runtime can reason about bounded execution more intentionally.

The goal is not to remove retries.

The goal is to prevent retries from silently becoming budget explosions.

Incident type 4: Background workflows that drift out of bounds

Many systems start with synchronous user-triggered actions.

Then they evolve.

Work moves into background jobs, queue consumers, autonomous workflows, scheduled agents, and multi-step processing pipelines.

At that point, the original user request may be gone while the system is still acting.

Why this matters

Once work becomes long-lived or asynchronous, teams lose the natural boundary of a single request-response cycle.

That means the system may continue to:

• call models
• invoke tools
• write state
• trigger follow-up jobs
• accumulate cost

without a clean execution envelope.

What Cycles changes

Cycles gives background execution a budget boundary.

A workflow or run can reserve bounded room to act before it continues, even if it is no longer tied to an active foreground request.

That makes asynchronous autonomy more governable.

Incident type 5: Tenant over-consumption

In multi-tenant systems, not every incident is caused by a single bad run.

Sometimes the issue is aggregate consumption.

One tenant may:

• use a feature far more heavily than expected
• trigger many concurrent runs
• repeatedly invoke expensive workflows
• consume shared capacity beyond its intended share

Without a strong budget model, teams often discover this through:

• a provider bill
• degraded shared performance
• surprise usage spikes
• unhappy other tenants

Why rate limits are not enough

A tenant can remain within request velocity constraints and still exceed intended total exposure over time.

This is especially true for long-running or autonomous workloads.

What Cycles changes

Cycles supports tenant-level budgets as part of hierarchical governance.

That means every action can be checked not only against local run or workflow limits, but also against broader tenant boundaries.

This turns tenant isolation from post-hoc analytics into pre-execution control.

Incident type 6: Side-effecting systems that continue too long

Some autonomous systems do more than think.

They act.

They may:

• send emails
• create tickets
• write to databases
• trigger payments
• call downstream business systems
• initiate deployments

At that point, the incident is not just cloud spend.
It is operational side effect.

Why this is more serious

A long-running reasoning loop is costly.
A long-running side-effect loop can be destructive.

The platform may need to distinguish between:

• low-risk model inference
• medium-risk retrieval
• high-risk external action

What Cycles changes

Cycles allows these actions to be governed as budgeted exposure, not just as traffic.

That means the system can decide whether an action is still allowed to proceed under the current budget, scope, and policy state.

This is how “autonomous execution” becomes something operators can actually bound.

The operational theme behind all of these incidents

All of these incidents share the same deeper issue:

the system keeps acting after it should have stopped.

Not necessarily because it is malicious.
Not necessarily because it is broken in the classic sense.

But because nothing in the runtime enforces a bounded execution envelope.

That is the problem Cycles is designed to solve.

What teams often use instead

Before adopting a budget authority, teams usually piece together partial controls such as:

• provider dashboards
• usage alerts
• request rate limits
• hardcoded loop counters
• timeout tuning
• kill switches
• tenant usage reports
• manual intervention

These controls are often useful, but fragmented.

They usually fail in one of two ways:

• they react too late
• they are too coarse to map cleanly onto autonomous execution

Cycles is not trying to remove all of these tools.

It is trying to add the missing control layer that turns bounded execution into a runtime property.

What prevention looks like in practice

Cycles does not prevent incidents by “observing harder.”

It prevents them by changing the execution model.

At a high level:

1. an action declares intended exposure
2. budget is reserved before work proceeds
3. execution happens within that bounded envelope
4. actual usage is committed
5. unused remainder is released
6. further work is denied or degraded when budgets are exhausted

That changes the system from:

keep going until something external notices

to:

continue only while bounded execution is still authorized

That is a different operating model.

See it in action: the runaway agent demo

The cycles-runaway-demo repository demonstrates exactly this failure mode with a runnable example.

The scenario: a customer support bot drafts a response, evaluates its quality, and refines it in a loop until the quality score exceeds 8.0. The bug is that the quality evaluator never returns above 6.9. Without a budget boundary, the agent loops indefinitely.

The demo runs the same agent twice:

1. Without Cycles — the agent runs for 30 seconds, making ~600 calls and spending ~$6.00 before being auto-terminated. In production, there would be no auto-termination.
2. With Cycles (budget: $1.00) — the agent hits the budget ceiling after ~100 calls. The Cycles server returns 409 BUDGET_EXCEEDED, the @cycles decorator raises BudgetExceededError, and the agent stops cleanly.

The entire integration diff between the unguarded and guarded versions is three @cycles decorators and one except BudgetExceededError block.

To run it locally:

git clone https://github.com/runcycles/cycles-runaway-demo
cd cycles-runaway-demo
python3 -m venv .venv && source .venv/bin/activate
pip install -r agent/requirements.txt
./demo.sh

Why this matters now

As AI systems become more autonomous, incidents are shifting.

The old failure model was often:

• one bad request
• one high-latency call
• one failed dependency

The new failure model is often:

• too much valid work
• repeated steps that stay locally reasonable
• distributed retries
• side effects that accumulate
• autonomy that continues past useful bounds

This is exactly why autonomous software needs more than traffic shaping and dashboards.

It needs budget authority.

Summary

Cycles is designed to prevent incidents such as:

• runaway agent loops
• recursive tool chains
• retry-driven budget explosions
• background workflows drifting out of bounds
• tenant over-consumption
• excessive or repeated side effects

These incidents all come from the same core gap:

the absence of a runtime control layer that can bound autonomous execution before cost and side effects accumulate too far.

That is what Cycles provides.

It gives teams a way to move from:

• hoping systems stay within acceptable bounds

to:

• enforcing bounded execution intentionally

Next steps

To explore the Cycles stack:

• Try the Runaway Agent Demo — see the failure mode and the fix in action
• Read the Cycles Protocol
• Run the Cycles Server
• Manage budgets with Cycles Admin
• Integrate with Python using the Python Client
• Integrate with TypeScript using the TypeScript Client
• Integrate with Spring AI using the Spring Client