Tool Calling Patterns: Sequential, Parallel, Nested

Sequential Pattern

Sequential tool calling executes one tool after another, where each call depends on the result of the previous one. This is the most common pattern and the most intuitive: the agent calls tool A, processes the result, then calls tool B using information from tool A result, then calls tool C, and so on. The execution order is determined by data dependencies between the calls.

A typical sequential workflow might involve searching for a user by email (tool A returns a user ID), retrieving the user order history using that ID (tool B returns a list of orders), and then looking up the shipping status of the most recent order (tool C returns tracking information). Each step requires data from the previous step, making sequential execution the only viable approach.

Sequential calling is straightforward to implement, easy to debug (you can inspect the state between any two steps), and reliable because each step completes before the next begins. The primary disadvantage is latency, each tool call adds a round trip to the total response time, and the latencies accumulate linearly. A task requiring eight sequential tool calls might take 30 to 60 seconds, which can be unacceptable for interactive applications.

Optimization strategies for sequential patterns include caching frequently requested data to avoid redundant calls, batching related queries into single tool calls that return multiple pieces of information, and pre-fetching data that is likely to be needed based on the current step. These techniques reduce the total number of round trips without changing the fundamental sequential structure.

Parallel Pattern

Parallel tool calling executes multiple independent tool calls simultaneously in a single model turn. When the model identifies that several pieces of information are needed and none depend on each other, it generates all the tool calls at once. The calling application executes them concurrently and returns all results together. This pattern dramatically reduces latency for tasks with independent data requirements.

The key requirement for parallel execution is independence: the calls must not depend on each other results. A weather forecast for three cities is naturally parallel because the Tokyo forecast does not depend on the New York forecast. A sequence of database lookups where each query uses the result of the previous one cannot be parallelized because the dependencies are inherent.

All major model providers, including OpenAI, Anthropic, and Google, support parallel tool calls. The model indicates parallel calls by including multiple tool call objects in a single response message. The calling application must track which result corresponds to which call using the unique call IDs provided by each provider. Results are returned to the model as multiple tool result messages, one per call, in a single follow-up request.

Error handling in parallel patterns requires special consideration. When three parallel calls are made and one fails, the application must decide how to proceed. Options include returning all results (successes and failures) to the model and letting it handle the failure, retrying the failed call while caching the successful results, or failing the entire parallel batch and returning a combined error. The best approach depends on whether the failed call is critical to the overall task.

Nested Pattern

Nested tool calling occurs when the execution of one tool internally triggers additional tool calls. The outer tool appears to the model as a single invocation, but internally it orchestrates a multi-step process. A "comprehensive_analysis" tool might internally call a data retrieval tool, a statistical computation tool, and a visualization tool, combining their results before returning a single, unified output to the model.

Nesting is useful for encapsulating complex workflows behind simple interfaces. Rather than exposing the model to 15 individual tools required for a complex analysis, the developer bundles them into a single high-level tool that handles the orchestration internally. This reduces the cognitive load on the model (fewer tools to choose from), reduces token costs (fewer tool definitions in the request), and improves reliability (the orchestration logic is hardcoded rather than model-directed).

The tradeoff is observability. When the model calls a single tool and receives a result, it has no visibility into the internal steps. If the result is wrong, neither the model nor the developer can easily determine which internal step failed without examining the tool implementation. Nested tools should include detailed logging of internal steps and should surface informative error messages that indicate which sub-operation failed.

Nested patterns work best when the internal workflow is well-defined and deterministic. If the internal steps require adaptive decision-making based on intermediate results, the model should handle the orchestration through sequential or conditional patterns rather than having the decisions hardcoded in a nested tool.

Conditional Pattern

Conditional tool calling uses the result of one tool call to determine which tool to call next. The model examines the output of a tool, applies reasoning about the result, and selects the appropriate next action from multiple possibilities. This pattern is where tool calling most closely resembles human decision-making.

A common conditional pattern checks a status before taking action. The model might call "get_subscription_status" and receive a result indicating the user is on a trial plan that expires tomorrow. Based on this information, it might call "send_renewal_reminder" rather than "process_payment" or "cancel_subscription". The decision about which tool to call next is made by the model based on the data, not predetermined in the code.

Conditional patterns rely heavily on the model reasoning capabilities. The model must correctly interpret the result of the first tool call, identify the relevant condition, and select the appropriate next tool. This works well when the conditions are clearly defined and the tool descriptions explicitly state when each tool should be used. It works less well when the conditions are ambiguous or when the model must make nuanced judgment calls about edge cases.

Applications can improve conditional reliability by structuring tool results with explicit status fields, category labels, and next-action suggestions. A result that includes "status": "trial_expiring", "suggested_action": "send_renewal_reminder" gives the model clear guidance about what to do next, reducing the chance of incorrect conditional branching.

Iterative Pattern

Iterative tool calling repeats a tool invocation with modified arguments until a desired condition is met. The model calls a tool, evaluates the result, determines that the result is insufficient or incomplete, adjusts the arguments, and calls the tool again. This pattern is common in search, pagination, and refinement workflows.

A search refinement workflow might start with a broad query, find that the results are too numerous and not specific enough, narrow the search terms, and repeat until a satisfactory set of results is found. A data collection workflow might paginate through results, calling the same retrieval tool with an incrementing offset until all pages have been fetched. A quality improvement workflow might generate content, evaluate it against criteria, and regenerate with adjusted parameters until the quality threshold is met.

The primary risk with iterative patterns is infinite loops. A model that does not recognize when to stop iterating can repeat the same failing call indefinitely, consuming tokens and time without making progress. Applications should implement maximum iteration limits that terminate the loop after a configurable number of attempts. The model should receive clear signals about when iteration has been exhausted: "Maximum 10 results per page, page 5 of 5, no more pages available" tells the model to stop paginating.

Models sometimes struggle with iterative refinement when the improvement direction is unclear. If a search returns no results, broadening the query might help, but the model might instead make the query even more specific. Clear error messages and guidance in tool descriptions help: "If no results found with the exact query, try removing specific terms or using synonyms" gives the model a concrete refinement strategy.