- In short
- Model-driven decision making lets Claude reason about which tool to call based on the current context and goal, while pre-configured decision making fixes the sequence of tools or branches at design time. Model-driven control gives flexibility; pre-configured control gives predictability, and high-stakes logic should be enforced programmatically.
Two ways to decide what happens next
Every agent has to answer a recurring question: given the current state, which tool runs next? Model driven decision making and pre-configured decision making are the two fundamentally different ways to answer it. With model driven decision making, you give Claude the tools and the goal and let it reason, turn by turn, about which tool the situation calls for. With pre-configured decision making, you decide the sequence or the branching logic in advance and the code, not the model, routes the flow.
This knowledge point is assessed at the analyse level, so the exam will not ask you to define the terms; it will ask you to compare the two approaches against a scenario and justify which fits. The analysis hinges on a trade-off between flexibility and predictability, sharpened by how much is at stake if a decision goes wrong. Get the trade-off clear and the rest of the knowledge point, including the high-stakes exception that overrides it, falls into place.
Where the decision actually lives
A useful way to sharpen the contrast is to ask who holds the routing logic. In a model driven design, the logic lives inside the model's reasoning on each turn; you express it indirectly through tool descriptions, the system prompt, and the goal you set. In a pre-configured design, the logic lives in your code as explicit branches, sequences, or state machines that you can read line by line.
That difference has practical consequences beyond flexibility. Model driven routing is harder to unit-test because the path is emergent rather than fixed, but it is far cheaper to extend, adding a new capability can be as simple as adding a well-described tool. Pre-configured routing is trivial to test and audit because every path is written down, but extending it means editing the control flow by hand. Neither is universally superior; the exam wants you to reason about which property the task most needs.
- Model-driven decision making
- An approach where Claude reasons about which tool to call based on the live context and the goal, rather than following a path fixed by the developer at design time.
What model-driven control buys you
Model-driven control shines when the right path cannot be known ahead of time. A customer-support request might be a refund, a password reset, or a shipping query, and the model can read the message and select the appropriate tool without you hard-coding every branch. An open-ended research task might surface a lead that demands a tool you never anticipated calling in that order. This is the regime Anthropic describes as a true agent: a system where the model "dynamically directs its own processes and tool usage."
The cost of that flexibility is predictability. Because the model decides, two runs of the same task can take different routes, and the behaviour is probabilistic rather than guaranteed. For many tasks that variability is exactly what you want, adaptability beats rigidity. The tool_choice parameter, set to auto, is the lever that grants the model this discretion.
What pre-configured control buys you
Pre-configured decision making fixes the route. You might wire a document-processing pipeline that always extracts, then validates, then summarises, in that order, every time. Anthropic's effective-agents guidance calls these workflows: systems where tools are "orchestrated through predefined code paths." The payoff is consistency, the flow is repeatable, auditable, and easy to test, because it does not depend on the model's judgment to stay on track.
The cost is the mirror image of the model-driven trade-off: a fixed path cannot adapt to the unexpected. If a document arrives in a shape the pipeline did not anticipate, a rigid flow has no room to improvise. So the analysis is rarely "which is better" in the abstract; it is "which trade-off fits this task." Predictable, structured work leans pre-configured. Open-ended, context-dependent work leans model-driven.
tool_choice: the lever between the two styles
The Messages API gives you a direct control for sliding between model driven and pre-configured behaviour: the tool_choice parameter. Its four settings map cleanly onto the spectrum this knowledge point describes. auto lets Claude decide whether to call any tool at all, the purest expression of model driven decision making, and the default when tools are provided. any requires the model to use one of the tools but lets it pick which. tool forces a specific named tool every time, which is a pre-configured decision baked into the request. And none prevents tool use entirely.
Understanding this parameter turns an abstract design choice into a concrete dial. If you want flexibility, you leave tool_choice on auto and invest in clear tool descriptions so the model routes well. If a step must always invoke a particular tool, forcing it with tool removes the model's discretion for that call. Most real agents mix the two: auto for the conversational routing, and a forced or gated choice where a specific action is mandatory. Knowing which setting expresses which intent is exactly the kind of applied judgment the analyse level rewards.
Note one subtlety the documentation flags: when you force tool use with any or tool, the model is prefilled to call a tool and will not emit a natural-language preamble first. That is usually fine, but if you need the model to explain itself while still using a tool, the recommended pattern is to keep auto and instruct the model in a user message. This is a small but exam-relevant detail about how forcing a decision changes the model's output shape.
Programmatic tool calling: a documented middle path
The two styles are not a strict binary. Anthropic's advanced tool use introduces programmatic tool calling, a pattern that blends them: instead of every tool result round-tripping back to the model for the next decision, Claude writes a script that orchestrates the whole workflow, with the loops, conditionals, data transformations, and error handling expressed explicitly in code. That script runs in a code-execution environment and calls the tools itself, returning only the final result to the conversation.
This matters for the analysis because it relocates where the routing logic lives a third time. In ordinary model-driven control the logic lives in the model's per-turn reasoning; in a hand-built workflow it lives in your application code. With programmatic tool calling the model authors the orchestration once, up front, and then a deterministic script executes it. You get model-generated flexibility in designing the flow together with code-like predictability in running it, plus far fewer round trips when a task fans out across many tool calls.
For the exam, the takeaway is not the implementation detail but the conceptual point: predictability and flexibility are knobs, not a single switch. When a scenario describes many tool calls whose structure the model can plan but whose execution must be efficient and repeatable, programmatic tool calling is the documented pattern that sits between letting the model decide every step and hard-coding the path yourself.
The critical exception: high-stakes logic
There is a third consideration that overrides the simple flexibility-versus-predictability comparison, and it is the part the exam most loves to test. Model-driven control is probabilistic: the model usually does the right thing, but not with a guarantee. For most decisions that is acceptable. For operations with financial, security, or compliance consequences, "usually" is not good enough.
When a single wrong decision means money moves to the wrong account or a compliance rule is skipped, the critical logic must be enforced programmatically, by code or hooks that the model cannot bypass, rather than left to the model's discretion. This is precisely the bridge into the prompt-based versus programmatic enforcement decision that Task 1.4 builds on next. Model-driven flexibility for the routing; deterministic enforcement for the guardrails the business cannot afford to have fail.
Worked example: routing a mixed support queue
Worked example
A support agent handles a queue containing refunds, address changes, and order questions. Refunds above a threshold carry financial risk.
The variety of incoming requests argues strongly for model-driven control. You hand Claude the full toolset, lookup_order, change_address, issue_refund, with tool_choice: auto, and let it read each message and select the right tool. A pre-configured pipeline would be a poor fit here; you cannot predict whether the next ticket is a refund or an address change.
But one branch carries real money. Letting the model decide, unaided, whether a large refund is legitimate is a probabilistic bet on a high-stakes outcome. So you keep the routing model-driven and add a programmatic gate: a hook intercepts issue_refund, and any amount over the threshold is blocked and escalated regardless of what the model decided. The result combines the best of both worlds, flexible routing for the everyday cases, deterministic enforcement for the one decision the business cannot afford to get wrong.
Misconceptions to discard
Misconception
Model-driven decision making is the modern, correct choice, so a good architect always lets Claude choose.
What's actually true
Misconception
Pre-configured flows are obsolete because the model can decide everything itself.
What's actually true
A practical heuristic for the analysis
When a scenario lands on your screen, three questions resolve almost every case. First, how predictable is the path? If the steps are the same every time, lean pre-configured; if they depend on inputs you cannot enumerate, lean model driven. Second, how varied are the inputs? A narrow, uniform workload suits a fixed pipeline; a heterogeneous one suits a model that reads each case. Third, and decisively, what is the consequence of a wrong decision? If a single error is merely inconvenient, the model's probabilistic judgment is acceptable; if it is financial, security, or compliance harm, that step must be enforced in code regardless of how the rest of the system is routed.
Run those three questions and the design usually writes itself: model driven routing across the board, pre-configured pipelines where the work is fixed and repeatable, and hard programmatic gates wrapped around the few steps the business cannot afford to leave to chance. The mistake the exam punishes is skipping the third question, choosing flexibility for a step whose failure mode is expensive.
How this is tested on the exam
Task 1.1 scenarios will describe a system and ask you to choose, or critique, its decision style. The analytical move the exam rewards is reading the task's characteristics, is the path predictable, how varied are the inputs, and what is the consequence of a wrong decision, and matching those to the trade-offs. Watch for the high-stakes trap, where a fluent-sounding "just let the model handle it" answer is offered for an operation that clearly needs programmatic enforcement. The architect who can name why model-driven flexibility is wrong for that one step, while right for the rest, is the one who passes this knowledge point.
A payments agent must, on every transaction, run a fraud check before transferring funds. The team proposes letting Claude decide when the fraud check is needed via tool_choice auto. What is the strongest critique?
People also ask
When should Claude choose its own tools?
What is the difference between agents and workflows?
Is model-driven control always better?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Agents and workflows
Why watch: Contrasts autonomous model-driven agents with pre-configured workflow paths, the exact distinction this KP draws.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.