Last week, within minutes of each other, Anthropic released Claude Opus 4.6 and OpenAI released GPT-5.3-Codex. The pace of foundation model releases shows no sign of slowing. For enterprise teams building agentic workflows, this relentless cadence raises an uncomfortable question. How much of what you build today will survive the next model generation?

New models bring improvements in reasoning, instruction-following, and domain knowledge. But they also bring changes in behavior. A prompt that achieved 95% success on one model may regress to 80% on its successor, not because the new model is worse, but because it interprets instructions differently. The more you have optimized your prompts for a specific model’s quirks, the more fragile your investment becomes.

The organizations that navigate model transitions gracefully are those with a solid control plane for their agentic processes. Here are some ideas on how to build for durability.

The Durable Layer: What You Own 

Certain components of your agentic infrastructure will outlast any model generation. Your tool integrations, the APIs you call, the authentication mechanisms, the data transformations between your agents and external systems don’t care which model is orchestrating the calls. Your knowledge sources and retrieval infrastructure are similarly model-agnostic (though re-embedding with newer embedding models may improve retrieval quality over time). 

Most importantly, your workflow orchestration logic reflects how your organization operates. The branching rules, escalation criteria, handoff conditions, and compliance requirements represent institutional knowledge encoded in executable form. This is knowledge that transfers well. 

The guidance here is straightforward. Invest deeply in what you know, not what the model knows. Document your business logic rigorously. Treat it as a long-term asset. The more clearly you have articulated your decision rules independent of any particular model’s reasoning, the more portable your investment becomes. 

The Fluid Layer: Prompts as Configuration 

Prompts are the fragile layer. When you optimize prompts through iterative testing, you are often compensating for specific model weaknesses or exploiting specific model strengths. For example, you add scaffolding to prevent reasoning failures the model tends to make. Or perhaps you structure outputs in ways that yield reliable parsing from this particular model and include examples calibrated to how this model generalizes. 

When you swap in a new model, several things happen. The weaknesses you were working around may no longer exist, meaning your scaffolding becomes unnecessary complexity. The new model may have different failure modes you have not anticipated. And the new model may interpret your carefully-tuned instructions differently. 

This requires a mindset shift. Treat prompts as configuration, not infrastructure. Prompts feel like creative work, and the temptation is to treat finely-tuned prompts as valuable IP. However, their actual role is to act as calibration for a specific model at a specific moment. Expect to revisit them and budget for it. The goal is prompts that are good enough with minimal complexity, not prompts that extract maximum performance through elaborate engineering.  

Documenting Your Business Logic 

Your business process documentation needs to be readable by the business stakeholders who own and maintain the logic, while also being precise enough for technical teams to translate it into agent configurations. Most organizations do one or the other badly.

• Keep it separate from the implementation. Do not let your business logic documentation live only inside your agent builder or your prompt files. That creates circular dependency where you cannot understand what the system is supposed to do without reverse-engineering what it currently does. Maintain a canonical source of truth in a system your business stakeholders can access and update: Confluence, Notion, SharePoint, or even well-organized Google Docs. The agent configuration should reference this documentation, not be the documentation. 
• Structure it by decision, not by workflow. Workflows change, but the underlying decisions are more stable. “When should we offer a refund without supervisor approval?” is a decision that might appear in five different workflows. Document it once, clearly, with the business rationale and the boundary conditions. Then your workflow documentation references the decision rule. This approach also surfaces inconsistencies where the same decision is being handled differently in different contexts. 
• Capture the “why” alongside the “what.” “Escalate to Tier 2 if the customer mentions legal action” is a rule. But why? Is it a liability concern? A de-escalation strategy? A regulatory requirement? The rationale determines how the rule should evolve when circumstances change, and it provides essential context for whoever is translating the rule into agent behavior. A year from now, someone will look at a rule and wonder if it is still relevant. The reasoning helps them decide. 
• Version it like you would code. Business logic changes. You need to know what the rules were when a particular decision was made, both for audit purposes and for debugging agent behavior. Date your changes and keep history accessible. 

The Critical Role of Evaluation 

Build evaluation before you build automation. This is the piece most enterprises skip because it feels like overhead. But your ability to quickly assess whether a new model handles your workflows, where it fails, and how severely, is what determines your upgrade velocity. 

If you cannot measure performance systematically, you are locked into whatever you built first because change becomes too risky. The workflows that required the most prompt engineering are exactly the ones with the highest migration cost. The “easy” tasks that worked with minimal prompting will likely just work with new models. The hard cases where you spent weeks getting the success rate from 70% to 95%? Those will probably regress, and you will need to re-tune. 

Good evaluation frameworks are the asset that lets you stay current without starting over. They tell you quickly which prompts need attention, which workflows have regressed, and where you can confidently upgrade. Without them, you are flying blind. 

Building for the Long Term 

The release of Opus 4.6 and GPT-5.3-Codex in the same week is not an anomaly, but rather a sign of the times. Enterprise teams building agentic systems must architect for a world where the model layer is continuously evolving. The organizations that will thrive are those that maintain clean separation between “this is how our business works” and “this is how we are prompting the current model to execute it.” Your business logic, decision rules, and evaluation frameworks are the durable assets worthy of deep investment. Your prompts are configuration files, tuned for the moment, expected to change. If you can get this distinction right, and every new model release becomes an opportunity for improvement rather than a threat to your investment. 

Categories: Articles