A research assistant can search documents, inspect account records, send email and edit a shared spreadsheet. Giving every worker all four capabilities looks flexible, but makes a source-gathering error capable of becoming an external communication or data change. The coordinator should own the overall decision while each worker sees only tools required for its specific evidence-gathering job. This distinction is central to Anthropic CCA-F tool-choice scenarios: a correct JSON schema explains how to call a tool; task-level ownership and permission boundaries determine whether that tool should be available to the agent at all.
Distribute authority by task, not convenience
A coordinator responsible for a research report may delegate source discovery to a browsing specialist and numerical checks to a spreadsheet specialist. The browsing worker needs access to search and page retrieval; it does not need the ability to send customer emails. The numerical worker can read bounded input files and run calculations, but it should not receive unrelated billing credentials. Restricting each worker’s catalog reduces accidental calls and makes failures easier to interpret. An impressive list of available tools is not a useful architecture metric.
Tool allocation should follow the task’s authority map. Record which agent can read data, which can propose an action and which service actually performs a privileged write. Do not let a worker’s recommendation silently become approval by the coordinator. Even within a single system, least privilege applies to autonomous components. The surrounding host and provider should enforce the permitted set rather than rely on each agent remembering a prose instruction to avoid disallowed operations.
Know what tool choice is controlling
In the Claude Messages API, the tool_choice setting can allow automatic selection, prohibit tools or—where supported—require a tool call. The architecture question is whether the task needs a model decision, a deterministic operation or a response without external access. Automatic selection is often suitable when Claude should decide whether existing information is enough. No-tool mode can be useful for drafting a final summary from already verified evidence. Forcing a specific tool may be appropriate for a mandatory structured step when the chosen model and settings support it.
Do not assume the same forced-tool modes work on every model or thinking configuration. Anthropic documents restrictions that depend on the current model and execution mode. Code should check supported options and fail clearly rather than silently treating a rejected force setting as an instruction the model will probably obey. Also separate tool-call selection from input-schema validation: strict schema checking can enforce argument shape, but it cannot prove that the selected tool is relevant or authorized for this user.
Decide when an automatic tool call is appropriate
A support agent asked to explain a published refund policy may already have the necessary verified policy text in context. Repeatedly calling a document tool wastes time and can return a newer draft outside the current policy period. Conversely, when asked for the current status of a particular refund, the agent needs an authoritative lookup; the previous conversation is not sufficient. A good system prompt explains the conditions under which the lookup should occur while external access controls prevent prohibited queries.
Operational evidence helps refine these choices. Log when the model uses a tool, whether it improves correctness, and when an unnecessary call adds latency. Investigate cases where Claude answers from stale context instead of checking a changing fact. Avoid solving every missed call by demanding a tool for every turn: that may increase cost and failure exposure without improving the answer. The objective is a reliable information decision, not a maximal number of tool invocations.
Make mandatory steps verifiable
Suppose an expense claim must pass a receipt lookup before payment approval. A system prompt telling Claude to always look up the receipt is helpful but does not itself enforce the business prerequisite. The host should check that a verified lookup result is associated with the claim before exposing the approval operation. If the protocol supports a forced call, it may streamline the step, but business correctness still depends on matching the returned receipt and verifying the current user’s authority.
This distinction becomes critical in longer chains. A model may call the right lookup with the wrong customer identifier or receive a malformed record. Checking only that the function name appeared in the transcript is insufficient. A deterministic gate needs the verified customer ID, accepted receipt status and a valid authorization state. Design the workflow so missing evidence remains an explicit unresolved condition, not a sentence the agent can reason away by producing a plausible explanation.
Reduce tool catalogs to improve selection
Specialization begins with the role boundary: an MCP integration may connect a server with many capabilities, but the active worker should see only the relevant approved subset. If several workers cooperate, task decomposition must explain who owns each finding and which dependent steps may proceed. Narrow catalogs and explicit handoffs solve different parts of the same reliability problem.
Large catalogs introduce selection ambiguity and context overhead. Two tools may have near-identical names but different side effects, or one server may provide both a basic lookup and a privileged administrative variant. Remove irrelevant tools from the worker’s view instead of compensating with increasingly elaborate prompt instructions. Clear names and descriptions remain important, as covered by MCP tool design, but catalog design determines whether the wrong tool was even offered as a candidate.
Different agents may need different descriptions of the same service. A source-research worker can receive a read-only documents.search interface, while the coordinator may receive only a summarized evidence-return function. This prevents lower-level workers from accumulating unnecessary capabilities. The tradeoff is additional orchestration, so measure whether specialization reduces errors and cognitive load more than it increases handoff latency. Tool distribution should solve a demonstrated problem, not create subagents simply because the framework supports them.
Treat parallel tool calls with care
Independent lookups, such as two public documentation searches, may run concurrently. Actions that share mutable state often should not. If a workflow reads account balance and then writes a transfer, scheduling the two operations in parallel undermines the prerequisite. The application should express ordering requirements and inspect whether the tool-choice configuration permits concurrent calls. Anthropic exposes parallel-tool controls in supported contexts, but an architectural dependency belongs in the workflow itself, not only in one model parameter.
For a reporting job, separate independent discovery from the dependent synthesis step. Gather source documents in parallel, then deduplicate and validate them before drafting a consolidated recommendation. If one source is unavailable, record the missing coverage rather than assuming another worker’s result is equivalent. Parallelism improves throughput only when the tasks are genuinely independent and the downstream decision can tolerate their arrival order and failures.
Design handoff contracts around ownership
A research specialist should return source identifiers, findings, confidence qualifiers and open questions to a coordinator, not an unrestricted instruction to publish the final report. The coordinator owns the decision to combine the material and may ask for more evidence. If a worker cannot access a required source, the error should surface as a coverage gap. Silent substitution with an unrelated tool is especially dangerous in regulated tasks where provenance matters.
The design in Claude subagent orchestration benefits from explicit ownership. A narrow tool catalog makes it easier to tell whether a failed research step was caused by unavailable permission, a tool error or an incorrect model choice. Document who can escalate and what the receiving agent is permitted to do. Context passing should preserve necessary evidence without transferring privileges from one actor to another.
Test negative as well as positive selection
Build test cases in which a correct outcome is deliberately not to call a tool. A user asks for a conceptual explanation with all facts already provided; the answer should not read customer records. Another asks for fresh shipment status; the system should perform the authorized lookup and cite its timestamp. Test similar tool names, missing permissions, irrelevant catalogs and model configuration changes. Record whether Claude chose the correct source and whether the host enforced the decision boundary.
A useful evaluation measures wrong-tool calls and avoided-but-necessary calls separately. Their operational costs differ: an unnecessary read may waste time, while an unauthorized write is a serious incident. Combine synthetic cases with real redacted traces, and challenge failures rather than adjusting the tool descriptions mechanically. Keep the model version and tool catalog frozen during comparisons so improvements can be attributed to the change under review.
Choose the tools for a purchase investigation
A coordinator investigates a disputed purchase. The evidence worker can fetch the order and payment state through scoped read-only tools; the policy worker can retrieve the applicable refund terms. Neither can issue the refund. The coordinator assembles the evidence and proposes a decision. A separate server-side gate checks customer identity, authorization and transaction state before any privileged operation is exposed. The result is a workflow that uses multiple tools without treating every tool as available to every participant.
If a document lookup fails, the coordinator reports a missing source and requests review rather than instructing a billing worker to improvise. If the evidence is complete, the final recommendation cites current records and the human approver can take the permitted action. The exam-relevant distinction is between model-selected assistance and enforced business authority: tool choice steers what Claude does next, whereas system design determines which actions are allowed and who is accountable for their effects.