How a Folder System Keeps Your AI Workflows Working When the Model Changes

If your business uses AI for proposals, content or customer research, the model doing that work will eventually be switched off. Providers make this official. Microsoft's Azure documentation says Azure OpenAI models are continually refreshed with newer and more capable models. As part of this process, we deprecate and retire older models. The two stages are different. A deprecated model still works, but it is no longer recommended and has a retirement date. A retired model is gone: requests to it return an error.

Retirements are frequent. Independent trackers report that on 30 November Anthropic retires Claude Sonnet 4.5, and on 11 December OpenAI retires GPT-5 and o3. You also don't get much warning. Azure promises at least 60 days' notice before model retirement for GA models. One analysis of Anthropic's notices found that since December 2025 every notice has given 60 to 62 days. That figure comes from a third-party tracker, so check your provider's own page for the dates that apply to you.

So the real question is how much of your workflow breaks when the model changes, not whether it will change.

Most owners assume a newer model is simply a better version of the old one. Sometimes it is. But prompts that worked well on one model can behave differently on the next. In one published case study on prompt migration, a company's prompts were stable on GPT-4-32k, but the tests started failing with GPT-4.1 and GPT-4.5-preview, with 98% and 97.3% of the tests passing respectively. The authors traced the cause to the newer model following instructions more literally. They quote OpenAI's guidance that "existing instructions are followed more closely and implicit rules are no longer being as strongly inferred".

A Claude migration guide describes the same pattern: a system prompt written to overcome an older model's reluctance ("CRITICAL: you MUST use the search tool") can over-trigger on a newer one. The same words produce different behavior.

None of this means you have to rebuild from scratch. It means you need two things: a workflow you can easily see and edit, and a habit of testing it. Anthropic's own model deprecations page advises teams to test your applications with newer models well before the retirement date of your current model.

Interpretable Context Methodology, or ICM, is a way to organize AI workflows with ordinary folders. It was introduced in March 2026 by Jake Van Clief and David McDermott of Eduba and the University of Edinburgh. It uses numbered folders to represent workflow stages, plain markdown files to carry prompts and context, and local scripts to handle mechanical tasks that do not require AI involvement.

The authors say the core idea is simple: if the prompts and context for each stage of a workflow already exist as files in a well-organized folder hierarchy, you do not need a coordination framework to manage multiple specialized agents. You need one orchestrating agent that reads the right files at the right moment. The method is specifically designed for sequential workflows that require high levels of human oversight. Writing a newsletter in steps (research, then draft, then edit) is a good fit.

The most useful part for a business owner is how ICM separates two kinds of files. Layer 3 holds reference material (the factory), stable across runs; Layer 4 holds working artifacts (the product), unique to each run. Your brand voice guide, style rules and conventions belong in the first group. Each week's drafts belong in the second.

To be clear about the evidence: the ICM paper is about simplifying how AI workflows are run. It doesn't claim to make model migration painless. What follows is our reading of how its design helps when the model underneath changes.

Your know-how sits in files you own, not inside a vendor's product. Your voice guide, step-by-step instructions and examples are plain text. When the model changes, those files stay the same. You point the new model at the same folder.

You can see exactly where a problem is. ICM is built so that a person can open any folder and see what state the system is in. If the new model's drafts suddenly sound off, you check the drafting stage's output folder and adjust that stage's instructions. You don't have to dig through a pile of code.

You can fix a stage by hand. If a human edits a file in 01_research/output/ before running stage 02, the agent picks up the edited version. While you're adjusting to a new model, your team can correct output at any step without stopping the whole process.

Fixes go in one place. Because the rules sit in shared reference files, a needed change, such as spelling out an instruction the new model no longer infers on its own, is one edit that every run picks up.

A folder system doesn't make a migration free. Your files will survive, but they won't automatically produce the same results. As one debugging guide notes, model behavior can change across model versions even when the prompt remains the same. You still need to run real examples through the new model and compare the results.

File names can also tie you to one vendor. The original ICM setup uses a root file typically named CLAUDE.md, which is Claude's naming convention. A more neutral option is AGENTS.md, which describes itself as a simple, open format for guiding coding agents, used by over 60k open-source projects. Its focus is coding tools, but the idea carries over: AGENTS.md is an open format that many agents read, while CLAUDE.md is specific to Claude Code. They do the same job, and a CLAUDE.md can pull in your shared instructions with a single @AGENTS.md import.

ICM is also new. There's a paper, open-source templates and community guides, but we found no independent studies measuring how much time it saves during a migration. Be wary of anyone quoting precise numbers.

1. Find out which model each workflow uses and check its retirement date on the provider's official page.
2. Keep a few real past inputs and approved outputs in each workflow folder as test cases.
3. When a new model comes out, change only the model. One guide recommends holding the prompt, inputs and context constant and changing the model only, and adapting prompts only after you understand the baseline difference.
4. Fix the stage that fails by editing its instruction file, rerun it, and record what you changed.

When you build workflows this way, a model retirement becomes an afternoon of checking and small edits. Your process, your voice and your team's know-how stay in your folders when the model changes.