The examples use the gpt-5.5-2026-04-23 snapshot, construct requests, and mock tools without making a paid API call. The goal is not to let a model “execute any tool.” It is a controlled loop: the model proposes a typed call, the application validates and executes it, the result returns, and the task advances through durable checkpoints.

Layer one: pin model and reasoning effort

Read the key from the environment and persist snapshot plus configuration:

import os
from openai import OpenAI

client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
MODEL = "gpt-5.5-2026-04-23"

response = client.responses.create(
    model=MODEL,
    reasoning={"effort": "medium"},
    instructions=(
        "Use only the provided tools. Never invent tool results. "
        "Ask for clarification when an order id is missing."
    ),
    input="Check whether order A1B2C3D4E5F6 has shipped.",
)

Choose effort with offline evaluations. A simple read may use low; synthesis across several results can test medium or high; xhigh belongs in experiments for the hardest asynchronous work. Version the configuration. Do not allow arbitrary user prompt text to rewrite reasoning policy.

The model alias can be evaluated separately, but a reproducible release uses the snapshot. Store SDK, prompt, and evaluation date as well.

Layer two: declare a narrow tool

The schema contains only required product fields:

ORDER_TOOL = {
    "type": "function",
    "name": "lookup_order",
    "description": "Read the shipping state for one authorized order id.",
    "parameters": {
        "type": "object",
        "properties": {
            "order_id": {"type": "string", "pattern": "^[A-Z0-9]{12}$"}
        },
        "required": ["order_id"],
        "additionalProperties": False,
    },
    "strict": True,
}

Pass tools=[ORDER_TOOL] to responses.create. Strict schema reduces formatting errors; it does not authorize access. The executor validates the id again, verifies the active user owns the order, applies rate limits, and constrains the read. The model never receives database credentials. It sends a proposal to a gateway that holds authority.

Return the smallest useful JSON from the tool, perhaps status and update time rather than the entire customer record. A page or ticket can contain prompt injection. Put untrusted text in a clearly delimited data field and never let it expand the available tool set.

Layer three: parse and execute

Iterate over response.output and dispatch by item type instead of using a fixed index. Preserve or safely ignore unknown items. A function call has a call id. Before execution, persist proposed; after schema and authorization, persist approved; after the mock or real operation, persist succeeded or failed. Submit the tool output with its call id in the next Response input.

The real executor does not accept a model-supplied URL, SQL statement, or shell command. Tool names map to local functions. Pydantic or JSON Schema and domain rules validate arguments. Timeouts and exceptions become short structured results. Writes add idempotency, and consequential actions ask for action-time human approval.

Do not retry every tool failure automatically. A transient read can retry within policy; an authorization denial, invalid argument, or business conflict returns to the model or person without repeated execution.

Long work needs durable checkpoints

Persist product task id, response id, model snapshot, prompt and tool versions, completed stages, tool calls, and external artifacts. previous_response_id can continue model state, but the product database remains task truth. After process restart, reconcile whether a tool result was already committed before continuing, preventing duplicate effects.

Checkpoint after important stages or a bounded number of steps. Limit calls, total tokens, wall time, and repeated failure. If the model invokes one failed tool twice with identical arguments, stop and report. An asynchronous task must support cancellation and release its resources; it cannot become an ownerless background process.

Separate a plan checkpoint from an execution checkpoint. A reviewed plan does not pre-authorize every later action if arguments or destinations change.

Observe and evaluate the loop

Logs contain task and call ids, model, effort, tool name, validation outcome, latency, and tokens—not credentials or complete sensitive arguments. Metrics include task success, invalid calls, tool errors, duplicates, human approvals, total cost, and recovery success. Mock integration tests cover invalid parameters, insufficient permission, timeout, prompt injection, cancellation, and restart.

Do not evaluate only the final prose. Assert that the required tool was called—or correctly not called—that arguments belong to the account, checkpoints recover, and final state agrees with real data. A model statement that an order shipped cannot override a tool result saying it has not.

Replay recorded mock traces after SDK or tool-schema upgrades. The same proposed calls should receive the same policy decisions, while intentionally changed schemas require an explicit fixture migration. This catches orchestration regressions without spending API tokens.

The core of a GPT-5.5 tool workflow is authority separation. Pin snapshot and effort, keep schemas narrow, let the application validate and hold credentials, make effects idempotent and approved, and manage long work in a durable database. The Responses API can connect model state; the product still owns facts, authorization, and recovery.