Prompts that work on multiple models: how to write them

A written and calibrated prompt on one model rarely yields the same on another. Usually still produces something sensible — recent models are all capable — but the format shifts, some constraints are ignored and quality on difficult cases changes unpredictably.

The problem is practical, not theoretical: catalogs move quickly, prices change, a model can be withdrawn or overtaken by a cheaper one. If the work done on the prompts is tied to only one provider, each change becomes a migration project.

The solution is not to write generic and vague prompts, which work poorly everywhere. It is separate what describes the task porta portable by definition — from what is calibration on a specific model.

What really changes from one model to another

Not everything behaves differently. It is better to know where to expect surprises.

The most insidious line is tone and verbosity: the models have different inclinations on how much to lengthen and how much to preface. A prompt that says nothing about it gets different results everywhere, and the difference is only noticeable when someone compares the outputs.

The five rules that make a portable prompt

1. Describe the task, not the behavior of the model. "Extract expiration dates and return them in chronological order" travels everywhere. An instruction built to circumvent a known flaw of a precise model, no.
2. Secure the format in a verifiable way. Fields, order, what to write when a data is missing. If output is to be read by another system, declare the structure instead of hoping it will be sorted.
3. From examples, not adjectives. "Reply Professionally" means different things for different models. Two examples of correct answer are worth more than five lines of description.
4. Separate instructions and data. Keeping "what you have to do" apart from "what you do it about" reduces misunderstandings and makes it easy to change just one thing.
5. Always predict the safe exit. A line that authorizes you to say that information is not there. It is the most effective defense against invented answers, and works on all models — see How to avoid hallucinations.

The two-layer structure

The most practical way to organize yourself, when you use or plan to use more than one model.

The practical rule: if a prompt line It would stop making sense on another model, it belongs to the specific layer. Everything else is in the core. So when you change model you rewrite ten percent, not everything.

Keeping two completely separate prompts instead seems simpler at first and becomes a problem at the first change in the process, because each change has to be made twice — and one of the two is eventually forgotten.

How the transition from one model to another occurs

The comparison must be done methodically, otherwise it remains a sensation.

• Use the same sample of real cases, at least fifty, including difficult ones
• Use the same criterion of correctness, written before looking at the results
• Run on both models without retouching the prompt between executions
• Count Outcomes: correct, wrong, ambiguous. Don't read two answers and decide
• Look where they're wrong differently: that's where the specific layer is needed
• Repeat the test when a new version comes out: even a minor update can move the results

The typical result is that the two models fare the same way on normal cases and diverge on strange ones. It's exactly the information you need: it says how much work it costs to get through, before you have to rush it.

The three differences that most often break a passage

When a prompt stops working on another model, in practice the cause is almost always one of these three.

The shape of the output. It is the most frequent and the most annoying case, because the content is right but the downstream system breaks down: an extra word, a courtesy premise, a slightly different structure. It is prevented by declaring the structure instead of describing it in words.

Uncertainty management. Faced with an ambiguous case, one model asks for clarification, another chooses the most likely interpretation, a third signal the doubt in the answer. They are three reasonable and incompatible behaviors: you have to decide which one you want, and write it down.

The length. For the same instructions some models tend to lengthen, others to synthesize. If the length counts unaa product description, a message to a customer —it must be indicated in a measurable way, not with adjectives.

There is a useful side effect: correcting these three points also improves the starting model. These are flaws that were already there, made visible by the comparison. It is one of the reasons why trying a prompt on a second model is convenient even when you have no intention of changing nessunathe same principle as the comparison between Claude, GPT and Gemini.

Practical examples

Service company, classification of incoming mails. The prompt had been fine-tuned on a model and worked well. Testing it on a cheaper model, the classification remained correct but the output changed shape: sometimes a single word, sometimes a sentence of explanation. The downstream system expected only one word and went wrong. The correction was declare the exact format and add two examples: from then on both models produced the same shape, and the transition to the cheaper one became possible.

Technical study, data extraction from specifications. As a model, the quality remained similar in average but worsened on documents with tables. By separating instructions and data and adding an example of a document with a table, the gap closed almost entirely. The useful work was the Common Core, and also improved the starting model.

Mistakes to Avoid

• Writing vague prompts to make them portable. They work poorly everywhere: portability comes from precision on the task, not genericity.
• Copying formulas designed for a specific model. I'm the part that breaks first.
• Not declaring the format. It is the most common cause of breakages when changing patterns.
• Comparing on different examples. Without shared sample the comparison says nothing.
• Giving a prompt for good after a version update. Even a minor version can change the inclinations.
• Binding the process to proprietary functions without knowing how much it would cost to replace them.

How to apply it in the company

For an SME this translates into three habits, all at almost zero cost.

1. Keep prompts out of personal chats. In a shared place, written down what they are for and how they occur to work.
2. Mark which part is model specific. Just two lines of comment: when you change, you will know what to touch.
3. Keep the test sample. It is the only tool that makes a migration a half-day verification instead of a leap into the dark.

This is also the premise that makes the use of Different models for different tasks: the light model for sorting, the most capable one where it really needs to be. Without portable prompts that strategy costs too much to maintain. And when prompts go into processes that run on their own, they become full-fledged system components —the transition to AI Agents.

Conclusion

A portable prompt is not a generic prompt: it is a prompt precise on task and neutral on supplier. Describe what needs to come out, show it with examples, state the format, predict the "I don't know" — and keep aside, in a separate block, the few lines that speak to a specific model.

The advantage is not seen on the first day. It is seen when the price changes, a better model comes out or yours is withdrawn: then the difference is between half a day of verification and weeks of makeover. To decide when to move, see when to change AI model.

If you want to go from testing with ChatGPT to an AI system integrated into business processes, Giallo Studio custom designed agents and automations.