Function calling

The pattern

A tool call has two decisions: which function to use, and which arguments are allowed. A typed result can keep those choices explicit while application code controls execution. Use a closed set of function names and validate each argument before dispatch.

This original example routes a support action. It demonstrates the composition and code layout of the public cookbook without repeating its trading example.

A narrow question

Keep the function choice separate from the argument extraction. A request for account access should not also decide whether an irreversible action is authorized.

from dataclasses import dataclass
from typing import Literal

@dataclass(frozen=True)
class SupportAction:
    function: Literal["open_ticket", "ask_for_details"]
    team: Literal["account", "billing", "product"]
    urgent: bool

# Original deterministic UI fixture, not an SDK response.
action = SupportAction(
    function="open_ticket",
    team="account",
    urgent=True,
)

Dispatch in application code

The application owns the branch. The local fixture maps a typed result to a message, so the page can demonstrate the result without contacting a help desk or model.

def describe_next_step(action: SupportAction) -> str:
    if action.function == "ask_for_details":
        return "Ask the visitor for missing details."
    priority = "urgent" if action.urgent else "normal"
    return f"Prepare a {priority} ticket for {action.team} support."

print(describe_next_step(action))
# Prepare an urgent ticket for account support.

Run the local fixture

Open the homepage decision specimen to try account, billing and unknown requests. Its output is deterministic and stays in this browser.