Runtime Controls for AI Agents: Loops, Cost Caps, Deadlocks and Audit Logs

AI Agents in Production | By the Zylen Solutions Team | 4-minute read

When an agent fails in a demo, everyone sees it. It throws an error, the screen goes red, someone fixes it. In production, the failures that hurt are quieter. The agent doesn't crash. It keeps running, keeps calling tools and keeps billing, and nobody finds out until the invoice or a customer does.

That's rarely a model problem. A better model still gets stuck when a tool returns something unexpected, or when two agents end up waiting on each other. What's missing is something around the run that notices and stops it: a circuit breaker.

These are the four runtime controls we look for first.

1. Loops: stop it repeating itself

An agent that can't finish a step will often try again with the same input, or plan, fail and re-plan indefinitely. Each attempt looks reasonable on its own. Together they never end.

• Step limit. Give every task a hard maximum number of steps. Start a little above your longest successful run and tighten from there.
• Loop detection. If the agent makes the same tool call with the same arguments several times in a row, stop the run.
• Stop with a summary. When the breaker trips, save where the agent got stuck and hand it to a person, instead of failing silently.

2. Cost caps: give every run a ceiling

Most teams only see AI spend as a monthly total. That makes it impossible to tell one expensive run from a thousand normal ones, and it means a single bad run can spend freely until someone looks.

• A budget per run. Set a token and dollar cap on every run, not just a monthly one.
• Warn, then stop. Alert when a run gets close to its cap, and stop it when it reaches it.
• Make it visible. Show spend per run on a dashboard, so outliers stand out the same day.

3. Deadlocks: put a clock on every wait

Multi-agent setups add a quieter failure. Agent A waits for agent B's output while B waits for A's approval. Nothing errors, so nothing alerts. The run just sits there, sometimes holding resources the whole time.

• Timeouts on every wait and handoff. No step should be able to wait forever.
• A no-progress check. Something outside the agents should flag runs that haven't moved forward in a set time.
• Escalation. When a timeout fires, the run goes to a person with the context, not into a retry loop.

4. Audit logs: be able to say what happened

When something does go wrong, the first question is "what did it do?" If the logs only show the final answer, nobody can say.

• Log every step. Prompts, tool calls, costs, decisions and approvals, not just the output.
• One run ID. Tie every step and every action back to the run that caused it.
• Replay. Make it possible to walk through any run step by step, especially the ones the breaker stopped.

Put them in one place

These controls work best together, in a run controller that sits around the agent rather than inside the model. Every task arrives with a step budget, a cost budget and a deadline. The controller watches each step, trips the breaker when a limit is hit, saves a summary, alerts a person and writes everything to the audit log under one run ID.

The reference architecture: the breaker sits around the run, not inside the model

1. Task: arrives with a step budget, a cost budget and a deadline.
2. Run controller: watches every step and trips the breaker. It holds the step limit, the loop detector, the cost meter and the timeouts.
3. Agent and tools: the agent plans, calls tools and checks its own work, all inside the controller.
4. Result: accepted, or sent back with a reason.

When a limit is hit:

• Breaker trips: the run stops and saves a summary of where it got stuck.
• A person: gets the alert and a link to replay the run.

Underneath it all, the audit log records every step, tool call, cost and stop under one run ID.

Keeping the controls outside the agent has a practical benefit: you can change models, prompts or tools without losing the guardrails.

Where to start

You don't need all four on day one. Start by measuring: how many steps your runs take, what each run costs and how long it runs. The outliers show you which control to add first. Then add one control at a time and check that accepted results don't drop.

How we approach it at Zylen

Zylen is an AI optimization partner. We work inside the AI systems companies already run. Our ten-day AI Optimization Audit meters what every AI workload costs and ranks what to fix. Controls like these go in during the sprint, behind evaluations, with the before-and-after on record.

Find the runs nobody is watching: start the AI Optimization Audit