§1The accounting nobody is doing
Every agentic workflow has the same shape. A user signs an instruction. The system accepts it. Sometimes the system delivers. The thing that gets logged is the delivery, the completed action, the cart that cleared. Stripe records the charge. The CRM records the booking. The DSAR case management system records the case closed. None of these systems record, with a signature, the moment the obligation was accepted. They are running on cash basis.
What we are going to call intent debt is the simplest possible derivative: the count of signed instructions a system has accepted, less the receipted completions against them. It is the obligation side of an agentic balance sheet, the accounts-payable column nobody renders. Most agent stacks cannot compute it because they have no signed-and-dated declaration of the asks they took on. A user prompt is not a receipt. A logged chat message is not an obligation. Until the system makes its own promise visible at the boundary, the only accounting it can do is "what we completed", and that is half a ledger.
§2AP2 already split this in two, and most teams use half of it
Google's Agent Payments Protocol (AP2) shipped with two distinct mandate types: an IntentMandate, signed at the moment the agent accepts an instruction, and a CartMandate, signed by the user at the moment of fulfilment. The community has mostly read AP2 as a payments primitive, a way for an agent to transact on behalf of a user with a cryptographic chain of custody. Read it as accounting and a different shape falls out. AP2's two-mandate design is the bookkeeping pattern any regulated agentic stack already needs. The IntentMandate is accounts payable; the CartMandate is the receipt that discharges it. Most teams who pilot AP2 issue the CartMandate side first, because the receipt-of-fulfilment is what unblocks payments. The IntentMandate side is the harder cultural move. It requires the system to admit, in writing, that it has accepted an obligation it has not yet honoured.
The numerator and denominator are then trivial. Over any window, the intent fulfilment ratio is the count of CartMandates whose reference field discharges an IntentMandate, divided by the count of IntentMandates issued in the window. Its complement is debt. The reason nobody reports this is not technical. It is that the IntentMandate, the harder of the two to issue, gets skipped.
§3Where the debt hurts (and who fines you for it)
Statutory DSAR is the cleanest demonstration. Under §45 of the Data Protection Act 2018 and the UK GDPR, a controller must respond to a subject access request within one calendar month of receipt of a valid request. The published ICO enforcement record from the last year alone shows councils, NHS trusts and private controllers being reprimanded for missed windows at rates that would not be tolerated in any other accrual-accounted process. The reason the rates persist is that case management systems track cases opened and closed, not signed obligations against a statutory clock. When the controller is asked, mid-month, how many DSARs are currently within their statutory window, the honest answer in most authorities is a SQL query that runs against a case table, not a count of signed intents. The case table is also where the cases that arrived as a tweet, an email, a verbal request at reception are quietly missing.
Education is worse. Section 19 of the Education Act 1996 places a statutory duty on Local Authorities to arrange suitable alternative education when a child is out of school for reasons beyond a fixed-term exclusion. The duty is the IntentMandate. The placement secured is the CartMandate. The LA's intent debt is the count of children whose duty has been accepted and whose placement has not been secured, weighted by how long the clock has been running. Most LAs only find out their intent debt when Ofsted asks, because the case management workflow stops at "placement search in progress" without ever asking "for how long, against what window". This is the workflow Conexus is built to instrument.
The financial-services case is the most familiar but the least striking. FCA SS1/23 expects firms to evidence that they monitor model behaviour over time. An accrual ledger of unfulfilled customer-facing intents is a more honest input to that monitoring than a model card. Until we have it, "we monitor" means "we hope".
§4What the runtime change actually looks like
A runtime that wants to be honest about intent debt does two things. First, it issues a signed IntentMandate at the boundary, every time it accepts an instruction. One Ed25519 signature, a timestamp, an expected fulfilment window (the statutory one, or the SLA, or whatever the workflow promises), and a reference identifier. AP2 already specifies the shape; the cost is one signature per accepted instruction and one row per audit-log line. Second, the runtime emits a CartMandate on close that names the IntentMandate it discharges. A daily reconciliation job sweeps unmatched intents; anything older than its declared window emits an overdue alert. That is the entire substrate change. It is not a research project.
The cultural change is harder. The IntentMandate forces the system to publish, in a place a regulator can read, the obligations it has not yet honoured. Most operators find that uncomfortable for the first week and then find it indispensable. A signed IntentMandate is also, incidentally, the cleanest possible training datum for any fine-tune that wants to know what users actually asked for. Most behaviour-cloning datasets have prompts and completions; very few have the user's signed declaration of what success would have looked like. The intent-debt ledger is that declaration, by construction.
§5What this does not solve
The two-mandate construction is bookkeeping. It does not tell you whether the work was correct, only that something with that intent's identifier completed. A wrong DSAR response can still close out an IntentMandate, just as an incorrect invoice can still close out a purchase order. So intent debt is necessary but not sufficient. It makes the open-obligation count auditable; it does not measure the quality of closure. Quality is a separate observable, the held-out evaluation we wrote about in Note №26. The two compose. Without intent debt you do not know what was promised. Without held-out evaluation you do not know whether closure was honest.
Two more caveats. AP2 expiry semantics do not quite match statutory windows: the ICO clock starts on receipt of a valid request, and most controllers determine validity asynchronously. The boundary at which the IntentMandate is issued has to be the validity decision, not the inbound message, and that adds a small workflow wrinkle. Second, the receipt cost: one signature plus one log row per accepted instruction is meaningful storage for high-volume systems, and somebody has to own the rotation, the retention and the key-management for the signing pair. We have written about both before in Note №20. The pattern still holds. Until a system can produce a count of obligations it has signed for and not yet honoured, it does not have an audit position. It has cash-basis accounting in a regime that requires accrual.