Why Nobody Will Touch That Process
Every company has a version of this story. The person who really understood how purchase approvals worked, or claims intake, or vendor onboarding, leaves. The process keeps running. But nobody will touch it. New situations get handled with workarounds instead of fixes. A year later there's a proposal to "rebuild it properly," which mostly means rediscovering, expensively, what the person who left already knew.
We treat this as a documentation problem. Write more wikis, record more Looms. It never works. A forty-year-old essay about software explains why.
In 1985, Peter Naur argued that the real product of programming isn't the code. It's the theory, held by people, of how the software maps to the world: why it's built this way, and what will break if you change it. The code and the docs are artifacts produced by people who hold the theory. You can read every line of both and still not understand the theory.
When the people who hold the theory leave, the software still runs, but nobody can safely change it. Naur says it dies. Each change degrades it further, because no one fully understands it. Eventually someone calls it legacy and proposes a rewrite.
If you've operated software, you've watched this happen. I spent ten years building workflow software, and saw this over and over. The reason it's hard to change workflows is almost never the tooling.
No one understands the full process¶
Nothing in Naur's argument is really about code. A business process starts as a theory in one or two heads. Then it grows: across teams, across tools, through a hundred exceptions the owner learned one new situation at a time.
When many people are involved, the theory doesn't grow in a single person. It fragments, disguised as "tribal knowledge." The finance lead knows why anything over $5,000 gets a second look. The ops manager knows why the Airtable has that weird column. Soon no one can explain the process end to end.
If no one can explain it, no one can safely change it. So changes route through the one or two people trusted to touch it, and bigger overhauls never happen. The process still runs, but can't evolve.
The tools we reach for make it worse¶
Automation tools take the theory that was in someone's head and bury it in the wiring of six connected apps. A zap chain tells you what happens. It can't tell you why. When it breaks, figuring out the fix takes hours, and the fix is usually another patch on top.
Vibe-coded internal tools are the same mistake, faster. The code gets written, the theory-building never happens. It ships, it runs, and from day one nobody can explain how it works.
AI agents, on their own, keep even less. They use judgment, yes, but it happens fresh each run and is kept nowhere. A skill file or a memory doesn't fix that. It's a pile of text sitting next to the process, not part of it. You can read that a rule exists. You can't ask which run put it there, who decided, or what it was protecting against.
All three share a blind spot. They ship the process and throw away the why.
The coworker who doesn't leave¶
If you and a coworker built a process together over a year and worked through the exceptions, would you say the theory was held by both of you? Of course you would.
Now make the coworker an AI with a deep understanding of that process, one that was there when you worked out why step four exists and did the building to set it up. When you propose making a change, it's still there to remember to re-run a scenario you've forgotten, one that would have blocked your team. Even when someone new contributes to a process, its still there.
Take the purchase approvals from the top of this post. Anything over $5,000 goes to the finance lead. She leaves. A year later someone wants to raise the limit to $10,000 and has no idea where $5,000 came from. Today that's a coin flip: leave it alone, or change it and find out. Instead they ask, and learn it was tied to a budget cycle that ended two quarters ago. So they raise it, knowing what they're doing.
A better way to run a process¶
With Malleable, the your process, documentation, and memory of every collaborative session that led to it are one. An agent runs the process and proposes changes. People correct it, in feedback and in review. The theory stays current instead of frozen at rollout, and it keeps getting built by the people who own the process and the AI that runs it.
No rebuild proposal a year later. Someone leaving is just someone leaving.
Thanks to Steve Krouse, who first pointed me to Naur's essay.