Executive Summary
Agent rules files are software, and they fail like software. Skills, prompt configurations, and instruction files now decide what a coding agent produces, yet teams commit them and never test them. Behavior shifts silently after a model update and nobody can say why.
The Context Development Lifecycle is the fix, and it has four phases. Generate is writing the skill. Evaluate is testing it, from linting the front matter to running a known task against it. Version gives the artifact a change log and an owner, so a model release can be diffed against a known state. The operational phase monitors whether the skill still produces the expected result in production. Three questions drive all of it. Is the skill current, does the model react to it correctly, and are you feeding context the model already knows? A broken rules file does not just produce worse code. The expensive failure is code that is wrong and arrives looking certain.
Skills, agent configurations, prompt instructions, and rules files now determine what your coding agents produce. They shape every line of generated code, every architectural decision, and every convention the agent follows or ignores. Functionally, they are software. Almost nobody treats them that way.
Teams write a skill, commit it to a repository, and never test whether it still works after a model update. Configurations get copied across teams without versioning. Rules files drift out of sync with the codebase they describe. When something breaks, the signal is a developer noticing odd output and complaining in chat.
Context needs a lifecycle
The framing that fixes this is the Context Development Lifecycle. It is not about context window management or cramming more tokens into a prompt. It is about managing the quality of the pieces that go into the context window.
Three questions drive it. Is a skill up to date? Does the model actually react to it correctly? Are you feeding the model context it already knows? Answer them honestly and you will find most agent setups have never been tested at all.
The lifecycle has four phases, and they map directly onto what teams already do with code.
Generate is where everyone starts. Writing skills, building prompt configurations, setting agent rules. It is the equivalent of writing code, and it is where most of the time goes today.
Evaluate is testing. Check that the front matter lints, that the syntax is not too long, that the instructions are unambiguous. At the sophisticated end you run scenarios against the skill, load a known task, and confirm the agent behaves the way you intended.
Version, monitor, repeat
The third phase is version. A skill is software, so it gets a version, a change log, and an owner. When a model release changes behavior, you have a record of what your setup looked like and can diff it.
The fourth phase is operational. Monitor whether the skill still produces the expected result in production. A rules file that worked with one model release can silently break with the next. If you are not checking, you are blind to it.
The straightforward read is that context artifacts deserve the same discipline as application code. They get linted, tested, reviewed, versioned, and monitored. That is not overhead. It is the only way to trust them.
This is especially true as agents take on more autonomous work. The more a model decides on its own, the more the rules that guide it matter. A poorly tested rules file does not just produce worse code. It produces confidently wrong code, which is harder to catch.
Context is the new code
The takeaway is a shift in how teams think. If prompts, skills, and rules determine what your agents build, then they are the most important code you write. And like all important code, they get a lifecycle.
Teams that adopt this find their agents become reproducible instead of mysterious. An agent that explains itself, is testable, and is versioned is an asset. An agent that just works some days is a liability you only discover when it fails.
There is a reason this gets skipped. Skills and rules files feel like prose, and prose feels like it does not need tests. But the moment a model reads a rules file and changes its behavior, that file is executable logic, whether it looks like code or not. The gap between a working skill and a broken skill is invisible until a task goes wrong.
Treating context artifacts as code solves a second problem too. It makes agent behavior reproducible. A team that can point at the exact skill version that produced a build can debug it, roll it back, and learn from it. A team that cannot is debugging a ghost.
That is the real argument for the lifecycle. It is not rigor for its own sake. It is the difference between an agent you can reason about and an agent you can only hope about.
Agent infrastructure is the development layer of the AI Infrastructure report, which covers how a model becomes a service with an owner, an evaluation gate and a cost line.
Related reading. Agentic Resource Discovery Wants to Give Agents Their Own DNS. Cortex Builds an Internal Developer Portal That Answers Your Own Questions. Your Coding Agent’s Biggest Bill Is the Data You Feed It. AI Infrastructure Runs on Four Layers. Most Break Below the Model..
Get the next one before it is old news
Independent analysis of cloud-native infrastructure, Kubernetes and data centre economics. No vendor spin.

[…] Related reading. We wrote about giving agents their own resource discovery layer, about the discovery gap MCP left open, and about why agent rule files are code. […]