The Problem: Retrying Until Something Looks Useful

A missing specification section, an unauthorized path, and a temporary service timeout are different failures. Treating all three as 'try again' can waste a budget or pressure the assistant into bypassing policy. Start with explicit error codes and a conservative rule: this baseline stops on the first tool or adapter error and hands over the evidence already collected. It does not repair permissions, guess another specification revision, or run an analysis to replace missing data.

Budget Every Resource That Can Grow

The baseline permits eight chooser calls by default, with a configurable range of one to twelve. Individual tool limits cap returned rows; a result may occupy at most 4096 serialized UTF-8 bytes, and retained evidence at most 12000 bytes. The adapter separately accepts at most 4096 response bytes after receiving a string. These are lesson parameters, not universal settings. They keep this fixture small enough to inspect while showing that step count, result size, and elapsed time are distinct limits.

Those size checks occur after in-memory construction. They cap accepted content, not the peak allocation of an untrusted transport or a real file reader. A production adapter must bound its response stream before buffering and its tools must avoid loading entire huge logs. Likewise, serialization bytes are not model tokens or billing units. The lab records no inference usage because it calls no model. A real integration needs its own input, output, request-count, and spend accounting based on approved provider or local-runtime measurements.

Worked Synthetic Budget Example

Suppose a hypothetical model chooser proposes three tool calls and then stop. That takes four steps. With max_steps=3, the controller records the three results but returns step_budget because no fourth stop choice was permitted. With max_steps=4 it can return handoff_requested. Now suppose the second tool returns after the deadline. The controller marks deadline and discards that late result; E1 remains available. These are expected control-flow outcomes, not measured latency observations.

A monotonic deadline is checked before a choice and after the chooser and tool return. It cannot interrupt a function that hangs. A future hosted transport needs connect/read timeouts tied to the remaining allowance; a local inference service needs a bounded request and cancellation mechanism enforced outside this loop. If a strict wall-time guarantee is required, an independently enforced supervisor boundary is needed. That infrastructure is outside the read-only, no-jobs lab and is not supplied by the example.

Exercise and Expected Checks

Classify these cases: the chooser asks for a protected document; a valid query matches no rows; the approved section is absent; the chooser repeats a valid call; the transport raises an exception. Specify which should create evidence and which should stop. Then decide whether adding three automatic retries would help. Boundary and schema failures are not transient, so repeating them is wasteful. A production transient-error retry policy needs a small retry cap, deadline accounting, and a documented reason.

Limits and Source

The catch-all error path emits a fixed code rather than copying an exception that might contain sensitive request data. It is intentionally coarse and would need approved operational diagnostics in a real service. See Python 3.12 time.monotonic for elapsed-time semantics. A stopped controller, a successful evidence task, and engineering signoff remain three different outcomes.

Related topics

• Up: Agent Design

• Next: Build the Starter Controller