109 — Agent Budgeting & Admission Control

Concept overview

Agent budgeting constrains the total resources a logical task may consume, including retries, parallel branches, and delegated subtasks. Admission control decides whether a new task can start under current capacity and policy. Together they prevent an apparently small request from expanding into unbounded model calls or overwhelming a dependent service.

A token rate limit alone does not govern a multi-step workflow. Track reserved and spent budget across the task tree, and distinguish capacity limits from monetary accounting. Estimates guide admission; runtime enforcement and reconciliation handle estimation error. When a budget is exhausted, return a useful partial result or explicit handoff rather than hiding unfinished work.

Why it matters in production

Proof of concept

A proof of concept records tokens, tool calls, and elapsed time per task to identify expansion patterns before defining enforceable budgets.

Production

Production reserves capacity before dispatch, enforces per-task and per-tenant limits, bounds retries, and defines queueing, cancellation, and partial-result behavior.

Enterprise scale

Enterprise scale adds weighted fairness, priority classes, regional capacity, adaptive estimates, budget transfer rules, and reconciliation for delayed usage receipts.

Architecture components

Admission controller

Checks tenant policy, priority, available capacity, and estimated task cost before accepting work.

Budget ledger

Atomically tracks reservations, consumption, releases, and parent-child allocations across concurrent branches.

Execution governor

Enforces time, iteration, tool-call, and token limits during runtime rather than relying on model cooperation.

Priority queue

Schedules admitted tasks with fairness and explicit expiry under constrained capacity.

Usage reconciler

Matches estimated reservations with observed provider and tool usage, including late or failed calls.

The architecture, mapped

flowchart LR
    R["Incoming task"] --> A["Admission and fairness policy"]
    A --> Q["Queue or explicit rejection"]
    A --> B["Atomic budget reservation"]
    B --> W1["Bounded specialist one"]
    B --> W2["Bounded specialist two"]
    W1 --> L["Usage ledger and hard limits"]
    W2 --> L
    L --> P["Complete or labeled partial result"]
    P --> C["Reconcile and release capacity"]

Runtime flow

1. 1

   Estimate bounded demand

   Classify the task and calculate a conservative reservation from allowed steps, model choices, and tool costs.

2. 2

   Apply admission policy

   Check tenant quota, priority, downstream concurrency, and regional capacity; queue or reject with a clear retry contract if unavailable.

3. 3

   Reserve atomically

   Create a task budget and allocate child limits without allowing parallel workers to overspend the same remaining balance.

4. 4

   Enforce during execution

   Charge every attempt, including retries and failed calls, and stop scheduling new work when any hard limit is reached.

5. 5

   Degrade intentionally

   Choose an approved lower-cost path, return a labeled partial result, or hand off unresolved work without silently weakening required checks.

6. 6

   Reconcile and release

   Replace estimates with observed usage, release unused reservations, and retain a cost and completion explanation for the task owner.

Alarm-storm investigation admission

Telecommunications · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

Illustrative architecture: A network incident creates thousands of related alarms and could trigger one investigation per event.

The problem

Unbounded agent fan-out consumes model capacity and overloads diagnostic APIs precisely when operators need them most.

Agent requirement

Admit incident-level work fairly, cap diagnostic load, and reserve capacity for higher-priority operational requests.

Architecture

An admission controller groups related signals, reserves one investigation budget, and allocates bounded specialist branches against a shared ledger.

Runtime

• Group incident signals
• estimate investigation budget
• admit by priority
• allocate branch limits
• stop redundant diagnostics
• return evidence with unresolved items

Failure scenario

A branch reaches its tool-call cap while evidence remains incomplete; the workflow returns the completed findings and routes unresolved checks to the operator.

Operational impact

Measure cost per accepted investigation, queue delay, denied work, fairness by tenant, budget overruns, and task quality under constrained capacity.

Architecture tradeoffs

Failure scenarios & recovery

Common architecture mistakes

Counting only successful model responses.

Account for failed attempts, retries, tools, embeddings, and cancelled work with observed cost.

Letting a specialist create unlimited child agents.

Require explicit child reservations drawn from the parent budget.

Dropping verification steps first when money runs low.

Preserve mandatory checks and reduce scope or return a clearly incomplete result.

When to choose this pattern

Choose it when

• Agents can loop, retry, or delegate enough work to make resource use unpredictable.
• Several tenants or priorities share constrained model and tool capacity.
• The product needs an explicit cost and completion contract for each task.

Avoid it when

• A fixed deterministic request has negligible and already bounded resource use.
• Budget policy would silently remove checks required for a valid result.
• The implementation cannot reconcile usage across asynchronous branches and providers.

Architecture checklist

• Define task, tenant, and platform limits for every meaningful resource.
• Reserve parent and child budgets atomically before dispatch.
• Include retries, failures, tools, and delayed receipts in accounting.
• Specify queue fairness, priority, expiry, and rejection behavior.
• Enforce hard limits outside the model and stop new work on exhaustion.
• Design useful partial results and explicit unresolved-work handoffs.
• Test parallel overspend, cancellation charges, and reservation leakage.

Related concepts

• 14 — Token-Aware Routing
• 17 — Agent Lifespan Management
• 33 — Token Rate Limiting
• 46 — Max Iterations Fallback
• 49 — Timeout Policies
• 56 — Load Balancing LLM Requests
• 59 — Cascade Failure Prevention
• 81 — Dynamic Model Routing
• 94 — Token Cost Allocation Tracking

Primary references

• Kubernetes: Resource Quotas
• OpenTelemetry: Traces
• Temporal: Workflow execution