Intent Debt: the category has a name now
A researcher just gave a problem teams have felt for years the language they were missing.
Intent debt is the missing or eroded rationale behind a system – the goals, constraints, and decisions that explain why it works the way it does, not captured in a form a person or an AI agent can reliably consult.
Intent debt, a term introduced by researcher Margaret-Anne Storey, resonated because it names what many engineering leaders have lived for years without a shared vocabulary.
Picture the version you’ve lived. An agent regenerates a checkout flow overnight. Clean diff, tests green, merged. Two weeks later support is on fire, because the new flow quietly stopped enforcing a rule about partial refunds that lived in one engineer’s head and got mentioned exactly once, in a Slack thread, last August. The code was fine. The understanding was fine, for precisely one person. What was missing was the why, captured somewhere the agent could reach it.
Storey introduced the idea in a March 2026 paper, later publishing an expanded version in ACM Queue. I’m here as an interpreter, not the owner – and I’ll admit it’s a little humbling that a researcher named the problem more cleanly than the language we’d been reaching for.
What is the triple debt model?
Storey proposes a triple debt model as a way to reason about software health across more than the code. It separates three kinds of erosion:
Technical debt → Missing clean implementation
Cognitive debt → Missing shared understanding
Intent debt → Missing externalized rationale
Technical debt lives in the code and cognitive debt lives in people. Intent debt is different: it’s about whether the rationale behind the system was externalized at all, into something a future teammate or a model can actually read.
Technical debt we’ve understood for decades: the shortcuts and tangles that make a system harder to change. The cognitive layer is newer to the conversation, the erosion of shared understanding that sets in when the people who could explain how the thing works drift off or stop replenishing what the team knows. Intent debt has had the least attention of the three, and Storey’s key requirement is that rationale be externalized. Rationale in someone’s head doesn’t count. It has to live in something a teammate, a future you, or a model can actually read.
The three interact. In Storey’s model, cognitive and intent debt reinforce each other inside a real system as either one erodes, and she argues, carefully, that in AI-assisted work the two may come to matter more than technical debt. That’s a hypothesis, not a measurement. The paper proposes a model and synthesizes existing research rather than running an experiment. But it’s the most useful frame I’ve read this year for why some teams that adopted AI fastest still report friction their delivery metrics don’t fully explain.
Isn't this just documentation?
It’s the obvious objection, and a fair one, but not exactly right. Intent debt isn’t solved by having more documentation. Teams can have hundreds of pages of docs and still lose the rationale behind critical decisions.
The debt accumulates when the goals, constraints, and reasoning that shaped the system aren’t captured in artifacts that people and AI agents can reliably find, trust, and reuse. A requirements doc explains what was built and an ADR records a decision, but neither guarantees the why survived. When the reasoning behind those decisions is fragmented, outdated, or never written down, intent debt keeps growing.
That’s the distinction Storey draws. What matters is not how much documentation you have, but whether the reasoning behind the system survived.
The part that actually matters
An agent can’t reliably recover a decision that was never captured.
Everything else here is supporting detail. An agent can help with technical debt: point it at a knotted module and it refactors. A team can rebuild cognitive debt slowly, by reading the system together until understanding comes back. Intent debt is the holdout. Faced with a gap where the reasoning should be, a model does the reasonable thing and produces something plausible, and plausible is not the same as correct. Almost right is worse than wrong: wrong gets caught, almost right gets shipped. That’s what a model hands you when it fills an intent vacuum with its best guess.
Storey ties this to AI directly. The missing information agents need to work, which some teams now call context debt, often shows up as a symptom of intent debt. Hers is the broader model: context debt is one way intent debt becomes visible in AI-assisted work, but intent debt also spans human decisions, organizational rationale, and knowledge that walks out the door when someone leaves. It’s the full arc of how a system evolves, not only the part an agent trips over.
What unpaid intent debt costs
It's worth being concrete about what happens when nobody pays this down. In recent public talks, Storey has described coaching student teams who build a product over a few months, often starting by cloning a previous cohort's app with AI and moving fast. The wall they hit isn't messy code. In one case a student couldn't move a button from one side of the screen to the other, because the team had lost all context for how the button got there in the first place. In another, a student gave up on editing the existing product and scrapped it to start over, because a rewrite felt easier than recovering intent the tools couldn't supply. That's the tax of unpaid intent debt: changes that should take minutes stall, and "start over" starts to look rational. At team scale, it's velocity quietly leaking out of a process everyone believes is fast.
How to start paying down intent debt
You can reduce intent debt without buying anything. A few practices move the needle:
Capture decisions at the moment they’re made, while the reasoning is still in the room, instead of reconstructing it months later when half of it is gone.
Define your product terminology explicitly. Take a word like “Everything.” If that’s a specific screen in your product, a model that doesn’t know it will build the wrong thing with total confidence. Every product has dozens of terms like that.
Record business rules separately from implementation, so a rule survives the next refactor instead of living only inside the code that happens to enforce it today.
Keep all of it where the work happens and where agents can read it: current and findable, not archived in a doc nobody opens.
That’s the discipline, and you can practice it with whatever you already run. Lowering its cost is the problem we built Atono to handle: capturing terminology, decisions, and rules as structured artifacts that people and tools can consistently reach. Storey’s paper resonated with us because it names the same failure modes we keep hitting in AI-assisted product work. There’s clear overlap with what we’ve been calling the Context Gap, though Storey’s model is broader and more general.
The point of capturing intent is simple: what you ship keeps matching what you meant to build, even when most of the building is being done by something that has never sat in your planning meetings. Get intent out of people’s heads and into artifacts your agents can read, and the model is far more likely to act on what you meant than to fill the gaps itself. Storey just gave the work a name.
FAQ
What is intent debt?
Intent debt is the missing or eroded rationale behind a system, the goals, constraints, and decisions that explain why it’s built the way it is, not captured well enough in something a person or an AI agent can reliably consult. The term comes from Margaret-Anne Storey’s 2026 triple debt model.
Is intent debt just documentation debt?
No. Teams can have plenty of documentation and still carry heavy intent debt. The debt exists when the reasoning behind decisions isn’t captured in a form that can be found, trusted, and reused by a future teammate or by an AI agent. It’s about the reliability of the why, not the existence of a document.
How is intent debt different from technical debt?
Technical debt lives in the code: implementation choices that make change harder. Intent debt is about externalized rationale, the missing goals, constraints, and reasoning that explain why the system works the way it does. You can run clean code and still carry severe intent debt: the system works, but no one, human or agent, can say what it’s supposed to do.
Why does AI make intent debt worse?
Agents can help with technical debt and even support understanding, but they can’t reliably recover rationale that was never captured. When the why behind a system is missing, the model fills the gap with its best guess, and a plausible guess isn’t the same as the right answer.
How can teams reduce intent debt?
Capture decisions when they’re made, define product terminology explicitly, record business rules separately from implementation, and keep all of it somewhere current that both people and agents can read.
Sources: Storey, M.-A. (2026). "From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI." arXiv:2603.22106; also published in ACM Queue. Context Gap Report.