Almost nothing, and that is usually the answer: the model is the engine, and your team is the files. A new release swaps the engine under the hood, and it does not erase a single line of what you taught your agents.
Every time a new model comes out I get the same wave of questions, and they all smell the same: a feeling that everything went stale overnight, and that you have to start from scratch. Your knowledge did not evaporate, it simply runs on a different engine now, and most people who panic discover within one conversation that the system works exactly like it did yesterday.
What does change is how the model reads your instructions. A stronger model follows your wording far more literally, so the aggressive instructions you wrote to push the previous model along ("CRITICAL! You MUST use this tool!") start overshooting, and the agent will reach for that tool constantly, even when there is no reason to. The fix is to soften the wording, not to pile another layer of rules on top of it.
Here is what it looked like on our side: when a new model landed at half the price of the previous top tier, we did not touch a single agent file. We changed one line, which model runs by default, and then we ran one task whose result we already know by heart, and compared. That is the entire test.
Which brings the practical step, and it is also the habit I recommend most: keep one reference task. A small task from your real work, with an output you know cold (mine is always the same boring email draft). Every time something shifts under the hood you run it, you look, and within a minute you know whether anything actually changed. Without a task like that, every release feels like an earthquake, and with it, it feels like an oil change.
A prompt, on the house
A new model just launched and I want to check whether anything in my team needs to move.
Do not change anything in my files at this stage. Instead:
1. Run the reference task I am attaching, exactly the way you always do.
2. Compare the result to what I expect, and flag only real differences.
3. If there is a difference, propose the smallest possible fix. Usually that means softening an aggressive instruction, not adding rules.
At the end, give me one line: leave it as is, or change one thing.A new model is worth one small test, and the difference between that and a rebuild is exactly the habit worth adopting today.
