On November 14, 2025, an engineering team at a mid-market SaaS company in Austin shipped two LangChain agents to staging for a 48-hour soak test and went home for the weekend. Eleven days later, on November 25, a finance analyst running the monthly Anthropic invoice reconciliation noticed an unfamiliar line item: $47,312 in Claude Sonnet usage attributed to a service account nobody had budget for. The agents had been running the entire time — each one calling the other in an unbroken loop, generating tool plans, evaluating tool plans, re-generating tool plans, calling Claude Sonnet 4.5 for every cycle. The CloudWatch budget alert at $5,000 had fired on day three. The on-call rotation had silenced it as a known false positive from a previous staging incident. The alert at $10,000 had fired on day five and gone to a Slack channel nobody read on weekends. By day eleven, the cumulative spend was 9.4x the alert threshold and the only thing that stopped the agents was a human noticing a line item in a spreadsheet. This is the canonical cautionary tale of 2026 agent FinOps. The lesson is not "set better alerts." The lesson is that alerts are not enforcement. This article builds the three-layer enforcement model — per-call cap, per-run cap, per-day org cap with auto-pause — and walks through the 2026 enforcement primitives (Portal26 Agentic Token Controls, swarm budgets, circuit breakers) that turn this from a known pattern into a solved problem.

The $47K LangChain Incident: The Full Timeline

Let's walk through the eleven days because the failure mode is instructive at every step.

Day 0 (Friday, November 14). Engineering deploys two LangChain agents to staging — a "planner" and an "executor" — for a soak test. Architecture: planner generates a multi-step plan, sends it to executor; executor attempts step 1, generates a status report, sends it back to planner; planner evaluates and generates revised plan. Loop is intended to terminate when executor reports "complete." A bug in the executor's status-formatting prompt causes it to always emit a status that the planner classifies as "needs revision." Loop never terminates.

Day 1. Agents run overnight. Cumulative spend hits $1,400. Below all alert thresholds.

Day 3 (Monday). CloudWatch billing alert at $5,000 fires. Goes to PagerDuty. On-call engineer acknowledges and silences — "staging billing alerts have been noisy since last month's eval cluster; will triage in standup." Loop continues. Standup does not happen because the lead engineer is at a customer site.

Day 5. Second alert at $10,000 fires. Routes to a Slack channel called #ai-billing-alerts that was created six months ago and has 14 members. Saturday morning. Nobody is paying attention to a low-priority Slack channel on a weekend.

Day 7. Anthropic's automated daily usage email shows a 4,000% spike in Sonnet calls on this account. Goes to the same Slack channel. No human reads it.

Day 9. The two agents have now made 2.3 million Claude Sonnet calls between them, generating an estimated 18 billion tokens. The staging cluster is running fine — there is no infrastructure pressure that would create a normal monitoring signal. The only signal is the bill.

Day 11. A finance analyst preparing the monthly Anthropic invoice reconciliation flags an unfamiliar service account with $47K of usage. Emails engineering. Engineering scrambles, finds the running agents, kills the staging cluster. Total spend: $47,312.

Post-mortem week. Anthropic, contacted with documentation, provides a one-time goodwill credit of $20K — generous but not policy. Net loss: $27,312 and significant CFO trust.

Why Alerts Failed Five Times

Five separate alerting layers fired during the incident. None stopped the agents. Understanding why is the foundation for understanding what enforcement actually means.

1. The $5K CloudWatch alert was silenced. Standard SRE practice — noisy alert gets silenced pending triage. The triage never happened because the silencing routes to a backlog, not a stop.
2. The $10K Slack alert went to a channel nobody read. Notification fatigue. The channel was created with good intent, accumulated noise, lost human attention. The alert was technically delivered but functionally invisible.
3. The Anthropic daily usage email landed in a shared inbox. Distribution-list email arriving in an account that was never anyone's primary mailbox.
4. The on-call rotation acknowledged but did not investigate. "I'll handle it after standup" is not a halt action. It is a deferral.
5. The monthly billing reconciliation only happens monthly. By design. Eleven days is more than a third of a month.

Every layer was monitoring, not enforcing. Monitoring tells a human. Humans were the failure mode in this incident — overloaded, miscalibrated to noise, on weekends, at customer sites. Any system whose stop mechanism requires a human to be in the right place at the right time will fail this way. The only question is when.

The $47K LangChain incident did not happen because the alerts didn't fire. It happened because alerts ask permission of a human to stop something. Enforcement does not ask. Enforcement stops.

The Three Enforcement Layers

A production-grade agent FinOps regime has three independent enforcement layers. Each operates without human consent. Each stops the agent if its threshold is crossed. They are belt, suspenders, and emergency brake — redundant by design because any single layer can be circumvented or misconfigured.

Layer 1: Per-call token cap

The smallest unit. Every individual model invocation has a hard ceiling on tokens. If the agent constructs a prompt that exceeds the per-call cap, the call is rejected at the gateway before it reaches the model vendor.

• Where it lives: The proxy layer (Helicone, LiteLLM, Portkey, Portal26 Agentic Token Controls).
• Typical value: 50K input tokens for most agents, 200K for long-context use cases.
• What it catches: Runaway context bloat, prompt injection trying to inflate token usage, accidental dump of large documents into a prompt.
• What it does not catch: An agent making thousands of small calls (each within the cap) in a loop. That is what Layer 2 is for.

Layer 2: Per-run token cap

A single agent execution — from invocation to completion — has a token budget. The gateway tracks cumulative spend across all calls within that run (identified by a trace ID or session ID) and cuts the agent off when the run cap is hit.

• Where it lives: Gateway with session-aware accounting (Portal26 Agentic Token Controls is the named primitive; LiteLLM and Helicone are catching up).
• Typical value: 200K-500K tokens for a customer service run, 2M-5M tokens for a research-agent run. Set based on observed P95 of legitimate runs * 2x.
• What it catches: A planner-executor loop. A research agent that keeps fetching more documents. An agent that gets stuck in a retry cycle.
• What it does not catch: A swarm of independent agents each operating within their per-run cap. That is what Layer 3 is for.

Layer 3: Per-day org cap with auto-pause

The total token spend across all agents on the account in a 24-hour window has a hard ceiling. Crossing the ceiling auto-pauses all agents — not alerts, pauses. Human intervention required to resume.

• Where it lives: Org-level FinOps controller (Portal26, OpenMeter, or custom — vendor-native consoles do not do this yet at the org level reliably).
• Typical value: 1.5-3x the historical daily P95 across all production agents. For the Austin team, this should have been about $3,000/day.
• What it catches: Multiple agents misbehaving simultaneously. New agents accidentally deployed to production. Compromised credentials being used to drive API calls. The $47K loop.
• How it auto-pauses: Gateway returns 429 / "service paused" on all agent requests until human override. PagerDuty-style escalation to the FinOps owner. Override requires authentication and audit logging.

Three layers, three independent enforcement points. The $47K incident would have hit Layer 2 inside the first hour and Layer 3 inside the first 12 hours. Neither layer existed at the Austin team. Both layers cost about a day of engineering effort to set up.

Portal26 Agentic Token Controls: The 2026 Enforcement Primitive

By 2026 the agent-gateway market has consolidated around a small number of vendors offering token-control primitives explicitly designed for agentic workloads. Portal26 is the most prominent, but LiteLLM, Helicone, and Portkey have shipped or are shipping comparable features. The key primitives the strategist asks for by name.

Token quotas, scoped

Quotas at per-user, per-agent, per-team, per-org, and per-day granularity, set independently. An agent's API key has a per-call cap, a per-run cap, a per-hour cap, and a per-day cap. Hitting any of them throws a 429 with a quota-exhausted reason code.

Swarm budgets

Multi-agent systems where N agents call each other are bounded as a swarm — a single budget pool for the whole orchestrator session. Without swarm budgeting, each agent in the swarm sees its own per-run cap and the swarm collectively can spend N x cap. Swarm budgeting binds them together. Critical for orchestrator-worker patterns (LangGraph, CrewAI, AutoGen) where the worker count is dynamic.

Circuit breakers

A circuit breaker trips when a defined rate condition is met — e.g., "if any agent makes more than 200 calls in 5 minutes, pause that agent" or "if total org spend rate exceeds $X/minute, pause all agents." Unlike thresholds, circuit breakers react to derivatives (rate of change) not absolute levels. They catch the runaway loop in minutes, not hours.

Resume policy

Paused agents do not auto-resume. Resumption requires a human override authenticated through SSO, audit-logged with reason code, and rate-limited (cannot resume more than N times per day without escalation). This is the layer that prevents the on-call engineer from re-enabling a paused agent without thinking.

Portal26, LiteLLM Enterprise, and Helicone Pro all sell variants of these primitives. The strategist's job is to demand them explicitly in any gateway evaluation. "Do you support per-run token cap with auto-pause and human-override resume?" is the qualifying question. A "we have budget alerts" answer is a disqualification.

Why Vendor-Native Budgets Are Not Enough

"Doesn't OpenAI / Anthropic / Google offer billing limits?" is the question. The answer is "yes, and they are insufficient for agent workloads." Three reasons.

First, vendor-native limits are billing-day boundary based. Hit your $10K daily limit at 2pm? You're done for that calendar day in their time zone. Tomorrow you reset. An agent loop that runs for 11 days will trigger the limit 11 times and continue burning $10K/day, every day, because each day's limit resets. The Austin team's $47K spend would have been distributed across multiple billing days under any vendor-native cap — and the vendor would have happily collected the next day's $10K each time the previous limit reset.

Second, vendor-native limits are per-API-key. A team with 4 API keys (one per environment, one per service account) has 4 independent limits. The runaway agent in staging blew through staging's limit and the team's autoscaling provisioned a new staging key to keep tests running. The new key got its own fresh limit.

Third, vendor-native limits are alerting, not enforcing. They notify but typically do not hard-cap. OpenAI's "usage limits" page describes a soft limit that triggers email notification and a hard limit that rejects requests — but the hard limit can be silently raised by the account admin without any audit trail or approval flow. An incident-mode engineer trying to "unblock production" will raise the hard limit at 3am and forget.

Vendor-native limits are good as the outermost safety net. They are not the FinOps regime. The FinOps regime is the gateway layer, owned by you, configured by you, audit-logged by you.

The Cost of the Three Layers: Honest Math

How much does it cost to install three enforcement layers? Honest numbers.

• Gateway/proxy with token-control features: $400-$2,500/month at moderate scale (Portal26, LiteLLM Enterprise, Helicone Pro). Some teams already have this; many do not.
• Engineering setup time: 5-10 days to integrate the gateway, set per-call/per-run/per-day caps, wire auto-pause to incident response, test the resumption flow. $6K-$12K loaded cost.
• Ongoing tuning: 1-2 days/quarter to revisit caps as workloads grow, tune circuit breaker thresholds, review override audit log. $3K-$8K/year.
• One-time cap-tuning false positives: Plan for 2-4 incidents in the first 60 days where the cap triggers on a legitimate workload, requiring tuning. Cost in lost productivity: ~$10K-$20K one-time.

Total year-1 cost of installing enforcement: roughly $25K-$50K depending on starting state. The $47K incident — one event — paid for it 2x over. The math is easy.

The Circuit Breaker Philosophy

The mental model that distinguishes alerting from enforcement: an electrical circuit breaker does not text the homeowner when current spikes. It trips. The lights go off. The homeowner walks to the panel and re-engages the breaker manually after diagnosing what tripped it. No alert. No human-in-the-loop pre-trip. The breaker's whole purpose is to stop bad things from happening when no human is available to make a judgment.

Agent FinOps needs the same model. The per-run cap is a circuit breaker. The per-day org cap is a master breaker. They trip on threshold or rate. They require human action to re-engage. The human's job is to diagnose why the breaker tripped — was it legitimate growth (raise the cap) or an actual loop (kill the agent and post-mortem). The human's job is not to authorize each call.

Teams that try to bolt human approval onto every cap exceeded miss the point. Approval queues become the bottleneck. Bottlenecks get bypassed. Bypasses defeat the cap. The cap has to be self-enforcing or it is not a cap.

Swarm Budgets: The Multi-Agent Edge Case

The Austin incident involved two agents, but the swarm pattern is becoming common as orchestrator-worker architectures (LangGraph, CrewAI, AutoGen) ship more agents per request. A research swarm might spawn 8-15 worker agents, each operating within their per-run cap. If each worker has a $5 cap, the swarm collectively can spend $75 on a single user request that was meant to cost $4. Multiplied across 10K requests/day: $750K/day swarm overspend versus expected.

Swarm budgeting solves this by binding the workers to a shared session budget. The orchestrator declares a swarm budget at session start ($8, say). Each worker spawned within that session draws from the shared pool. When the pool is exhausted, no new workers can spawn and existing workers are gracefully terminated.

The technical implementation: gateway tracks a session-level budget keyed on a swarm-session-id. Each call deducts from the budget. Calls beyond the budget are rejected. Portal26, LiteLLM 2.0, and Helicone Enterprise all support this primitive in 2026; many self-built gateways do not. A strategist whose org is running orchestrator-worker patterns without swarm budgets has a $47K incident waiting to happen — bigger than the Austin one because the swarm dynamics are nonlinear.

Incident Response When a Breaker Trips

Once the three-layer regime is installed, breakers will trip. The strategist needs an incident response playbook for the trip itself. Five steps.

1. Verify the trip was real. Pull the trace. What agent? What run? What was the cumulative spend? Did it cross the cap or hit a circuit breaker rate condition?
2. Decide: legitimate growth or actual incident. If the agent is processing a legitimate large workload (a research query with deep document retrieval), the cap may be undersized. If the agent is in a loop or doing something unintended, it is an incident.
3. If incident: kill, don't resume. Kill the agent. Capture the trace. Open a post-mortem ticket. Do not re-enable the agent until root cause is understood.
4. If legitimate growth: raise the cap with approval. Update the cap with a 1.5-2x buffer, log the change in the audit trail, notify the FinOps owner. The cap should grow with the workload but always have human approval, not silent auto-scaling.
5. Post-incident: review the cap. If a legitimate trip happened, was the cap set right? If an incident trip happened, what caused the loop? The post-mortem updates the cap and the agent both.

The on-call engineer's instinct will be to silence and resume. The strategist's job is to make sure the playbook says investigate and decide. The Austin team's on-call engineer's instinct was correct given their tooling — silencing was the only action available. Build tooling where silencing is not the only action.

The Quarterly FinOps Review for Agents

The strategist publishes a quarterly review of the FinOps regime. The agenda:

• Per-call cap distribution: how many calls hit the cap last quarter? What was the cap value? Was the cap right?
• Per-run cap distribution: how many runs hit the cap? Of those, how many were legitimate (cap raised) vs incidents (post-mortemed)?
• Per-day org cap: did it trip? If yes, what was the cause? Was the cap set correctly?
• Swarm budget exhaustion: which swarms exhausted budget? Was the budget tuned?
• Override audit log: who overrode caps? Why? Was the override appropriate?
• Vendor-native limits: are they configured as outermost net at the right values?
• Spend by agent, by team, by day: trend lines. Anomalies investigated.

The review is 90 minutes quarterly. It is the artifact that demonstrates to the CFO that the FinOps regime is alive, tuned, and trustable. The CFO who sees this quarterly review never has to ask "are we exposed to another $47K incident?" — the review is the answer.

Key Takeaways

• The $47K LangChain incident of November 2025 was not an alerting failure — alerts fired five times. It was an enforcement failure. Alerts ask a human; enforcement stops the agent.
• Production agent FinOps requires three independent enforcement layers: per-call token cap (gateway-level, rejects oversized prompts), per-run token cap (session-aware, catches loops), and per-day org cap with auto-pause (catches swarms and credential abuse).
• Each layer operates without human consent. Crossing the threshold triggers a stop, not a notification. Resuming requires authenticated human override with audit logging.
• Portal26 Agentic Token Controls are the named 2026 enforcement primitive — token quotas at per-user/per-agent/per-team/per-org granularity, swarm budgets binding multi-agent sessions, circuit breakers that react to spend rate not just absolute levels, and human-override resumption.
• Vendor-native billing limits (OpenAI, Anthropic, Google) are the outermost safety net, not the FinOps regime. They reset daily, are per-API-key, and can be silently raised at 3am by an incident-mode engineer. Insufficient for agent workloads.
• Swarm budgets bind multi-agent orchestrator sessions to a shared budget pool. Without them, a 15-worker swarm can spend 15x per-run cap on a single request. Critical for LangGraph, CrewAI, AutoGen patterns.
• The circuit breaker mental model: stop bad things from happening when no human is available to judge. The breaker trips automatically; a human investigates and re-engages. Approval queues are not breakers — they are bottlenecks that get bypassed.
• Cost of installing the three-layer regime: $25K-$50K year 1 (gateway license + 5-10 engineering days + tuning + false-positive incidents). One $47K incident pays for it 2x.
• Incident response playbook when a breaker trips: verify, decide (growth vs incident), kill or raise with approval, post-mortem, tune the cap. Silencing is not an action in the playbook.
• Publish a quarterly FinOps review: cap distributions, override audit log, swarm budget exhaustion, trend lines. The review is the artifact that demonstrates the regime is alive — and the answer when the CFO asks "are we exposed to another $47K incident?"