The Tool-Call Round Trip

You understand what a tool call is and how schemas describe tools. Now let us trace the complete round trip — the full sequence of events from the moment a user sends a message to the moment the model produces its final response, with one or more tool calls in between. This end-to-end picture is what you need to build, debug, and reason about real agent systems.

The Five-Phase Cycle

Every tool-use interaction passes through five phases. Understanding each phase precisely prevents the most common implementation mistakes. Phase 1 — Model receives context. The model receives the conversation history plus the tool definitions (schemas) in its context window. Before it generates a single token of response, the model has already 'read' every available tool and knows what each one does. In multi-turn conversations, the history may already contain previous tool calls and results. Phase 2 — Model decides: respond or call a tool? This decision is the model's highest-level reasoning step. For some queries the model can answer directly from its training knowledge. For others it determines that accurate answering requires live data, an external action, or a computation it cannot perform internally. That judgment is itself a form of reasoning the model has been trained to perform. Phase 3 — Model emits a tool call. If it decides to call a tool, the model outputs a structured tool call message — not a text response. Depending on the API, this might look like a JSON object with 'name' and 'arguments' fields, or a dedicated message type. The model stops generating at this point; control passes to the executor. Phase 4 — Executor runs the tool. Application code extracts the tool name and arguments, calls the corresponding function, and collects the return value. This is where real work happens: a database query runs, an API call is made, a file is read, code is executed. The executor is responsible for error handling — if the tool fails, the executor must decide whether to retry, return an error result, or abort. Phase 5 — Result is returned; model continues. The executor packages the tool result as a new message and appends it to the conversation history. The model sees: [user message] → [tool call] → [tool result] and continues generation. If another tool call is needed, it loops back to Phase 3. When the model has all the information it needs, it generates a final natural-language response to the user.

Let us trace a complete, realistic round trip for a financial research assistant. The user asks: 'Compare the market cap of Apple and Microsoft, and tell me which grew more over the past year.' Phase 1: The model sees this message plus two tool schemas: get_stock_info(ticker) and calculate_percentage_change(old_value, new_value). Phase 2: The model reasons that it needs current and year-ago market cap values for both companies — it cannot answer accurately from training data because market caps change daily. Phase 3a: The model emits: call get_stock_info with ticker='AAPL'. Phase 4a: Executor calls the financial API. Returns: {current_market_cap: 3.1T, market_cap_one_year_ago: 2.8T}. Phase 5a: Result appended to history. Phase 3b: Model emits: call get_stock_info with ticker='MSFT'. Phase 4b: Executor calls the API. Returns: {current_market_cap: 3.2T, market_cap_one_year_ago: 2.5T}. Phase 5b: Result appended. Phase 3c: Model emits: call calculate_percentage_change with old_value=2.8, new_value=3.1. And: call calculate_percentage_change with old_value=2.5, new_value=3.2. Phase 4c: Executor runs both. Returns: 10.7% for AAPL, 28.0% for MSFT. Phase 5c: Both results appended. Final response: The model synthesizes: 'Apple's market cap is currently $3.1 trillion (grew ~10.7% year over year). Microsoft's is $3.2 trillion (grew ~28.0%). Microsoft grew substantially more.' Four tool calls, four round trips, one coherent answer.

Parallel Tool Calls

In the financial example above, the two calculate_percentage_change calls in Phase 3c are independent — neither depends on the other's result. Some AI APIs (including OpenAI's and Anthropic's) allow the model to emit multiple tool calls simultaneously in a single response turn. The executor can then run them in parallel, cutting latency significantly. Parallel tool calls require the executor to handle concurrent execution and collect all results before returning them to the model. The model receives all results at once and can reason across them together. Not all tools are safe to parallelize — if Tool B's arguments depend on Tool A's output, they must run sequentially. Designing agent systems requires reasoning carefully about these dependencies. A useful mental model: treat tool calls like function calls in a program. Sequential calls are like sequential statements. Parallel calls are like parallel threads. The model's conversation history is the call stack. The executor is the runtime.