Keeping it working after the model changes
Keeping it working after the model changes is the practice of treating an agent’s prompts, tools, routing logic, and model selection as versioned production behaviour, protected by evals. It lets you replace or upgrade a model by measuring application-specific regressions before rollout, rather than rediscovering broken prompt assumptions in production.
A model change is not like swapping a library for a strictly compatible implementation. The new model may follow instructions differently, choose tools at different moments, format output less predictably for your parser, refuse cases the old model handled, or recover from ambiguity in a new way. The problem is that your agent relies on local behavioural contracts, many of which were discovered by trial and error rather than written down.
The practical mechanism is a compatibility test suite for the agent. You collect representative tasks, previous failures, expected tool calls, valid response shapes, safety constraints, and latency or cost expectations. Then you run the current model and the candidate model through the same harness, compare the outputs, and inspect where behaviour changed. The result is not a single score, but evidence for whether to adjust prompts, schemas, routing, or rollout policy.
This costs engineering time and it never proves the agent is correct for every future input. Good evals are samples, not a mathematical guarantee. They also need maintenance as the product, tools, and user behaviour change. The trade-off is deliberate: you spend effort preserving the behaviours that matter to your application, instead of trusting broad benchmark improvements or informal manual testing to catch local breakages.
Engineers meet this during model deprecations, provider migrations, prompt rewrites, tool schema changes, and attempts to use a newer model for cost or capability reasons. In practice it looks like checked-in eval cases, golden examples from incidents, assertions over structured outputs and tool calls, and rollout decisions based on regressions. A common misunderstanding is that a smarter model is automatically safer to deploy. It depends on your contracts.
Common questions
- What should go into an eval set for a model upgrade?
- Use examples that represent real production behaviour: common tasks, awkward edge cases, past incidents, expected tool calls, required output formats, refusal boundaries, and domain-specific safety rules. The set should include cases where the old prompt barely worked, because those are often the first places a new model exposes hidden assumptions.
- Is this just prompt testing?
- No. Prompt text is only one part of the contract. The eval should also cover tool selection, argument shape, routing decisions, structured output, ambiguity handling, latency, cost, and policy-sensitive behaviour. A model can answer well in prose while still breaking your agent by calling the wrong tool or returning unusable JSON.
- What do you do when the new model improves some cases and regresses others?
- There is no automatic answer. You can revise prompts, tighten tool schemas, keep the old model for specific routes, send only part of traffic to the new model, or accept the regression if the trade-off is worthwhile. The point of the eval harness is to make that decision explicit before users discover it.