The Triple Debt Model: A Framework for Thinking Through Your Automation

There was no framework on hand when Autopilot came together — five problems got solved one at a time, not from a blueprint. Later, at an AI and data conference, a framework came up that put those same five problems into a simpler shape: technical debt, cognitive debt, intent debt.

Whether Autopilot got it right isn’t really the point here. What matters is the framework itself — it’s useful for working out which layer a piece of automation actually sits in, and what the common approaches look like at each layer. Autopilot’s choices are just one set of answers, not necessarily the right ones for anyone else.

Three layers, three different problems

Once automation has been running a while, one thing tends to stand out: the code itself is usually the easiest part to deal with — refactor it, add tests, clean it up, and there’s a clear path forward. What quietly turns into friction instead is two other things: whether anyone can still follow what the system is actually doing, and whether the reasons behind its design are still around.

Margaret-Anne Storey, at the University of Victoria, laid this out in a recent paper as three separate kinds of debt.

Technical debt lives in the code — the implementation choices that make a system harder or easier to change later.

Cognitive debt lives in people’s heads — a team’s shared understanding of the system, eroding over time. What makes this one dangerous is that it can happen while the code is completely fine and every test passes: everything looks healthy, but nobody actually follows what the system is doing anymore.

Intent debt lives somewhere that may never have been written down at all: the goals, constraints, and reasoning behind how the system evolved. If that only exists in someone’s head and was never externalized, recovering it later is hard, sometimes impossible.

Storey is clear that these are independent axes. A system can have almost no technical debt and still be drowning in intent debt — clean code, full test coverage, and nobody besides the person who built it has any idea why it turned out this way.

What gets borrowed here isn’t the debt framing itself — Autopilot isn’t a discussion of what debt it owes or how to pay it down. What’s useful is the three-layer split underneath: one layer is concrete execution that can be spelled out as rules, one is the higher-level understanding of what’s actually happening, and one is the direction — what’s actually meant to happen. These three map neatly onto the three kinds of problems that keep coming up when designing automation, which isn’t quite the same problem the original paper set out to solve.

So the question under each layer becomes: how can an Agent actually lighten the load here? If the answer still comes down to “a person has to go check,” that’s just moving the checking work somewhere else — it isn’t a lighter load. Genuinely lightening it means the Agent has taken on part of the understanding, filtering, or organizing that a person used to do, leaving only the judgment call for the human.

Technical layer: picking the right trigger and execution method

Autopilot runs on Cursor’s Automation, but nothing about this layer requires locking into one platform. A GitHub-event-triggered bot, or a webhook-triggered CLI agent, would do a similar job. What decides which one fits isn’t the platform’s name — it’s whether the step can be written as a set of rules.

Using Cursor is partly a matter of familiarity — even a non-coding task like writing a book ends up on the same platform. That doesn’t make Cursor the only or best answer, just the one that’s comfortable to reach for right now. Different kinds of tasks will probably end up on different platforms over time.

Where an Agent can actually lighten the load at this layer is mostly in making the rules more complete — reading logs to catch cases the rules missed, flagging tests that are missing, pointing out places that could be refactored. Making the judgment call itself is a different matter, and should stay with deterministic code as much as possible. “An Agent that helps maintain the automation” and “an Agent that runs the automation” are two different things.

Cognitive layer: a dashboard, or something that tells you what matters

Pulling scattered state into one view doesn’t automatically mean the load has gotten lighter. If that view still needs someone to scan it item by item and judge whether anything looks off, the burden hasn’t gone away — it’s just moved. Checking got cheaper; understanding still takes the same work.

Actually lightening this load usually needs an Agent to do two more things. First, active summarizing: instead of handing someone a dashboard to read, surface what changed, what looks off, and what needs a decision, and push that to the person rather than waiting for them to go dig it out. Second, routing: taking a conversation or an idea and splitting it into the specific instructions each repo actually needs — which is closer to translation than to organizing.

Autopilot does a partial version of both: a cross-project collector pulls state together, and day-to-day conversation with Claude handles turning a sentence into concrete tasks for different repos.

There are other ways to approach this. Some people use a centralized database like Notion as an overview dashboard, keeping everything in one place to check. Claude’s or ChatGPT’s own connectors, or other agent tools on the market, can also stand in for this. A common limitation across these is that chat session memory doesn’t carry across sessions or locations — every new conversation starts back at zero. That’s exactly what the collector (with Orbita filling this role) is meant to solve: storage and retrieval are kept separate, state lives in one place, and a dedicated agent handles reading and presenting it, instead of relying on any single session’s memory.

Intent layer: personal and team burdens aren’t the same

This layer’s burden looks different at the personal level than at the team level, and the two are worth separating.

Personal intent

The difficulty here usually isn’t a lack of somewhere to write it down — it’s that writing a complete direction document from scratch is a high enough barrier that most people never actually do it. Not because it doesn’t matter, just because it’s too much friction, so intent stays in someone’s head and never makes it to an Agent.

A common approach — probably the one most people already use without naming it — is just talking to an Agent continuously, letting it help clarify and record things over conversation rather than writing a formal document up front. That’s a workable approach; the reasoning just ends up scattered across a lot of conversations instead of living in one place. Another possibility is having the Agent draft a direction document from conversations and decisions that already happened, leaving a person to review and edit rather than starting from a blank page. Which one fits better probably comes down to personal habit more than which one is “correct.”

Team intent

This is still an open question, still being figured out.

Autopilot uses Slack as one entry point: when a discussion in the team reaches consensus, an emoji triggers it, and the Agent turns the thread into a proposal. Slack is just one of many possible entry points. A pattern common in open-source projects — collecting feedback through GitHub Issues, with a maintainer deciding on direction — is a version of the same idea: it turns who gets to contribute intent from a single person’s bottleneck into something anyone can take part in.

The burden isn’t really in the collecting — an issue tracker already does that. It’s in filtering and synthesizing: if someone still has to read through hundreds of issues one by one to decide on a direction, nothing has actually gotten lighter, it’s just a different form of “someone has to read it all.” A more promising approach is having an Agent cluster and summarize a large pile of scattered feedback into a handful of candidate directions, so a person only has to judge between a few options instead of reading everything.

This part is still at the experimental stage — there isn’t a settled approach worth sharing yet.

Looking at the three layers separately has a management upside too

Autopilot doesn’t handle all three layers equally well. Technical and intent both have clear mechanisms in place, but the collector at the cognitive layer only aggregates technical state — the actual judgment about direction still depends on a person reading and making sense of what gets pulled together, and that step hasn’t been systematized any further.

The three axes really are independent: a system can be doing well on one and not touching another at all. Instead of asking broadly whether a piece of automation is any good, it’s more useful to ask layer by layer: has the technical layer become a checkable set of rules? Does the cognitive layer give anyone a way to regain a picture of the whole? Has the reasoning behind the intent layer actually been kept somewhere?

Splitting the three layers apart also brings a practical benefit: each one can run on a different tool, managed on its own, instead of needing one system to handle everything. The technical layer can run on Cursor Automation or switch to a different trigger; the cognitive layer can run on Orbita or switch to Notion or another agent tool; the intent layer’s direction can go through Slack, team feedback through GitHub Issues. Keeping the three loosely coupled means trouble in one doesn’t drag down the other two, and any single layer can be swapped out without rewriting the whole system. That’s a personal takeaway from actually running this, not a claim that it holds everywhere — trying to make one system handle all three layers at once would probably be a lot harder to manage.

---

Source: Margaret-Anne Storey, “From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI,” 2026.