If you only have a minute, here is what you need to know.
- Frontier models now ship roughly every one to three months. The fear that anything you build will be obsolete before it ships is rational, but it points at the wrong layer.
- Your agent stack changes at three different speeds. The model churns every few weeks. The harness around it changes a few times a year. Your MD files, the intent, barely change at all. The further from the model you invest, the longer your work lasts.
- The instruction layer already proved its durability. AGENTS.md became an open standard stewarded by the Linux Foundation, adopted across 60,000+ repositories, and readable by nearly every major coding agent.
- Markdown intent files do not depreciate when a new model lands. They appreciate. A smarter model executes the same intent better, for free.
- The builders paralyzed by the pace are optimizing the wrong variable. Stop betting on a model. Invest where the half-life is longest: the harness that enforces your rules, and above all the intent those rules encode.
The anxiety that's freezing good teams
I keep hearing the same anxiety from smart engineering leaders, and it sounds reasonable until you look at what's actually underneath it.
It goes like this: "The technology is moving so fast that whatever we build now will be obsolete by the time we ship it. Why invest six months in an agent system when the model it runs on will be replaced twice before we're done?"
The pace is real. Between November 17 and December 11 of 2025, four labs shipped their most capable models inside a single twenty-five day window. Grok 4.1, Gemini 3, Claude Opus 4.5, and GPT-5.2, one after another. The cadence didn't slow in 2026. The frontier labs are now releasing flagship models roughly every one to three months.
Four frontier models in twenty-five days. The release cadence is now every one to three months.
Source: model release trackers, late 2025 through mid 2026
So the fear is grounded in a true observation. But it draws exactly the wrong conclusion from it.
Your stack changes at three speeds, not one
When you build an agent system, you are not building one thing. You are building three, and they change at completely different rates. The anxiety comes from watching the fastest-moving layer and assuming everything moves at that speed. It doesn't.
The model is the fastest layer. It is the reasoning engine. It churns every few weeks, you have zero control over it, and a better one is always coming. Half-life measured in weeks. You did not train it and you cannot pin it forever, so betting your effort here is the one move that actually does get obsoleted.
The harness is the middle layer, and most people forget it's even there. The harness is everything you build around the model: the hooks that fire on every action, the validators and schemas, the tool permissions, the orchestration that decides what the agent is allowed to do. You own this layer. It changes, but on the order of a few times a year, as your tooling matures and as you find new rules worth enforcing. A single enforcement hook you write today will outlive a dozen model releases. This is the layer that turns a hopeful instruction into a guarantee, and I've argued before in the harness playbook and why the harness is the multiplier that it's where the real engineering lives. Half-life measured in months to years.
Your MD files are the slowest layer, and that's the whole point. This is the intent. The approval rules. The naming conventions. The definition of done. The architecture decisions you've already litigated. The format your finance team expects. The things an agent must never do. In a modern setup, all of that lives in markdown: a CLAUDE.md or AGENTS.md at the repo root, a folder of skills, the policy the harness enforces. None of it changes when a lab ships a point release, because how your organization works did not change. Half-life: indefinite.
Stack those up and a pattern falls out that should reorganize where you spend your effort. The further from the model you invest, the longer your work lasts.
The model is the engine. The harness is the chassis you bolt it into. Your MD files are the route. You swap engines every season. You rebuild the chassis a few times a year. The route, where you are actually trying to go, does not change because you dropped in a faster engine. A new model lands, you swap it in, and your instruction files do not know or care. The intent you encoded last quarter still describes how your company operates.
The instruction layer already won the durability argument
This is not a prediction. It already happened, and it happened fast.
AGENTS.md started as a convention inside one tool. Within months it became an open standard, now stewarded under the Linux Foundation, adopted across more than 60,000 open source repositories. GitHub Copilot, Cursor, Codex, Windsurf, Zed, Amp, Google's Jules and Gemini all read it. Claude Code reads its own CLAUDE.md and falls back to AGENTS.md when there isn't one.
60,000+ repositories standardized on AGENTS.md. The same file is read by nearly every major coding agent.
Source: Agentic AI Foundation, Linux Foundation
Sit with what that means. The same plain markdown file that describes your intent now survives not just a model swap, but a tool swap. You can change your reasoning engine and change your agent platform, and the document that encodes how your organization works carries over untouched. The volatile layer got more volatile. The intent layer got more portable. Those two trends moved in opposite directions on purpose.
When the industry standardizes on a file format the way it standardized on CONTRIBUTING.md or CHANGELOG.md decades ago, that is the market telling you which layer is stable. You do not standardize the thing that changes every three weeks. You standardize the thing you intend to keep.
What actually depreciates, and what compounds
Not everything you write down is durable, and it's worth being honest about the difference.
What depreciates fast is anything tuned to a specific model's quirks. The prompt that only works because you discovered GPT-5.2 responds to a particular phrasing. The scaffolding you built to route around a context window that the next release quadruples. The clever workaround for a tool-calling bug that gets patched. That work has a shelf life measured in weeks, and the anxious builders are right to not want to sink a year into it.
This cuts straight through the harness, too. The model-specific glue you write into it, the prompt-shaped workarounds, ages with the model. The enforcement logic underneath, the rule itself, compounds right alongside the intent it protects. Same layer, two different half-lives, and worth knowing which part of your harness you're actually writing.
What compounds is intent. A skill that encodes how your senior engineer reviews code is true regardless of which model reads it. A policy that says infrastructure changes require three approvals is true regardless of inference speed. A specification format your organization agreed on does not expire when benchmarks climb. I wrote about this from the knowledge side in Why Skills Are the Missing Link, and from the enforcement side in Why Your Agent Forgets the Rules. The throughline is the same: the encoding of how your organization operates is the asset. The model is just the current best way to execute it.
Here is the part that should change how you feel about the next release. When a smarter model ships, your existing intent files don't lose value. They gain it. The same skill, the same policy, the same specification gets executed more reliably by a more capable engine, and you did nothing. You wrote the intent once. Every model release after that is a free upgrade to how well your intent runs.
Prompts tuned to a model depreciate in weeks. Intent compounds. A better model executes your existing MD files better, at no additional cost to you.
The paralysis is the only real risk
Picture two teams looking at the same release calendar.
The first team decides to wait. The dust is moving too fast, so they hold off on anything serious until the frontier settles. They run small experiments, nothing structural, nothing written down. Six months later the frontier has not settled, because it never does, and they have the same blank repository they started with. They have nothing to show a new model except their continued indecision.
The second team accepts that the model layer will churn and decides to build the layers that won't. They spend those six months writing down intent and hardening the harness around it. Their coding standards, their review criteria, their architecture decisions, their guardrails, all encoded as skills, policy, and enforcement hooks. They swap through three model releases during that period without rewriting any of it. Each swap makes their system quietly better.
At the end of six months, the first team is waiting for certainty that will never arrive. The second team has a compounding library of organizational knowledge that improves itself every time a lab ships. The fast-moving technology did not punish the team that built. It punished the team that waited.
The pace of model releases is not an argument against building. It is an argument against building the wrong layer. The builders who feel the anxiety most acutely are usually the ones picturing themselves hand-tuning prompts against a model that's about to be retired. That work is genuinely fragile. The answer is not to stop building. It's to build one level up, where the work lasts.
What to write down this week
Write your AGENTS.md or CLAUDE.md first. Put it at the root of your most active repository. Capture the things a competent new hire would need explained: how you build, how you test, what "done" means, what's off limits. This is the single highest-leverage file you can write, and it's portable across nearly every tool by design.
Turn one expert's process into a skill. Pick the most repeated judgment call your team makes, code review, incident triage, spec writing, and encode how your best person does it. That tribal knowledge stops living in one head and starts running on every model you adopt.
Write the rules down as policy, where the harness can enforce them. The constraints that must hold regardless of which model is reasoning, security boundaries, approval gates, data handling, belong in a hook or validator that checks every action, not in a prompt you hope the model remembers. The rule goes in the MD file so the intent is clear. The enforcement goes in the harness so the rule actually holds.
Keep it model-agnostic on purpose. When you catch yourself writing an instruction that only makes sense for one specific model's behavior, flag it. That's the depreciating layer leaking into the durable one. Describe the intent, not the workaround.
The models will keep coming. One to three months apart, indefinitely, each one better than the last. You can treat that cadence as a reason to freeze, or as a reason to build the things every new release rewards.
Your MD files are not a bet on a model. They are a record of how your organization works. That record was true before the last four releases, it's true now, and it'll be true after the next four. The engine changes constantly. The harness changes occasionally. Intent doesn't go out of style.
Matthew Kruczek is Managing Director at EY, leading Microsoft domain initiatives within Digital Engineering. Connect with Matthew on LinkedIn to discuss building a durable intent layer for your organization.
References
- Vertu. "The AI Model Race Reaches Singularity Speed: Nov/Dec 2025 Releases." 2025. vertu.com
- LLM-Stats. "AI Updates Today (June 2026): Latest AI Model Releases." 2026. llm-stats.com
- Morph. "AGENTS.md Spec (2026): Recommended Sections + AGENTS.md vs CLAUDE.md vs .cursorrules." 2026. morphllm.com
- DeployHQ. "CLAUDE.md, AGENTS.md & Copilot Instructions: Configure Every AI Coding Assistant." 2026. deployhq.com
- Anthropic. "Equipping agents for the real world with Agent Skills." October 16, 2025. anthropic.com
