Skip to main content
Sail supports tool calling through the Responses API, letting you build agents that call external tools and reason over the results across multiple turns.

How it works

  1. Send a user message along with tool definitions to /v1/responses.
  2. The model may return one or more function_call items instead of (or alongside) text.
  3. Execute the tools locally, then send the results back as function_call_output items in a new request, together with the full conversation history.
  4. Repeat until the model responds with text only.
Each request includes the entire conversation so far. Append response.output items directly to your conversation list (they are valid input items with no conversion needed), then append the function_call_output results.

Full example: multi-turn weather agent

This example uses zai-org/GLM-5.2-FP8 to build a two-turn conversation where the model calls a weather tool and then answers a follow-up question using context from the first turn.

What happens under the hood

  1. Turn 1: the model receives the user question plus the tool definition. It calls get_weather for San Francisco. After we send the tool result back, a second request is made and the model produces a text summary.
  2. Turn 2: the full conversation (including Turn 1’s tool call and result) is sent again. The model calls get_weather for New York, gets the result, and compares it with the San Francisco data it already has in context.

Tips

  • Optionally choose a completion window for your agent loop. balanced buys more tokens per dollar for autonomous work and flex offers the lowest prices for time-insensitive workloads. See Completion windows for the cost and latency tradeoff.
  • background=True is recommended for long-running agents and required for flex. Background mode avoids HTTP timeouts and lets you poll for completion.
  • Treat incomplete as terminal. It is not an error and can contain partial output and usage. Inspect incomplete_details.reason before deciding whether to continue with the partial result or submit a new request. For a normalized max_output_tokens reason, consider both the request’s output limit and its total input plus output context usage. Depending on which limit stopped the response, reduce the input or adjust the output budget.
  • Do not assume every terminal response is completed. Stop polling on completed, incomplete, failed, or cancelled. Only completed and incomplete can contain output to consume.
  • Send the full conversation in each request. Include all prior messages, response.output items, and tool results. Output items from previous responses can be appended directly. No serialization or conversion is needed.
  • strict: true on tool parameters enables structured output guarantees: the model’s arguments JSON will always conform to your schema.
  • Parallel tool calls are supported by default. The model may return multiple function_call items in a single response.
  • Add a per-request Idempotency-Key header so retries will use the stored response instead of re-running inference and double charging. See Idempotent Requests.