Durable Intent: The One Thing Your Agent Will Not Forget or Make Up
By Michael Cooper · Founder
Note (2026-06-11): the rest of the site now calls this signed intent— same primitive, renamed because “durable” increasingly reads as durable execution (workflow replay), which this is not.
Here is a failure mode every team running agents has hit. An agent starts a piece of work, runs for a while, and then loses the thread — a context window fills and truncates, a session expires, the work hands off to a fresh agent, a tool swap resets the running state. When the work resumes, the agent no longer knows for certain what it was doing or why.
The dangerous part is not that it forgot. It is that, asked to remember, a language model does not say “I don't know.” It reconstructs. It produces a fluent, plausible account of what it was probably doing — an account that can be subtly or completely wrong, and that nothing flags as invented. For a chatbot that is an annoyance. For an agent that is about to spend money, provision access, or act on someone's behalf, it is a liability.
Memory, logs, and the thing in between
Two tools are usually reached for, and neither closes the gap.
Agent memory and RAG store and retrieve, but what they hand back is reconstructed and unsigned. A summarized memory is a lossy compression of a conversation; an embedding lookup returns what is similar, not what was true. There is no way to tell a faithful recollection from a confident fabrication, because both arrive as ordinary model output.
Logging and observability capture what happened — the tool calls, the spans, the outputs — after the fact. That is useful for debugging, but a log is written about the action, not the intention behind it. By the time you read a log to ask “what was this agent trying to do, and on whose authority,” the only thing that can answer is the model, reconstructing again.
The thing in between is a record of intent that is captured at the moment it is real and is durable enough to be read back unchanged. Not a summary. Not a reconstruction. The byte-stable statement of what the agent was required and authorized to do, made before the work, and still there after.
What durable intent is
Durable intent is that record. At the start of a task, the agent states what it intends to do and under whose authority, and that statement is signed and hash-chained the moment it is written. The agent does not manage keys or assemble proofs — it reports with its API key, and the notary signs what it reported, naming the accountable principal inside the signed record. The authority is the principal's; the signature is the notary's.
Later, when the context is gone, the agent reads the record back. It does not have to remember — it recovers, byte-for-byte, what it was told to do. A concrete version: an agent places a hardware order, and the laptop arrives two weeks later. The session that placed it is long gone. The agent does not reconstruct why it ordered the machine; it reads the record notarized when it placed the order — what was intended, the principalAgentId accountable for it, the requestedBy party that asked. The conversation evaporated; the chain did not.
Why a reliability feature is also an audit trail
The same record that an agent reads for recovery is read later by two other parties, and each gets something different from it. The agent trusts itself and reads the record to recover state. The operatorreads it for oversight — what did my fleet intend and do, where did a handoff go wrong. The auditorreads it for proof, and verifies the cryptography offline without taking anyone's word for it.
That is the quiet leverage. The cryptography is overkill for the agent recovering its own state — it trusts itself, it does not need to check a signature. But it is exactly what an auditor relies on. So the developer who adopts durable intent for reliability is, without doing anything extra, accumulating audit-grade evidence. When the compliance question arrives later — an audit, a customer's security review, a regulation — nothing has to migrate. The records are already signed, chained, and verifiable. The same object travels from a debugging convenience to a piece of legal evidence as it is read by more skeptical parties.
Making it a precondition
Durable intent works beside the action: the agent records as it goes, and the record is there to recover from. When the action is consequential enough, you can also put the record in the pathof it — a gate you run that refuses a tool call until a valid record exists, and validates that record against the API rather than trusting that a string is present. No record, no action. That is enforcement, and it is the same record doing double duty.
You do not need a gate to get value, though. Durable intent is the on-ramp: plug in, let agents record what they intend and do, and they become more recoverable the same day. The free Developer Edition is production-capable and runs on your own infrastructure — the agent reports, the notary signs, and you have a memory your agents cannot lose or invent.
Sources & further reading
- in-toto Attestation Framework — Statement v1 — the payload format AGLedger signs intent and result into.
- RFC 9052 — CBOR Object Signing and Encryption (COSE) — the COSE_Sign1 envelope each record is signed as.
- How AGLedger works — the record and the chain
- Verification — what an offline check proves, and what it does not