I would treat the model response as a versioned contract, not merely a string the gateway parses. A tool call has a name, arguments, call identity, ordering relative to other calls, and a point at which the model's proposal is complete. A streaming partial argument is not a tool action. If the new format changes any of those semantics, a parser that merely renames fields can create duplicate or premature effects.

First, inventory how clients actually use the old response. Log the model snapshot, gateway adapter version, declared tool schema, client version, and which fields the gateway and applications read. Do this without logging private arguments unnecessarily. Separate apps that accept a platform-normalized tool proposal from apps that parse provider bytes themselves. The latter already crossed an abstraction boundary, but they still need a migration path. The undocumented field might be harmless debug metadata or might be their only way to correlate a tool result with a call. We cannot know by deleting it in a canary.

Old and new model formats go through versioned adapters before a common policy and operation boundary. Existing runs stay pinned while new applications move deliberately.
Two formats can coexist. One effect gate still decides whether a proposed call may run.

I would keep the old route and adapter available for pinned apps. Put a new adapter behind an explicit model-and-contract version. It produces a typed internal proposal only after the new stream has a complete call. The proposal carries the raw response reference, tool name, validated arguments, call ID, model version, and capability flags such as parallel calls or required result ordering. The tool runtime still checks policy, approval, idempotency, and current authority. An adapter must not turn unfamiliar output into a best-guess executable call.

This is a real compatibility problem, not a hypothetical one. OpenAI's Responses migration guide documents a different function-call shape from Chat Completions. The lesson for an internal platform is to test the wire contract and behavior of the chosen model and API, not assume a provider-neutral JSON blob makes all tool semantics equivalent.

Before live cutover, replay representative app inputs in a sandbox. Compare tool selection, arguments, call correlation, parallel-call behavior, refusals, and timeouts. Shadow the new model's proposals on production-shaped traffic, but do not execute its writes. Then opt in a few read-only and low-risk apps, followed by apps with stronger effect contracts. Each app should have a gate for task success and tool errors, not only whether the gateway returned HTTP 200. Keep a rapid route rollback and the owners of that rollback visible.

The undocumented field needs its own investigation. I would identify every consumer and the field's actual meaning from traces and code. If it can be derived without losing semantics, expose an explicit replacement for a deprecation period and test both old and new values. If it cannot, those apps remain pinned or fail clearly until their owners migrate. Silently filling the field with null or a plausible value can be worse than an explicit incompatibility. Publish a deadline only after there is a tested replacement and a plan for apps that cannot meet it.

What about an agent already in the middle of a run? Pin its model, adapter, and tool schema for the in-flight step. Do not switch formats between a tool proposal and the matching result. If a provider response was sent and the external effect is uncertain, changing adapters cannot resolve it. The operation ledger must reconcile that effect under its original identity. New runs can move to the new contract after their application passes its gate. Long-running old runs may need a deliberate checkpoint migration with compatibility tests, not an unannounced default change.

Finally, test rollback with mixed versions in flight. Can the old adapter still parse old responses? Does the new route use a tool schema the old route cannot express? Is the application allowed to return to the old model after its state has incorporated a new-only tool result? If not, rollback may mean stop new intake and drain or hand off existing runs. A platform migration is complete when every app has a known contract and the old route can be retired with evidence, not when the default model label changes.