Tool Selection Sequencing

8 patterns for this goal

Tool selection sequencing fails when agents call tools in wrong order, when tool outputs that should feed into downstream tools are formatted incorrectly, when agent forgets required prerequisites before calling a tool, or when conditional logic doesn’t properly guard when tools should be called. The 8 sequencing patterns documented here cover the challenge of orchestrating multiple tools into correct sequences — from tool dependencies through conditional invocation, to error recovery when one tool fails and downstream tools must adapt. Sequencing failures are particularly dangerous because a single tool called at the wrong time or with wrong prerequisites can cascade into complete workflow failure.

Key Takeaways

  • 8 patterns span tool ordering, prerequisites, conditional logic, error propagation, and workflow composition.
  • Wrong Sequence Order is most severe: calling tools in wrong order violates dependencies and produces wrong results.
  • Missing Prerequisites and Conditional Logic Errors are second-order: agents forget required setup or call tools when conditions don’t permit.
  • Error Propagation Failure is architectural: when one tool fails, downstream tools should adapt or stop, but don’t.

Scope

  • Sequencing and Dependencies — Tool ordering, prerequisites, dependency chains.
  • Conditional Logic — Conditional invocation, early termination, error recovery.
  • Data Flow — Output formatting between tools, cardinality mismatch, state propagation.

When Sequencing Matters

  • Multi-step workflows require specific tool ordering.
  • Tool output from one step must feed into next step correctly formatted.
  • Failure in one tool should stop or redirect downstream tools.

Cross-Pattern Insight

Sequencing failures result from treating each tool call independently rather than as part of a workflow. Tools are not orchestrated; they’re called opportunistically. When sequencing requirements exist, failures cascade silently. The mitigation is explicit workflow specification: model tool dependencies as a DAG (directed acyclic graph), validate that agent follows dependencies, and test workflows under failure conditions (tool fails at step 2; verify step 3 doesn’t execute or adapts).

Frequently Asked Questions

How do you specify tool sequencing requirements?

Model tools and their dependencies explicitly: Tool A must be called before Tool B, Tool B’s output must be passed to Tool C. Document these requirements and add agent-level validation to detect sequencing violations.

What should happen if a prerequisite tool fails?

If prerequisite fails, downstream tools should not be called (or should be called with fallback data). Make failure propagation explicit: if Tool A fails, don’t call Tool B.

Patterns

PatternMechanism
Wrong sequence orderTools called in wrong order; violates dependencies
Missing prerequisitesTool requires prior setup or data; agent doesn’t provide it
Conditional logic errorConditional should prevent tool call; condition is wrong or missing
Early terminationWorkflow should stop after tool failure; agent continues
Output format mismatchTool 1 output formatted wrong for Tool 2 input
Cardinality mismatchTool 1 returns N results; Tool 2 expects 1 result; mismatch causes error
State not propagatedTool 1 modifies state; Tool 2 needs modified state; state not passed between tools
Error recovery sequenceTool fails; error recovery sequence is wrong or missing

Total: 8 patterns

Tool Composition Complexity Explosion

Frequency: Occasional
Category: Operations

As the number of available tools and the depth of a plan grow, the number of possible tool-call sequences the agent could construct grows combinatorially, and the planning process either times out, truncates its search, or falls back to a shallow heuristic that ignores most of the space. The agent isn't failing on any single tool call — it's failing to reason about which combination and ordering of many tools is correct, because the branching factor has outgrown what the planner can actually evaluate within its context or time budget.

Tool Idempotency Assumption Failure

Frequency: Common
Category: Operations

An agent retries a tool call after a timeout, an ambiguous error, or a crash-and-resume, assuming that calling it again is safe because "retrying is always safe." Some tools are not idempotent — calling them twice with the same arguments produces two distinct side effects (two charges, two emails, two created records) rather than converging to the same end state. The agent's retry logic doesn't distinguish between tools where a duplicate call is harmless and tools where it corrupts state or produces a real-world duplicate action.

Tool Invocation Ordering Dependency

Frequency: Common
Category: Operations

Two or more tools must be called in a specific order for the task to succeed — one establishes a precondition, allocates a resource, or authenticates a session that a later tool depends on — but nothing in the tool definitions or the agent's planning logic enforces that order. The agent, reasoning about which tool seems most relevant to the current sub-goal, calls them out of sequence, and the later call either fails outright or, worse, succeeds against stale or wrong preconditions.

Tool Mutation State Leak

Frequency: Occasional
Category: Operations

A tool call mutates some shared state as a side effect — a global filter, a session variable, an environment setting, a cursor position, an authentication context — that isn't part of its declared return value, and a later, logically unrelated tool call is affected by that leftover mutation without either the agent or the tool's own interface making the dependency visible. The agent has no way to know that calling tool X changed the behavior of tool Y, because the mutation isn't represented anywhere in the tool-call contract.

Tool Output Format Mismatch

Frequency: Very Common
Category: Operations

An agent chains the output of one tool directly into the input of another, but the two tools disagree on format — one returns a date as `MM/DD/YYYY` while the next expects ISO-8601, one returns a list under a `results` key while the next expects `items`, one returns plain text while the next expects structured JSON. The agent either passes the mismatched data through unchanged (producing a downstream error or silent misinterpretation) or the LLM performs an ad hoc, occasionally-wrong reformatting step in between.

Tool Selection Greedy Suboptimal

Frequency: Common
Category: Operations

At each step, the agent picks whichever tool looks most immediately useful for the current sub-goal — the one whose description best matches the current phrasing — without considering how that choice constrains or costs more in later steps. This locally-good, globally-suboptimal selection pattern repeatedly leads the agent down a path that technically makes progress at each step but ends up more expensive, slower, or less accurate overall than a different tool choice earlier on would have been.

Tool Selection Non-Determinism

Frequency: Common
Category: Operations

The same task, given to the same agent with the same available tools, results in a different tool being selected across separate runs — one run calls a REST API tool, another run calls a functionally-overlapping SQL tool, a third calls a third-party search integration — with no change in the input that would justify the difference. Because downstream behavior, cost, and reliability differ by tool, this non-determinism makes the agent's behavior unpredictable and hard to test, debug, or give consistent guarantees about.

Tool State Dependency Violation

Frequency: Common
Category: Operations

A tool call is written or planned assuming a prior call already established some state it depends on — an authenticated session, a created resource, an uploaded file, a set configuration — but that prior call was never actually made, failed silently, or was skipped by the agent's plan. The dependent call proceeds anyway, either erroring against missing state or, more dangerously, succeeding against a default/fallback state that isn't the one the agent intended.