Choose who decides the next tool

Learning objective

Contrast model-driven tool selection with predefined decision trees and fixed tool sequences.

Core idea

The defining question is who chooses the next operation after receiving evidence. In a model-driven loop, Claude selects tools from the available definitions using the request, conversation, and prior results. In a predefined decision tree, application code chooses among known branches. In a fixed sequence, application code schedules an established series of steps.

All three can contain model calls. Calling a model at every step does not make a workflow model-driven if the application already determines the next tool. Conversely, running tool implementations in your application does not make the selection deterministic if Claude chooses which implementation to request.

Anthropic’s architectural distinction is between workflows organized through predefined code paths and agents whose model directs the process and tool usage. Choose the amount of flexibility the task needs, then retain explicit application control over allowed effects.

How it works

Let evidence guide model-selected actions

For user-defined client tools in the Messages API, supply tools with each tool’s name, description, and input_schema. These definitions tell Claude what operations are available and what arguments they accept. The model’s response identifies its selected operation through a tool_use block containing name and input.

With tool_choice: {"type": "auto"}, the default tool-choice behavior, Claude can choose how to respond in light of the request and tool definitions. After the application returns tool results, the next model decision incorporates that evidence. A failed account lookup can lead to a clarification; a successful lookup can reveal which policy search is relevant. The next action need not be known before the first request.

Good tool descriptions explain what a tool does, when to use it, what it returns, and how its arguments work. This is part of the selection interface, not cosmetic metadata. Ambiguous descriptions make the model’s alternatives harder to distinguish. See subsection 2.1 for tool-interface design; the architectural point here is that descriptions help the model choose among possible actions.

Model selection does not authorize the selected action. Your executor still validates the input and enforces the application’s permissions before running it. If a denied or failed call needs to be reported, use the matching tool_result mechanism from 1.1.2. The model receives evidence of the failure instead of a fictional success.

Encode known branches in a decision tree

A decision tree puts the routing rule in application code. For example, a support workflow checks whether an authenticated request contains an order identifier. If it does, code invokes the order service. If it does not, code returns a request for that identifier. The model might write the customer-facing explanation, but it does not select the branch.

You can also use a model to classify the request into a bounded set of categories, then route through predefined handlers. Anthropic calls this a routing workflow. A classification result that selects a known downstream process does not give that process permission to invent arbitrary tool sequences.

A tree makes known branches reviewable and testable, but unusual cases need an exception path. Delegating every unhandled branch to Claude changes the control model and needs deliberate design.

Code can call a tool directly without asking Claude to choose it. When a prescribed step instead needs Claude to generate a particular tool’s input, tool_choice: {"type": "tool", "name": "TOOL_NAME"} forces that tool on supported models; replace TOOL_NAME with its defined name. tool_choice: {"type": "any"} requires some provided tool but leaves selection to Claude, while tool_choice: {"type": "none"} prevents tool use. None of these fields defines an entire sequence: code still schedules its stages.

Forced any and tool choices fail with manual extended thinking (thinking: {"type": "enabled"}). They also return HTTP 400 on Claude Opus 5.5, Claude Sonnet 5.5, Claude Fable 5.1, and Claude Mythos 5.1. For those models, Anthropic documents auto with strict tool use (strict: true on the tool definition) as the alternative for schema-valid inputs; it does not force a specific selection. Check model and thinking support before prescribing a forced call.

Schedule known steps as a fixed sequence

A fixed sequence always follows an established order, such as retrieve an approved policy record, draft a response from it, and validate that draft. Individual steps can call Claude, but code owns their order. Anthropic’s prompt-chaining pattern decomposes work into fixed subtasks and can place programmatic checks between stages.

A sequence differs from a tree because it does not choose among alternative next steps based on branch conditions. It can still fail or halt at a validation gate. “Fixed” means the intended progression is prescribed, not that errors must be ignored to reach the final stage.

Do not use a fixed sequence merely because one example followed that path. If missing evidence can require a different lookup, or a result can reveal an unexpected dependency, the sequence needs either explicit branches or a model-driven investigation stage. Otherwise it spends work on irrelevant steps and cannot adapt when its assumptions fail.

Who chooses the next operation after receiving evidence differs in each strategy.

Key distinctions and trade-offs

These control strategies place the next-action decision in different locations:

Selection versus execution: Claude can choose an operation that your application executes. The two decisions are separate. A model-driven selector does not require unrestricted credentials or arbitrary execution.

Flexibility versus predictability: Agents can adapt to evidence that was unavailable at design time. Workflows make expected paths easier to inspect. Neither architecture guarantees answer quality; each needs acceptance criteria appropriate to its task.

Hybrid versus inconsistent ownership: You can combine a deterministic outer workflow with a bounded model-driven investigation. Define where the model’s discretion begins and ends. A required policy gate should remain a code gate rather than an optional tool that the model is asked to remember; see subsection 1.4.

More autonomy is useful only when it solves uncertainty in the path. If one retrieval and one response are enough, a longer loop adds operational cost without establishing a better result. Anthropic recommends beginning with the simplest approach that fits and adding complexity when evidence supports it.

Architecture / decision scenario

A support service handles delivery inquiries, routine policy questions, and disputed charges. The architect assigns each request type the control strategy it needs.

For a routine policy question, a fixed sequence retrieves the approved policy, asks Claude to draft an explanation, and checks the output before delivery. There is no need for Claude to discover an alternative business process. Code schedules the stages and stops if the retrieval fails.

For a delivery inquiry, a decision tree chooses known paths from authenticated customer data and order state: request a missing identifier, fetch tracking for a shipped order, or report the recorded processing state. Claude can explain the selected result. The application owns the predicates and the next operation.

For a disputed charge with uncertain cause, a bounded agentic stage exposes application-defined lookup tools. Claude selects which evidence to request, observes the returned records, and chooses whether a second lookup or clarification is necessary. The executor checks every operation; it cannot let a plausible explanation substitute for permission to change a financial record.

The outer workflow then evaluates the evidence and applies the required approval rule before any mutation. This hybrid uses model-driven selection where the investigation path is unknown while retaining predefined control where policy is mandatory. The deciding criterion is uncertainty about the necessary steps, not whether the request contains natural language or whether a model appears anywhere in the design.

Common exam traps

• Assuming forced tool_choice works on every model and thinking setting.
• Calling every workflow with an LLM an autonomous agent.
• Treating application execution of tools as proof that code selected them.
• Using a fixed sequence for a task whose evidence changes the required path.
• Assuming model-selected tools are automatically authorized.
• Treating a model-based routing classifier as unrestricted orchestration.
• Turning a required policy check into an optional model-selected step.

What to remember

Locate the next-action decision. Use fixed sequences for stable stages, decision trees for known branches, and model-driven tool selection when evidence determines an unpredictable path. Combine them with explicit control points rather than relying on the model to enforce mandatory policy.

Knowledge check

References

• Anthropic, Building effective agents
• Anthropic, Tool use with Claude
• Anthropic, Define tools
• Anthropic, Strict tool use