Budget autonomy for uncertain search paths

Learning objective

Choose between a fixed pre-retrieval pipeline and agentic search where the model queries iteratively.

Core idea

Fixed retrieval prescribes the search path; agentic search lets findings influence the model’s next query. The Professional decision is whether that flexibility earns its operating cost for this workload.

Compare retrieval delivery, missing-source failures, operation budgets, and accepted-answer cost on the same request classes. The grounding interface can remain consistent across fixed and iterative retrieval even when the admission and scheduling policies differ.

How it works

Establish a fixed baseline

For pre-fetched evidence, the Messages API accepts search_result blocks directly in a user message. The block carries source, title, and text content; set citations: {"enabled": true} to enable attribution. Code can assemble the results of query transformation, hybrid retrieval, and reranking from 3.6.3 into this delivery format before answer generation.

For dynamic RAG, custom tools can instead return search_result blocks from their calls. Both delivery points support citations, so adopting iterative search does not require changing the grounding format. The Search results page documents support on all active models except Claude Haiku 3 and requires no beta header. See 2.2.4 for source-grounded answering.

Keep the source identifiers consistent across delivery points so the service can compare which documents each strategy found. An answer with citations still needs the required sources: attribution does not establish that retrieval covered every obligation. Record missing-source outcomes separately from incorrect synthesis over sufficient evidence.

Evaluate missed cases by cause. If an exact identifier never reaches the candidate set, fix method selection in 3.6.2. If the correct passage ranks too low, fix relevance in 3.6.3. Introduce iterative search only when a later query needs a decision that the prescribed pipeline cannot adequately represent. Otherwise autonomy obscures a repairable retrieval defect.

Spend turns where results change the investigation

For dynamic retrieval, stop_reason: "tool_use" marks the client-tool execution point; enforce search admission before executing the requested tool_use blocks. Count actual search operations, not just model responses: parallel tool use can place several blocks in one response. With tool_choice: {"type": "auto"}, setting disable_parallel_tool_use: true inside that object limits Claude to at most one tool call per response; see 3.6.3 for independent sub-query execution and result formatting.

The Agent SDK’s Python max_turns and TypeScript maxTurns count tool-use turns, not individual calls, and reaching the cap returns error_max_turns, so a six-operation retrieval cap still needs host-side counting; see 1.4.1 for budgets. Before dispatching a batch, compare its number of search operations with the shared remaining allowance and check the deadline. A prompt asking Claude to search briefly cannot implement either admission check.

Define successful completion in terms of required support, not merely the absence of another tool request. An investigation may terminate with a grounded answer, a clarification request, or an unresolved result. If the budget expires with a missing dependency, preserve the supported findings and name the gap rather than declaring that the whole question is answered. Recovery and broader agent-failure handling belong to 1.4.4.

The host admits each requested search against the shared allowance and deadline, and a budget that expires with a missing dependency ends with the supported findings preserved and the gap named.

Compare useful outcomes, not call counts alone

Runtime exploration adds turns and variable search work. Anthropic’s context-engineering article warns that it is slower than retrieving precomputed data and can chase dead ends without appropriate tools and guidance. The agent article likewise identifies higher cost and compounding errors as autonomy costs. A retrieved page can introduce a wrong lead that drives several later searches.

Measure answer acceptance, missing-source failures, search operations per request, model turns, total latency, and accepted-result cost. Compare the same request classes under the fixed baseline and the loop. Keep the difficult cases visible: a high average acceptance rate can hide a loop that times out on the very exploratory requests it was introduced to handle.

Record which requested search produced decisive evidence. This lets the team distinguish useful follow-up discovery from redundant searching. Anthropic’s tool-definition guidance recommends clear descriptions and high-signal tool responses; apply that to search interfaces that return stable source identifiers and only the information needed for the next decision. A huge result does not become useful merely because the agent chose it.

Avoid claiming that agentic retrieval eliminates freshness work. Just-in-time reads can reduce reliance on a stale precomputed index, as the context-engineering article explains, but a live source can still contain a withdrawn or inapplicable document. Retain the eligibility checks from 3.6.3 on every requested search.

Make the hybrid boundary explicit

Anthropic’s context-engineering article illustrates hybrid retrieval with Claude Code: CLAUDE.md supplies context up front, while glob and grep primitives retrieve files just in time, reducing reliance on stale indexing. The article suggests that hybrid retrieval may suit less dynamic legal or finance content. This is an architectural example, not a guarantee about which named Claude Code tools are enabled on every platform.

For the financial-services workload, identify the predictable documents supplied up front and the unresolved source relationships that admit additional searches. Implement that admission predicate in code, and preserve the same search_result source identities when dynamic tools add evidence. Measure how often the iterative stage retrieves a decisive source absent from the baseline, rather than merely repeating a lookup the fixed stage already performed.

Give the fixed stage and iterative stage a shared deadline and cost allowance. Otherwise the loop restarts the operating budget after the baseline has already consumed most of it. Keep tenant and source scope enforced by the executor throughout both stages; uncertainty about the next source does not authorize access to a different user’s records.

Key distinctions and trade-offs

Attribution versus coverage: Both delivery points preserve source attribution through search_result, but citations do not prove that all required evidence was retrieved.

Turns versus operations: Several search calls can occupy one model turn. Evaluate and cap actual retrieval work rather than assuming a turn limit supplies an operation limit.

Fresh reads versus valid evidence: Avoiding stale indexing does not establish that a retrieved document applies to the requested date or population.

Compare the two strategies using required-source coverage and accepted-answer cost. A hybrid needs an owner for the admission predicate and a trace showing which additional source justified each exploratory operation.

Architecture / decision scenario

A financial-services engineering team runs an internal incident assistant. Routine policy questions have a four-second target; dependency investigations permit 20 seconds and at most six search operations. In a hypothetical trial, the fixed path accepts 96% of routine answers in 2.6 seconds but only 68% of exploratory investigations. An iterative design reaches 89% on investigations in 14 seconds and takes eight seconds on routine questions.

A colleague proposes moving all requests to the loop to maximize investigation quality. The architect rejects that because routine traffic misses its four-second target. The service retains fixed retrieval for known policy sources and known dependency chains. The incident path admits iterative search when a result identifies an unresolved dependency whose source is outside the prescribed chain.

The host enforces the six-operation cap before executing requested tool_use blocks and shares the 20-second deadline across initial retrieval and exploration. Search descriptions distinguish service configuration, deployment history, and dependency records. Eligibility checks apply to each returned source, and answers record the supporting paths rather than inferring connections from similar names.

The service owner approves the increased cost for the 21-point investigation acceptance gain. The retrieval owner maintains the tools and source scope. If the sixth search leaves a dependency unresolved, the assistant returns supported findings with the gap for the incident engineer; it does not turn budget exhaustion into a complete diagnosis. This hybrid preserves the routine target while buying discovery where the measured gain warrants it.

Common exam traps

• Assuming every multi-hop question requires model-directed search.
• Switching to an agent to repair a missing lexical retrieval path.
• Treating agentic search as a particular index or query method.
• Enforcing search budgets only through prompt instructions.
• Giving the exploratory stage a fresh budget after fixed retrieval.
• Assuming live reads guarantee applicable document versions.
• Accepting loop termination as proof that every required source was found.

What to remember

Keep known retrieval paths in code. Admit model-directed search when discoveries change the required path and measured gains justify the extra turns. Enforce shared budgets at the executor, preserve eligibility on every operation, and return unresolved findings when the available evidence does not complete the answer.

Knowledge check

References

• Anthropic, Effective context engineering for AI agents

• Anthropic, Building effective agents

• Anthropic, Tool use with Claude

• Anthropic, Define tools

• Anthropic, Search results

• Anthropic, Parallel tool use

• Anthropic, How the agent loop works