Operating LLM agents in production: budgets, gates and escalation

A chatbot that answers wrongly costs you an apology. An agent that acts wrongly costs you a refund, a deleted record or a compliance incident. The moment an LLM gets tools - lookups, writes, payments, deploys - the operational question changes from “is the answer right?” to “is the action safe, bounded and reversible?”

This guide covers the operations layer that makes agents run-able: what to scope, what to gate, what to budget and what to trace.

The two questions#

Prototype: “Did the agent complete the task I gave it?” Production: “Can it complete every task within a budget, refuse the ones it shouldn’t do, and hand off cleanly when it’s stuck?”

A demo agent is judged on its best run. A production agent is judged on its worst one.

What breaks in production#

• Wrong action, not wrong answer. An erroneous refund or a bad write is a side effect you cannot un-generate. Text mistakes are recoverable; tool mistakes often are not.
• Injection becomes execution. With a chatbot, prompt injection produces embarrassing text. With an agent, the injected instruction can call your tools - the untrusted input now has hands too.
• Runaway loops. The agent retries, re-plans, re-reads, and burns an hour of tokens on a task worth a cent. Without caps, one stuck conversation is a budget event.
• Undebuggable failures. A ten-step run failed. Which step? With only request-level logging, a multi-step agent is a black box - you see the task and the wreckage, nothing between.
• No way out. The agent is stuck, the user is angry, and there is no designed path to a human - so the agent improvises, which is the worst of all outcomes.

The operating framework#

Scope tools to least privilege#

Every tool is attack surface and blast radius. Give the agent the narrowest tool that does the job - lookup_order(id), not run_sql(query) - and validate both inputs and outputs against strict schemas. A tool the agent does not have is a failure mode you do not operate.

Gate irreversible actions#

Split actions by reversibility. Reads and drafts flow freely; refunds, account changes, sends and deletes go through an approval gate - a human sign-off or a hard policy check between the agent’s decision and the side effect:

{
  "tool": "issue_refund",
  "input": { "order_id": "ord_812", "amount_eur": 84.5 },
  "policy": "requires_approval",
  "approved_by": null,
  "state": "pending_approval"
}

The gate is a designed step, not an afterthought - the same principle as the Governance layer’s human-in-the-loop, applied per action instead of per use case.

Budget everything the loop can spend#

An agent loop spends four currencies: steps, tokens, money and wall-clock time. Cap all four per conversation, and make the cap visible to the agent so it can prioritise and wrap up instead of being cut off mid-action:

{
  "conversation_id": "c_2231",
  "budget": { "max_steps": 12, "max_tokens": 60000, "max_cost_usd": 0.50, "max_seconds": 120 },
  "spent":  { "steps": 4, "tokens": 18200, "cost_usd": 0.11, "seconds": 34 }
}

Exhausted budget is a defined outcome, not an error: summarise progress, save state, escalate.

Trace every step, not every request#

Request-level logs are useless for a ten-step run. Instrument per-step spans - plan, each tool call with inputs/outputs, each model hop - under one trace ID, the agent-shaped extension of what to log in an LLM trace. OpenTelemetry’s GenAI conventions (cited below) give you a vendor-neutral schema for exactly this.

Design the way out#

Define, in advance, the conditions that end a run: low confidence, exhausted budget, a denied approval, an out-of-scope request. Each maps to a handoff

• to a human queue with the trace attached, so the human starts with context instead of archaeology. Resolution rate matters less than this number: how often does the agent correctly conclude it should stop?

Close the loop with evals#

Every completed run is a labelled example: task in, actions taken, outcome. Route the failures - wrong tool, wasted steps, missed escalation - back into your eval set, and add the worst ones as regression cases. Agent evals judge trajectories, not just final answers: right tool, right arguments, sane step count.

Minimal vs mature#

Aspect	Minimal	Production-grade
Tools	Read-only lookups	Scoped actions, schema-validated I/O
Irreversible actions	Blocked entirely	Approval gate + audit trail
Budgets	None	Steps, tokens, cost and time caps
Tracing	Request-level logs	Per-step spans under one trace ID
Escalation	The agent improvises	Designed handoff with context

Where this lives in a real system#

The customer support agent blueprint is this article as an architecture diagram - scoped tools, approval gate, human escalation and the trace schema to copy. The Security layer covers the injection-to-execution risk in depth, and the agent items in the Production Checklist are the bar to clear before your agent gets its hands on anything real.