The prompt that broke three teams.
In month one, the AI instructions your team writes are notes. By month four they are infrastructure. They are still being edited like notes.
- A prompt, a skill, or a workflow is a shared dependency. Other work quietly relies on its exact wording.
- Most companies edit theirs in place. That leaves no history, no owner, no way to tell whether a change helped, and no clean undo.
- Capi turns every change into a published version instead of an edit. Old versions stay exactly as they were. What your teams receive is a pointer that can move forward or back in one recorded move.
- Everything that depends on a capability is pinned to the version it was reviewed against, so an upstream improvement arrives as a small reviewable change for each team, never as an outage.
- Before publishing, the new version is compared against the one in use, on real cases from your own past work. The result is a verdict in words, not a score.
A Tuesday in month four
Someone in marketing improves the customer email guidelines. Genuinely improves them: the new wording is tighter, warmer, and closer to how the best reps actually write. They open the doc, make the edit, and move on. Four minutes.
What they cannot see is that three other things were built on top of the old wording. The sales follow up workflow cites a tone rule that no longer exists. The support triage agent chooses a template based on a section that got renamed. The quarterly review brief drops a disclaimer it used to inherit.
Nothing errors. There is no alert, because nothing is broken the way software is broken. The output is just slightly wrong, in three places, for four days.
When someone finally notices, the investigation is the expensive part. Nobody can produce the old wording. Nobody knows exactly what changed, or who decided, or whether the change was an improvement that exposed a hidden assumption, or simply a mistake. So the safe move gets made: everyone stops touching the guidelines.
The category error underneath
AI instructions look like documents, so companies manage them like documents. One file. Edit in place. A change log if someone is unusually disciplined.
But they behave like code. Other things call them. Other things depend on their exact wording. Other things break when that wording moves.
The tools for this exact problem are forty years old and extremely well understood: version control, pinned dependencies, release and rollback, tests before merge. None of it has been applied to prompts, because until recently prompts did not look like they needed it.
The failure mode is not a crash. It is four days of slightly wrong.
Change one: you publish versions, you do not edit files
Every change creates a new version. The previous one stays exactly as it was, permanently. Nothing is overwritten and nothing is deleted.
What your teams actually receive is decided by a label: a pointer named production. Publishing means moving that pointer to a newer version. Rolling back means moving it to an older one. They are the same kind of move, both take seconds, and both are recorded with who did it and when.
That one design choice, versions frozen and only the pointer moving, is what makes every other guarantee in this post possible.
Change two: dependents are pinned, so nothing arrives by surprise
Each capability records the exact versions of the things it relies on. When something upstream gets a new version, its dependents keep receiving the version they were built and reviewed against. They keep working. That is the whole point of a pin.
Then the interesting part. Instead of a change silently spreading, or silently not spreading, every affected dependent gets its own small proposal. Capi compares the old and the new upstream version and classifies how big the difference is. Minor differences can be approved automatically under a policy you set. Significant ones wait for the person who owns that dependent.
An improvement upstream becomes a short review for each affected team, instead of an outage they discover on Thursday.
Change three: better gets checked, not assumed
One gap remains. So far, "improved" is still an opinion. Someone wrote a new version, someone approved it, and everyone hoped.
So before a version is published, Capi can run it against the version currently in use, on cases drawn from your own real work rather than a generic benchmark. Same task, both sets of instructions, results compared without knowing which is which, and compared a second time with the order swapped so that position cannot tilt the outcome.
The output is a verdict in plain words: clearly better, likely better, inconclusive, or worse. Deliberately not a score out of ten, because a score out of ten invites someone to ship a 6.8 over a 6.7 and call it progress. And if the candidate loses on a case that used to pass, the verdict is capped: no regression gets averaged away.
The verdict is attached to the version permanently. Six months later, you can still see why it was published.
Most AI governance tells you what happened. This tells you whether it should have.
Why this is the whole game
Companies do not stop improving their AI instructions because they run out of ideas. They stop because one change caused a mess nobody could trace, and after that everybody quietly leaves things alone. The instructions calcify at whatever quality they happened to have in month four, and the AI budget keeps being spent on tools that follow them.
Making change cheap, visible, and reversible is what keeps the quality curve pointing up. That is where the compounding comes from, and it is why versioning and evaluation are not back office features here. They are the product.
Capi treats your company's AI instructions the way your engineers already treat code: versioned, pinned, reviewed, measured, and reversible. The difference is that the people using it never have to think about any of that.
See it on your own team's work.
We are opening a small founding design partner cohort, limited by how much hands on onboarding we can give each team.