Treat a model change or deprecation as an application dependency change that requires evaluation and a release decision. Identify affected workflows, test the replacement against their acceptance conditions, and preserve permission and approval controls. If the current model becomes unavailable before a replacement is accepted, use an agreed fallback or pause the affected capability.
Separate a changed model from a retired dependency
A model change can alter the behaviour of a workflow even when its surrounding application code stays the same. A replacement may interpret an ambiguous request differently, select a different available tool, or produce output that needs different handling. The question is whether the complete product still meets its acceptance conditions.
Deprecation adds an availability issue. A dependency marked for retirement requires a migration plan based on the service's actual notice and support terms. Do not assume that a familiar endpoint name is permanent or that a replacement will preserve every behaviour the workflow depends on.
Separate a behavioural regression, a service outage, and a retirement notice in operational records. They may call for different immediate responses. A regression may justify reverting an available configuration; a retired model may no longer be a usable rollback target. An outage may require a temporary restriction while the current dependency remains supported.
Know where the model is used before replacing it
Maintain a dependency record that connects model configurations to product capabilities. Include the application owner, deployment location, configuration source, access boundary, and evaluation suite. Model calls hidden inside separate scripts or retrieval helpers can otherwise escape a migration review.
Include indirect uses. The model used to draft a proposal may differ from a model used to assess its quality. A changed grader can change evaluation verdicts even if the proposing model is unchanged. Review both dependencies and preserve human-reviewed reference cases so evaluation does not drift unnoticed with its subject.
Record the version information the service actually exposes. Where an explicit version can be selected, document that selection and its support conditions. Where the service supplies an alias or managed deployment, record that limitation and monitor the corresponding change notices. Configuration discipline cannot freeze a dependency that the provider does not make immutable.
The operational owner should know who receives those notices and who decides whether a change affects the product. This is part of operating an agent after launch, alongside incidents and ordinary application maintenance.
Keep business contracts outside model-specific behaviour
The application should define what a valid proposal contains, which evidence is required, and what operations are permitted. Those contracts should not be implicit in the way a particular model usually phrases its answer. Validate output before it enters a decision queue or an execution path.
Keep model interaction behind an interface the team can change deliberately. That interface can handle request construction, output parsing, failure classification, and configuration references. It does not make models interchangeable: the replacement still needs behavioural evaluation and may need different instructions or context handling.
For a hypothetical facilities application, the proposal might identify a maintenance request, relevant equipment records, and a recommended action. A replacement that writes an attractive explanation but omits the equipment reference has not preserved the product contract. The application should reject the incomplete proposal rather than guess which record the model intended.
The same principle applies to tools. An adapter can translate a model's request format into a declared read contract, but the integration layer remains responsible for permission checks. Enterprise AI integration describes those responsibilities independently of model choice.
Evaluate the replacement against the actual workflow
Use ordinary tasks, ambiguous requests, missing evidence, restricted records, and previously observed failures. Examine whether the candidate retrieves appropriate context, respects the task boundary, produces a reviewable proposal, and stops when it cannot proceed. A generic demonstration does not answer these questions for your application.
Compare outcomes against written acceptance conditions rather than demanding identical prose. Different wording may be acceptable when the evidence and intended operation are equivalent. Conversely, similar wording can hide a changed target record, omitted qualification, or unjustified assertion.
Investigate failures before weakening the check. The candidate may need an instruction change, the integration may have an incompatible assumption, or the existing expectation may be wrong. Record which explanation the evidence supports. Keep acceptance authority separate from the desire to finish a migration.
Evaluate the complete candidate configuration. If prompts, retrieval, and parsing change with the model, results apply to that combination. Preserve those versions with the evidence so reviewers can identify what was accepted. The guide to what agent evals catch explains why task evaluation and deterministic checks are both necessary.
Preserve human authority during the migration
In CodeDTX's Propose–Decide–Execute pattern, the model participates in proposing work. A named human decides, and a separate execution layer performs approved work. The proposing agent has no outward write tool. Replacing the model must not silently expand those permissions or bypass review to accommodate a different output format.
Pending proposals need an explicit treatment. Preserve their original configuration and evidence references. If a migration regenerates a proposal or changes its intended operation, obtain a decision on the changed proposal. A reviewer who approved an earlier draft did not thereby approve any later interpretation of it.
Also review integration and knowledge dependencies, reliability checks, safety controls, and the product interface. The reference architecture makes the migration a review of the workflow rather than a model-selection exercise. A different response shape may affect what a reviewer sees even if backend validation passes.
Release with a fallback that can actually run
Introduce the accepted configuration within a controlled scope and watch the requests it handles. Where parallel comparison is appropriate, keep comparison runs from duplicating business actions or exposing data to an unapproved environment. Results collected from a candidate should remain distinguishable from production decisions.
A rollback plan must name an available, permitted configuration and the conditions under which it can be restored. If the old model has been retired, reverting its identifier is not a recovery strategy. The fallback might be a separately evaluated model, a deterministic part of the workflow, or manual handling through the existing application.
Define what happens when no accepted replacement is available. Preserve pending work, stop unsupported generation or execution paths, and make the product's state clear to users. This is preferable to silently routing sensitive requests to an unreviewed dependency. Production monitoring should confirm that the chosen restriction or fallback behaves as intended.
Frequently asked questions
Does changing the model require rebuilding the whole agent?
Not necessarily. Declared application and tool contracts can localise changes to model interaction, configuration, and output handling. Behaviour still needs evaluation because compatibility at the interface does not establish suitability for the task. The assessment should identify which assumptions depend on the current model and which controls remain enforced independently in the application and integration layers.
Can we keep using a deprecated model until migration is convenient?
That depends on the actual service notice and access terms. Treat continued availability as a dependency to verify rather than an entitlement. Assign an owner to the retirement plan, identify affected workflows, and prepare an operational fallback. If the dependency becomes unavailable, the product should preserve work and communicate the restriction instead of repeatedly attempting unsupported requests.
Will a model with stronger general capabilities pass our existing checks?
That cannot be assumed. General capability does not determine how a model behaves with your instructions, evidence, tool contracts, and ambiguous requests. Evaluate the candidate against the workflow's acceptance conditions and known failure cases. A replacement may need configuration changes even when it performs well on unrelated tasks or produces more fluent explanations during a demonstration.
What should happen to approvals recorded before a model migration?
Keep the approved proposal, evidence, decision, and configuration references intact. Execution still needs to verify that the approval applies and that the underlying state permits the operation. If the migration changes or regenerates the proposal, obtain a fresh decision on that content. Do not let a new model reinterpret an earlier approval as authority for a different action.
