Frequency:Occasional
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.
Frequency:Common
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.
Frequency:Common
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.
Frequency:Occasional
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.
Frequency:Very Common
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.
Frequency:Common
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.
Frequency:Common
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.
Frequency:Common
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.
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
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.
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
| Pattern | Mechanism |
|---|
| Wrong sequence order | Tools called in wrong order; violates dependencies |
| Missing prerequisites | Tool requires prior setup or data; agent doesn’t provide it |
| Conditional logic error | Conditional should prevent tool call; condition is wrong or missing |
| Early termination | Workflow should stop after tool failure; agent continues |
| Output format mismatch | Tool 1 output formatted wrong for Tool 2 input |
| Cardinality mismatch | Tool 1 returns N results; Tool 2 expects 1 result; mismatch causes error |
| State not propagated | Tool 1 modifies state; Tool 2 needs modified state; state not passed between tools |
| Error recovery sequence | Tool fails; error recovery sequence is wrong or missing |
Total: 8 patterns