Lesson 35 — bounded agents and their traces. The trace is the artifact. Without it, you are running a black box you cannot review. With it, the agent is just another auditable component.
The agent that escaped its budget
An agent is given a research task. It is allowed to call a web-search tool. It calls the tool. The first result triggers a new search. The new search triggers another. Twelve searches later, the agent has wandered into an unrelated topic, accumulated four hundred dollars of API cost, and produced a summary of something the user did not ask about.
An unbounded agent is not an engineering pattern. It is a hope. A bounded agent has explicit budgets: maximum steps, maximum tool calls, maximum tokens, maximum cost. The trace records what was spent on what. The trace is what makes the system reviewable.
The rule: Agents in production are bounded agents. The bound is the contract. The trace is the evidence the contract was honoured.
The bounds that matter
- Step count — maximum number of LLM-to-tool turns. The blast-radius cap.
- Tool call count — separate cap per tool. Prevents runaway loops on a single API.
- Token budget — total tokens across the trace. The cost cap.
- Wall-clock budget — maximum time. Protects users from indefinite waits.
- Escalation triggers — conditions that force handoff to a human or to a fallback workflow.
The trace records each step: the input, the LLM’s plan, the tool call, the tool result, the LLM’s next decision. Every step has a cost, a latency, and a decision. The trace is replayable.
Try it yourself
The trace playground below lets you run a bounded agent on a sample task. Set the bounds, watch the agent execute, inspect each step. Try a too-tight bound; watch the agent escalate. Try a too-loose bound; watch the cost climb.
Bounded agent trace playground
Step-by-step replay of three bounded-agent scenarios on a Maltese-grant-eligibility workload. Every step shows the planner / tool / schema-validator / executor / verifier / approval-gate / retry-counter / cost-meter state — the bounded primitives the doc names as non-optional.
Workload: Question: 'Is this Maltese SME eligible for the Digitalise Your SME grant?' — agent has access to: lookup_company_registry(vat_no), check_employee_count(company_id), check_sector_eligibility(naics), check_project_budget(amount). Bounded by: max_retries=3, max_cost=€0.05, approval_gate on any €>€100k commitment recommendation.
-
# - Pick a scenario and press ▶ to play the agent’s trace.
What you just saw
The right bounds are workload-specific. A research task may need 20 steps; a customer service task should not exceed 5. Setting the bounds too loose makes the system expensive and unreviewable. Setting them too tight produces too many escalations and shifts the operational burden to humans.
The trace also doubles as the explanation surface. For Article 86 explanation rights, the trace is the answer to “why did the system reach this conclusion.” The trace is verbose; a summarised explanation is the user-facing version. Both should exist.
Three architect-grade arguments
- Bounds are the contract. Surface them in the API. Surface them in the documentation. Surface them to the user.
- The trace is the deliverable. Without it, the agent is opaque. With it, the agent is a reviewable component like any other.
- Escalations are a feature. The agent that gives up at the bound is preferable to the agent that bulldozes past it.
Next lesson: the failure mode heatmap for agents — what goes wrong, where, and how often.