Tool Selection and Orchestration

Once an agent has access to multiple tools, a new problem appears: tool selection. The agent must decide whether a tool is needed, which tool is appropriate, what arguments to pass, and what to do after receiving the result.

This is where tool use becomes orchestration. A single function call is simple. A multi-tool workflow requires planning, state management, error handling, stopping conditions, and sometimes human approval.

Tool selection can be handled mostly by the model, mostly by application code, or through a hybrid approach. Most production systems use a hybrid approach: the model interprets the user’s request and proposes tool calls, while the application constrains what is available, validates arguments, and enforces workflow rules.

When should an agent call a tool?

A model should call a tool when the task requires information or action outside the prompt and model parameters.

Good reasons to call a tool include:

• The answer depends on current information.
• The answer depends on private data.
• The task requires exact computation.
• The task requires reading or writing files.
• The task requires interacting with an external system.
• The model needs to verify a claim.

A model should not call a tool when the task can be answered directly from provided context or general stable knowledge.

For example:

User: Explain what an API is.

No tool is needed.

User: What is the status of ticket BUG-9812?

A ticket lookup tool is needed.

Model-driven selection

In model-driven selection, you provide the model with tool definitions and let it choose. This works well when tools are clearly described and the consequences are low-risk.

Example:

{
  "tools": [
    {
      "name": "search_docs",
      "description": "Search product documentation for technical explanations and API references."
    },
    {
      "name": "get_account_status",
      "description": "Retrieve account status for a known customer ID."
    },
    {
      "name": "create_ticket_draft",
      "description": "Create a support ticket draft for human review."
    }
  ]
}

If the user asks, “How do I rotate an API key?” the model should choose search_docs. If the user asks, “Is customer C-481 active?” it should choose get_account_status.

The quality of selection depends heavily on the clarity and separation of tool descriptions.

Code-driven routing

In code-driven routing, application logic decides which tools are available or which workflow to run. This is useful when tasks are predictable, regulated, or high-impact.

For example:

def select_available_tools(user_role: str, task_type: str) -> list[str]:
    if user_role == "support_agent" and task_type == "order_lookup":
        return ["get_order_status", "get_shipping_events"]
    if user_role == "support_manager" and task_type == "refund":
        return ["create_refund_request", "approve_refund"]
    return ["search_help_center"]

The model still decides how to use the available tools, but the application narrows the action space.

This is often safer than exposing all tools to all users in all contexts.

Sequential orchestration

Sequential orchestration means each step depends on the previous result.

Example research flow:

1. search_web(query)
2. fetch_url(best_result)
3. extract_relevant_facts(page_content)
4. answer_user(facts)

The agent cannot fetch the best result until it has searched. It cannot extract facts until it has fetched the page.

Sequential workflows are easy to reason about and debug. They are appropriate when each decision depends on new evidence.

Parallel orchestration

Parallel orchestration means calling multiple independent tools at the same time.

Example travel flow:

- get_weather(destination, dates)
- search_hotels(destination, dates)
- search_flights(origin, destination, dates)
- check_calendar_availability(dates)

These calls do not depend on each other, so they can run in parallel to reduce latency.

Parallel tool use is powerful but requires result merging. The agent must combine data, resolve conflicts, and avoid acting prematurely. Parallel reads are usually safe. Parallel writes require much more caution.

Planned orchestration

Some agents create an explicit plan before tool use:

Plan:
1. Identify the relevant policy.
2. Search internal policy documents.
3. Fetch the most relevant document.
4. Extract the section about reimbursement limits.
5. Answer with citation and caveats.

Planning is useful for complex tasks, but it can also add overhead. For simple tasks, planning may be unnecessary. The orchestration strategy should match the task complexity.

Example: multi-tool support agent

Suppose a user asks:

My order is late and I want to know whether I can get a refund.
Order ID: ORD-7711

A support agent might need several tools:

get_order_status(order_id)
get_shipping_events(order_id)
search_refund_policy(query)
create_refund_request(order_id, reason)

A good sequence might be:

1. Look up order status.
2. Check shipping events.
3. Search refund policy for late delivery.
4. Explain eligibility.
5. Offer to create a refund request draft if appropriate.

The agent should not immediately call create_refund_request. It first needs evidence.

Tool arbitration

Sometimes multiple tools seem relevant. Tool arbitration is the process of choosing the best one.

Example:

User: What does our vacation policy say about unused days?

Possible tools:

• web_search
• search_internal_policy_documents
• search_hr_tickets

The correct tool is likely search_internal_policy_documents, because the question is company-specific and policy-based. The public web is less authoritative.

Tool descriptions can help:

Use search_internal_policy_documents for official company policy. Prefer it over web_search for internal HR, security, and compliance questions.

Limiting the tool set dynamically

One practical strategy is dynamic tool availability. Instead of showing every tool on every request, the application first classifies the task or user context, then provides only relevant tools.

Example:

def tools_for_task(task_type: str) -> list[dict]:
    if task_type == "research":
        return [web_search, fetch_url, summarize_document]
    if task_type == "customer_support":
        return [get_order_status, search_policy, create_ticket_draft]
    if task_type == "coding":
        return [read_file, edit_file, run_tests]
    return []

This reduces confusion, improves tool selection, and limits risk.

Practical takeaway

Tool orchestration is the control layer of a tool-using agent. Good orchestration answers these questions:

• Should the agent call a tool?
• Which tools should be available?
• Should calls be sequential or parallel?
• What should happen after each result?
• When should the agent stop?
• When should it ask for confirmation?

The model is useful for flexible interpretation and decision-making. Application logic is useful for enforcing permissions, workflow order, and safety constraints. Reliable agents combine both.