Restore the previous behaviour after a model regression

Identify the release behind the report

Capture the request or run identifier and load its model, prompt, tool and retrieval configuration. Determine whether the behaviour changed after the release or whether a source update, tool failure or traffic shift explains it.

Reproduce the issue with a controlled fixture where possible. Preserve the original evidence under the appropriate access rules. A screenshot of the answer may omit the field, source or tool decision needed to locate the failure.

If the regression can cause consequential effects, disable or restrict the affected capability while investigating. A broad model rollback may be appropriate, but a capability-level control can provide faster containment when only one operation is affected.

Check the restoration target

Confirm the previous configuration remains available and compatible with current tools and saved state. Do not assume an old model reference still behaves identically or that an old prompt can handle a newly introduced schema.

Run the known regression and a small set of essential tasks against the restoration target. This verifies the path you are about to use without turning the incident into an open-ended benchmark exercise.

If no compatible prior configuration exists, use the documented limited or manual fallback. Avoid claiming restoration when the application is actually running a new, untested combination.

Handle work already in progress

Identify runs started on the candidate and decide which can finish, pause or resume under compatible execution code. Preserve operation identifiers and approvals for tasks that may already have caused effects.

Do not replay an entire agent conversation on the old model as a substitute for recovering durable state. That can repeat mutations or reinterpret the user's request.

Invalidate or partition cached outputs where they would continue serving the regressed behaviour after routing changes. Check both new requests and previously saved results according to the product's historical-answer policy.

Verify and record the incident

Confirm traffic is using the intended configuration and inspect the affected task category. Watch for retry storms, unresolved operations and misleading user messages created during the transition.

Record the regression mechanism and add a synthetic reproduction to the evaluation set. Explain whether the release evidence missed a task, the evaluator missed an error or production conditions differed from testing. This turns restoration into a concrete improvement to the next release decision rather than another prompt adjustment without history.