The AI Champion Who Left
Your AI project didn't fail because of the model. It failed because the one person who understood it got promoted, transferred, or quit.
There’s a pattern we see more than we’d like.
A company builds an internal AI system. It works. It’s used. It quietly handles hundreds of requests a day. Then six months later, nobody knows how it works anymore. It’s still running — but it’s untouchable. Any change risks breaking something nobody fully understands.
The model didn’t decay. The infrastructure didn’t rot. The AI champion left.
The Single-Threaded Project
Most AI projects in mid-size organizations have one person who really understands them. They made the design decisions. They know why the prompt is structured the way it is. They know which edge cases were handled and which were punted. They know the quirks.
Everyone else knows the feature. Nobody knows the system.
When that person leaves — gets promoted, moves teams, quits — the project enters a strange limbo. It keeps running. Nobody has the context to change it. Gradually it becomes technical debt by default, not by neglect.
This Is Not an AI Problem
It’s an organizational problem that AI makes worse.
Traditional software at least has code that can be read. Prompts, eval criteria, retrieval logic, model behavior — these are often undocumented, embedded in someone’s head, and non-obvious to anyone reading the repo for the first time.
The surface area of “things only one person knows” is much larger in AI systems than in conventional software. And the failure mode is harder to detect — the system keeps producing output, even when it’s wrong.
What Resilience Actually Looks Like
The fix isn’t hiring better people or hoping champions stay. It’s treating your AI system like something that needs to outlive the person who built it.
That means:
Decision logs, not just code comments. Why was this prompt written this way? Why was this retrieval strategy chosen? Why is this threshold 0.7 and not 0.5? Write it down.
Evals that encode intent. A test suite that captures what “correct” looks like is institutional memory. Without it, nobody can safely change anything.
Runbook for the weird cases. What happens when the model starts returning garbage? What’s the escalation path? Who owns it? Document the answers before you need them.
At least two people who understand it. If only one person can explain the system in a postmortem, you have a dependency, not a team.
The Real Risk
The AI project that depends on one person isn’t an AI problem you’ll solve with better infrastructure. It’s a people and process problem that will surface the moment that person’s calendar changes.
Build systems that survive turnover. That’s what production-ready actually means.
The model doesn’t leave. The person who knows how to use it does. Plan for that.