Moving an agent from one model provider to another is more than changing a model name. Tool schemas, parallel-call behavior, message roles, streaming events and error payloads can differ. Production migrations must preserve the effect of each approved action, not merely generate a plausible text answer.
How it works
Start with an application-owned canonical tool definition: a name, strict input JSON schema, output schema, side-effect classification and authorization rule. Write small adapters that translate this definition into each provider’s supported API representation and validate both requests and responses. Never assume support for a similarly named JSON or function-calling mode means identical validation, ordering or retry behavior. Keep the tool executor independent from the model SDK.
A practical, bounded workflow
A workflow with ‘search_record’, ‘propose_update’ and ‘commit_approved_update’ can serve as a migration fixture. The old and new providers receive equivalent user requests and authorized evidence; a test harness records tool selection, arguments, omitted optional fields, invalid values and the final structured draft. The commit tool is simulated against a sandbox, and an external policy service remains responsible for approval tokens and payload fingerprints.
Failure modes and limits
When a provider streams partial arguments, never execute a write until the tool call is complete and fully validated. Some models may produce multiple tool calls in parallel even when the original executor assumed sequential actions; serialize side effects where business dependencies require it. Changing argument coercion can silently alter amount or date fields and should fail schema checks rather than auto-correct without logging.
Deployment controls
Assign responsibility for each transition: scheduled, running, awaiting evidence, awaiting approval, writing, reconciled, canceled or unresolved. The controller, not a free-form language response, decides whether a next action is authorized. Persist operation IDs and deadlines so a restart does not erase obligations or repeat committed effects.
When to choose this approach
Use cross-provider migration when resilience, capability or vendor policy justifies the extra adapters. A stable single-provider system may be easier to maintain. Keep model release IDs in AI 02, price units in AI 10 and IDE-specific coding integrations in AI 06; this guide owns only orchestration interoperability.
What to evaluate before production
Run identical golden tasks across both adapters with no real external writes. Compare call-level validity, authorized side effects, refusal cases, duplicate tool calls, streaming cancellation and replay behavior. Record adapters and exact model IDs; block migration if protected actions show any new unapproved execution path.
Version, market and tier caution (25 October 2026): This is a technical and operational guide, not a live entitlement, pricing or geographic-availability certification. Numeric commercial limits and undocumented release dates are intentionally omitted. Reconfirm the exact account, deployment region, access policy and vendor release before procurement or publication.