Cost budgets and kill switches are requirements

Ask an engineer what an agent should optimize and you will hear accuracy. Ask finance and you will hear the monthly invoice. LangChain's State of Agent Engineering survey puts quality first and latency second among barriers to production. Cost is the quieter risk, and it tends to arrive all at once: a retry loop, a context window that grows every turn, or an orchestrator that spawns twenty workers when two would do.

The fix is not heroic monitoring. It is writing spending limits and a stop mechanism into the requirements before the first release, with the same weight as functional requirements. Below is language you can paste into a spec and adapt.

Budget requirements

B1. Per-run budget. Each run has a maximum spend, expressed in tokens or currency and configured per task type. When a run reaches it, the run makes no further model or tool calls.

B2. Graceful stop. When a run hits its budget, the system saves state, tells the user what was completed and what was not, and leaves no half-finished write. "Stopped to stay within the cost limit; here is the draft so far" is acceptable. Silently truncating an email mid-sentence is not.

B3. Per-tenant and per-day ceilings. Aggregate spend is capped per customer or team per day, with alerts at 50%, 80%, and 100%. Behavior at 100% is defined in advance: degrade to a cheaper path, queue requests, or decline with an explanation.

B4. Fan-out limits. Orchestrators may spawn at most a fixed number of child agents per run, and each child draws from the parent's budget rather than receiving a fresh one.

B5. Cost in the trace. Every model call and tool call records its token count and estimated cost, so the price of any run can be explained after the fact.

Kill-switch requirements

K1. Granularity. The switch can disable the whole agent, a single tool, or a single tenant. Turning off a misbehaving email tool should not take down the entire product.

K2. Speed. Activation takes effect within a stated time, for example under one minute, and covers both new runs and tool calls already in progress.

K3. No deploy. The switch is a configuration flag or admin control, not a code change. Whoever is on call at 3 a.m. must be able to use it without a release.

K4. Authority. The runbook names who may pull it. The list should include on-call engineering and at least one owner outside engineering.

K5. Rehearsal. The switch is exercised in staging on a schedule, and the time to full stop is recorded. A kill switch nobody has pulled is a hypothesis.

Choosing the first numbers

Teams often stall on what the limits should be. A practical starting point: run your golden test set, record the cost of each successful run per task type, and set the per-run budget at two to three times the slow-tail figure. That leaves headroom for legitimate hard cases while still catching a runaway loop. Set the daily ceiling from expected volume times typical cost, plus a margin you can explain to finance. Then revisit both after the first month of real traffic, using the runs that hit the limit as evidence for raising or lowering it.

Levers that lower cost without lowering quality

Budgets cap the damage. These reduce the baseline:

• Use workflows where the path is known. Fixed steps avoid exploratory calls the model would otherwise make.
• Shorten trajectories. Fewer steps per task means fewer calls and less accumulated context.
• Trim context. Take reference material out of system prompts and filter tool output to the fields a task needs.
• Cache stable prefixes. Where your provider supports prompt caching, keep instructions and tool definitions stable so they can be reused.
• Route by difficulty. Send classification and extraction hops to a small, fast model, and reserve the largest model for steps that need it.
• Measure cost per successful task. Cost per call can look fine while cost per completed task climbs, because retries and failures hide inside it.

Talking about it with leadership

Budgets and kill switches are sometimes framed as engineering caution. A better frame is customer trust and operational ownership. A system that cannot be stopped is a system nobody truly owns. A system whose cost cannot be explained per run is one the finance team will eventually shut down for you.

Three numbers belong in the monthly review: cost per successful task by task type; how many runs hit their budget, and why; and the time to full stop from the latest kill-switch rehearsal.

The version-one test

Before calling anything version one, ask two questions. If this agent loops tonight, what is the most it can spend before something stops it? And who can stop it without a deploy? If either answer is "we're not sure," the release is not ready.

Sources cited

• LangChain, State of Agent Engineering (survey of 1,340 respondents, November 18–December 2, 2025; report published February 2026)