Shift log: tool calls checked before provider rotation

The useful question on a provider rotation is not whether the next model supports function calling. It is whether the application still executes the right operation, with valid arguments, under the right authority, and returns the result in a format that model understands. This year, keep the practices that make those boundaries explicit. Treat tool use as an execution protocol, not a formatting convenience.

Keep the tool contract smaller than the provider surface

Maintain one application-owned definition for each tool, then translate it into each provider’s request format. Give tools precise names, describe when they should be used, and document units, accepted values, and side effects. Separate a read-only lookup from an operation that changes state rather than hiding both behind an ambiguous action parameter.

Start with a conservative schema: objects, explicit properties, required fields, and simple enums. Check support for optional fields, null values, nested structures, and constraints against the actual endpoint you use. A shared request shape does not establish identical schema enforcement. Where strict schema modes exist, enable them deliberately, but still validate every proposed call in your application.

Separate model proposals from execution authority

A tool call is a proposal from the model, not permission to act. The executor must authenticate the user, authorize the operation, validate arguments, and enforce limits independently. Tool descriptions can guide behavior; they cannot replace access control.

• Reject unknown tool names and unexpected arguments before dispatch.
• Resolve account ownership and resource permissions using trusted application state rather than model-supplied claims.
• Require confirmation for consequential writes when the workflow needs human approval, and bind approval to the exact proposed action.
• Treat retrieved documents and tool output as untrusted data, even when they contain instructions that appear operationally urgent.

Return structured failures that distinguish invalid input, denied access, temporary unavailability, and completed operations. That gives the model useful recovery information without exposing secrets or internal traces.

Finish assembling streamed calls before dispatch

Streaming can make a tool call look ready before it is complete. Names and argument strings may arrive in fragments, and multiple calls may be interleaved. Accumulate fragments using the provider’s call identifiers or indexes, wait for the documented completion signal, then parse and validate. Never execute a partial argument buffer because it happens to parse successfully.

Preserve call identifiers through the tool-result turn. Providers differ in their message envelopes and sequencing requirements, so keep that translation in an adapter. Test multiple calls, malformed arguments, interrupted streams, and a response that contains no tool request.

Retry transport failures without repeating business actions

Separate retrying a model request from retrying a tool execution. A disconnected response does not prove that a payment, ticket update, or deployment failed. For writes, use application-generated idempotency keys where supported, persist execution status, and reconcile uncertain outcomes before attempting the operation again.

Allow parallel execution only when operations are independent and safe to overlap. Put limits on tool rounds, total execution time, output size, and repeated failures. When the budget is exhausted, stop with a clear status rather than letting the agent improvise an endless recovery loop.

Requalify failover against recorded tool workflows

Before switching a workflow between models such as Claude Haiku 4.5 and Gemini 2.5 Flash, replay representative cases through the actual integration. Check tool selection, argument validity, authorization handling, result interpretation, and successful stopping. Do not infer equivalent behavior from an SDK accepting the same request.

Record the provider, model, schema version, tool-call identifier, validation outcome, execution status, and latency for each round. Redact sensitive arguments and results. Preserve application state separately from provider-specific conversation payloads so failover does not require blindly copying incompatible history.

Use a relay for access, not as a portability guarantee

Relay365 fits teams that want pay-as-you-go access across model families and compatibility with Claude Code, Codex, Gemini CLI, and OpenAI SDK clients. Its API base is https://api.api365relay.com; OpenAI clients add /v1. Verify tool behavior through the exact route you plan to deploy, because client compatibility alone does not establish feature parity.

Create a Relay365 account if that access pattern suits your evaluation workflow. Keep your schemas, safety checks, execution ledger, and regression tests under application control. Those are the shift assets worth carrying forward when the provider roster changes.