Function calling looks like one feature in the API docs and turns into five distinct patterns the moment you write production code with it. The patterns are stable across providers — GPT-4o, Claude Sonnet 5, and Gemini 2.5 all express them with minor syntax differences — and knowing which one your task needs saves you from the default failure mode of this space: an over-eager model calling tools in circles.

If you have not read the cluster pillar, how to get reliable JSON out of LLMs, start there; it places function calling among the other structured-output approaches. This page assumes you have picked tool use and asks: in what shape?

Pattern 1: the single forced call

The simplest and most underrated pattern. One tool, tool_choice forcing it, one call, done. This is how you use function calling as a structured output channel rather than for actual actions: define a tool named record_extraction whose parameters are your target schema, force it, and read the arguments. On OpenAI that is tool_choice: {"type": "function", "function": {"name": "record_extraction"}}; on Anthropic, tool_choice: {"type": "tool", "name": "record_extraction"}.

Forcing matters. On auto, models sometimes answer in prose "instead of" calling the tool, especially when the input is ambiguous, and your parser gets nothing. If the call is the point, do not give the model the option. The pure-extraction version of this overlaps heavily with schema mode, and json mode vs schema mode covers when to prefer which.

Pattern 2: parallel tool calls

Both OpenAI and Anthropic support the model requesting multiple tool calls in a single assistant turn, as of 2026-07. OpenAI returns an array under tool_calls (opt out with parallel_tool_calls: false); Anthropic returns multiple tool_use content blocks (opt out with disable_parallel_tool_use).

This is a gift for latency — "check inventory for these three SKUs" becomes one model turn plus three concurrent lookups instead of three round-trips — but it obligates your executor to handle plurality correctly: execute each call, then return one result per call ID in the next message. The classic bug is an executor written for the single-call case that silently drops the second call. Write the loop plural from day one, even if your current prompts never trigger it.

Pattern 3: tool_choice as a dial, not a switch

Three useful settings, present on both major providers as of 2026-07:

  • auto — the model may call tools or answer directly. For genuinely conditional tools: search, calculators, escalation.
  • required / any — the model must call some tool. For routers, where every input maps to one of several handlers and prose is never acceptable.
  • named tool — the model must call this tool. For extraction and any single-purpose call.

Pick the tightest setting the task allows. Every degree of freedom you leave open is a degree of freedom the model will eventually use in a way you did not want.

Pattern 4: extract-then-act

The pattern that keeps LLMs out of your execution path. Instead of giving the model a charge_customer tool, give it an propose_charge extraction step; your deterministic code validates the proposal (amount within limits, customer exists, idempotency key fresh) and then performs the action itself. The model structures intent; conventional code executes it.

This buys three things: an audit point between intent and effect, a place to apply the semantic validation that schemas cannot express (see retry loops for validation failures), and the ability to unit-test the acting half without a model in the loop. Any tool whose effect is irreversible or costs money should be behind this split. NerdSip's lesson pipeline is a mundane but real example of the shape: the model proposes a structured lesson object, validation gates it, and only then does ordinary code publish it into the app.

Pattern 5: the agentic loop with a done tool

For multi-step tasks, the standard skeleton is a loop: send the conversation plus tools, execute whatever the model calls, append results, repeat. The two design decisions that separate loops that terminate from loops that wander are an explicit terminal tool and a budget.

tools = [search_orders, get_order_detail, done]
history = [user_task]
for turn in 1..MAX_TURNS:          # MAX_TURNS = 8, fixed
    reply = model(history, tools, tool_choice=required)
    for call in reply.tool_calls:  # may be several — see Pattern 2
        if call.name == "done":
            return call.args       # structured final answer
        result = execute(call)
        history.append(tool_result(call.id, result))
return best_effort_or_fail(history)   # budget exhausted: a normal path

The done tool's parameters are your final-answer schema, so termination and structured output arrive in the same envelope. tool_choice: required keeps the model from drifting into prose mid-loop.

And the budget is not decoration. Models over-call tools — they re-search for things already in context, re-verify results they just received, and take a third look "to be safe." This is consistent across providers as of 2026-07 and prompt instructions reduce it only somewhat. A fixed loop budget converts that behavior from an unbounded cost into a bounded one. Size it to the task (5 turns for lookups, 10 to 15 for multi-source research) and treat budget exhaustion as an expected outcome with defined handling, not an exception.

What makes all five patterns work: the tool set itself

Every pattern above degrades if the model cannot tell your tools apart. Overlapping tools produce coin-flip selection; vague descriptions produce over-calling; forty micro-tools produce choice paralysis and wasted context. The craft of naming and describing tools so the model picks correctly is its own topic, covered in tool selection prompting — read it before you ship a tool set larger than three.

The takeaway

Match the shape to the task: forced single calls for extraction, parallel calls for independent lookups, the tightest tool_choice you can get away with, extract-then-act for anything with side effects, and a done-tool-plus-budget loop for multi-step work. The common thread is structural control — budgets, forced choices, deterministic execution — doing the work that prompt instructions alone cannot. As of 2026-07 the models are good enough to make these patterns reliable and not yet good enough to make them optional.