Short answer
Agent memory systems are built to answer 'what happened'. Production agents also generate obligations - follow up next month, renew the certificate Friday, recheck the provider after the outage, run the audit when the evidence arrives - which are not facts but scheduled future work.
The paper we study here (arXiv:2609.01272) argues that prospective memory - remembering to act - needs a different data structure from retrospective memory, and proposes typed intention stores for it, shaped so that even small models can hold obligations reliably.
Ernesta Labs adopted the separation. Retrospective memory answers 'what is true and why'; an intention store answers 'what is owed, when, to whom, and what counts as done'. Conflating them is how systems end up with beautifully remembered, silently skipped obligations.
The failure mode: 'follow up next month' stored as if it were a memory
Every agent system that survives contact with real work starts generating sentences about the future. 'I will follow up with this lead next month.' 'Renew the TLS certificate on Friday.' 'Recheck the provider once the outage is resolved.' 'Run the security audit when the evidence pack arrives.' These are not descriptions of the world. They are commitments - and almost every agent architecture stores them exactly like descriptions.
The conventional home is the memory system: the commitment becomes an episodic memory entry or a vector chunk, retrievable by similarity. And here the failure begins, quietly. Memory retrieval answers the question 'what is relevant to my current context'. Obligations need to answer a different question: 'what must happen now that has not happened yet'. These questions have different triggers, different orderings, and different failure modes.
A memory entry sits inert until something retrieves it. Nothing in a memory store knows that Friday arrived. Nothing in a similarity search knows that the outage ended, that the evidence pack landed, or that a window closed. So the obligation fires only if the model happens to reason in the right direction at the right moment - which is precisely the reliability profile this library has repeatedly found insufficient for anything that must not silently fail.
The consequence is a system that remembers its obligations perfectly and executes none of them. Ask the agent 'what did you promise to do?' and it recites a flawless list. Ask the audit log 'what did you do?' and the list is empty. That is the reflection-action gap from Article 13, now with a data-structure cause: the obligation was given a home that has no concept of time, trigger, or completion.
It is worth being precise about the four example classes, because they have different trigger physics. 'Follow up next month' is time-triggered: a date arrives whether or not anything else happens. 'Renew the certificate Friday' is time-triggered with a hard window: fire early enough to matter, expire after the point of uselessness. 'Recheck the provider after the outage' is event-triggered: the obligation fires when the world changes to a condition, not when a clock ticks. 'Run the audit when the evidence arrives' is evidence-gated: the trigger is the existence of an artifact. A store that only handles dates handles one of four classes; a store that conflates them with similarity-retrieved prose handles none reliably.
What the paper actually does
PRIMARY SOURCE RESULT: 'Making Prospective Memory SLM-Shaped: Typed Intention Stores for Small-Model Agents' (arXiv:2609.01272) studies prospective memory in LLM agents - the remembering-to-perform of deferred intentions - and argues it is a distinct mechanism from retrospective memory, with distinct data requirements.
PRIMARY SOURCE RESULT: The paper proposes typed intention stores: structured, typed records of future intentions, rather than prose embedded in memory. The framing 'SLM-shaped' matters: the design targets small-model agents, on the reasoning that if a 7B-class model must hold an obligation reliably, the obligation cannot live in free text the model must reconstruct. The structure carries the load so the model does not have to.
PRIMARY SOURCE RESULT: The study reports that structured intention handling outperforms memory-embedded intentions on follow-through in its evaluated settings, and that the advantage is larger for smaller models. We treat the direction of that finding as the transferable result; the specific margins are study-scale numbers, covered under limitations below.
What they found, in builder terms
PRIMARY SOURCE RESULT: The core empirical finding is that obligations held as structured intentions are executed at higher rates than obligations held as narrative memory, across the paper's evaluated model set, and that the gap grows as model size shrinks. The mechanism is not mysterious: a typed record exposes the fields a runtime needs to schedule, check, and verify; prose buries them where only a fortunate retrieval can resurrect them.
PRIMARY SOURCE RESULT: The paper also reports failure cases where memory-embedded intentions were retrieved but not recognized as actionable - the model read its own promise and did not treat it as a task. This is worth sitting with. Retrieval is not interpretation, and interpretation is not execution. Three separate steps can each fail; a typed store collapses the first two by making the record's actionability explicit in its type.
Ernesta Labs reads this as the same lesson Article 13 taught from the benchmark side: stated intentions are claims, and claims need an owner outside the model. The intention store is the owner. The paper's contribution is showing that the owner does not need to be expensive machinery - a typed table plus a scheduler is enough, which is what makes the pattern adoptable for small teams and small models alike.
The store: fields an intention record needs
LABS RECOMMENDATION: Ernesta Labs specifies the intention record as follows, informed by the paper's typed-store design and by what our own runtime needed. This field set is our specification, not a quotation of the paper's schema.
Intention ID: stable identifier, referenced by every event about the intention. Actor: who owes the action - which agent, which role - because obligations without an owner are unassignable. Trigger: when it fires - a date, a recurring rule, or an event condition ('provider status returns to healthy', 'evidence pack arrives'). Window: the bounds within which firing is valid; fire too early and the premise may not hold, too late and the obligation may be meaningless. Status: PROPOSED, COMMITTED, FIRED, EXECUTING, COMPLETED, EXPIRED, CANCELLED - explicit states, not vibes.
Supersession: which intention, if any, this one replaces, so re-planning does not leave ghost obligations running in parallel. Cancellation: who may cancel, and the required evidence for why. Permissions: what authority the execution needs, resolved at execution time - an intention is not a grant of permission, a point Article 17 of this library makes at length. Idempotency: a completion key, so a trigger that fires twice produces one execution, not two charges or two emails. Completion evidence: the artifact that proves the action happened - a record ID, a receipt, a hash - without which the store will not mark the intention COMPLETED.
Two fields deserve emphasis. The trigger is what makes the store prospective rather than a to-do list the model rereads: the runtime evaluates triggers, not the model's discretion. The completion evidence is what keeps the store honest: an intention closes on proof, not on the model asserting it closed. An agent that marks its own homework is the pattern this library rejects everywhere else, and intention completion is not the exception.
Limitations
The paper's evaluations are study-scale and focused on its evaluated task settings. Follow-through margins on benchmark obligations are not production renewal-miss rates; treat the direction as established and the magnitudes as indicative.
The design targets small-model agents specifically. Whether the structured-store advantage persists, shrinks, or inverts for frontier-class models is not established by this study - and our recommendation does not depend on the answer, because the store's value is architectural (a scheduler-ownable record) rather than purely model-compensating.
Trigger conditions for event-fired intentions ('when the evidence arrives') require the runtime to observe the event, which is an integration problem the paper does not solve for you. An intention store without event sources is a calendar without clocks.
And the study does not address adversarial writes - who may create intentions. A store that turns prose into scheduled effects is also a store that turns injected prose into scheduled effects, which is why the permissions field is not optional decoration. See Article 15 on memory poisoning for the attack family.
Why builders care
Because obligations are where agents touch commitments, and commitments are where trust is won or lost. A lead that was promised a follow-up and never got one is not a metric anomaly; it is a broken promise, and your memory system will still be able to recite it perfectly.
There is a model-selection angle too, and it is the reason the paper's SLM framing matters even for teams running frontier models. If obligations live in prose, the memory's reliability floor is the model's follow-through rate - and Article 13 established that stated commitments convert to actions at rates no team should build on. If obligations live in a typed store, the reliability floor is the scheduler's, which is effectively perfect. You want the load-bearing behavior on the perfect floor and the model doing what models are for: deciding what to owe, and executing when the trigger fires.
The examples are not exotic. Certificate renewals are obligations with hard windows; miss one and the site goes down. Provider rechecks after an outage are obligations with event triggers; without a store, they depend on someone remembering during incident cleanup, the worst possible moment. Evidence-gated audits are obligations whose trigger is an arrival, not a date. Recurring obligations - the follow-up next month - are the ones memory systems handle worst, because 'next month' becomes a stale string that never updates.
There is also a cost argument. The intention store is cheap: one table, one scheduler pass, one completion check. Compare that with the failure it prevents - the silently skipped obligation discovered weeks later by a human - and the asymmetry settles the question. This is why Ernesta Labs moved this pattern from studied to adopted.
What we would implement, and what we would not
LABS RECOMMENDATION: Implement the store as the single system of record for future obligations. Every 'I will do X' that survives review becomes a typed intention with the full field set above. Route all intention lifecycle events - creation, trigger, execution, completion, cancellation - into the same evidence ledger the rest of the runtime uses. Evaluate triggers with deterministic code, never with a model's judgment of whether it 'feels like' the condition holds.
LABS RECOMMENDATION: Gate completion on evidence. The intention store accepts a completion artifact - record ID, receipt, hash - and refuses COMPLETED without one. An obligation that fired and produced no evidence stays open and visible. Expiry is explicit: an intention whose window passed unexecuted becomes EXPIRED, loudly, not silently forgotten. A visible expiry is a debuggable failure; an inert memory entry is not a failure at all, which is the problem.
What we would not implement: we would not let the agent write intentions directly from its own free text without a structured write path - prose in, obligation out is an injection surface and a typo factory. We would not implement model-driven trigger evaluation as a fallback; a model asked whether the evidence has arrived is a classifier with a confidence problem, not a trigger. We would not conflate the intention store with a task queue for synchronous work - intentions are obligations, not a job runner; execution still belongs to your durable execution layer (Article 5's territory). And we would not treat a COMPLETED intention as proof the outcome was good - completion evidence proves the action happened, not that it worked.
CASE STUDY - NIKO: giving obligations a home that is not a paragraph
Ernesta Labs adopted the typed intention store inside NIKO's runtime - the system behind this site - because NIKO generates exactly the obligation classes this article lists: time-windowed follow-ups on waitlist activity, provider rechecks after failures, and verification steps the diary promises before publishing.
Before the store, such commitments lived in prose: diary entries, notes, plans. The store made them addressable. A diary-stated 'we will verify persistence before launch' becomes an intention with an actor, a trigger, a window, and a completion-evidence requirement. The scheduled checks NIKO's runtime already runs for load-bearing commitments (Article 13's watchers) are now backed by intention records rather than ad-hoc cron entries, so each one has a status, an expiry, and a completion artifact.
The separation also clarified the boundary with memory. NIKO's diary is retrospective: what happened, verified. The intention store is prospective: what is owed. Neither reads from the other as a system of record; the diary may describe an intention, and an intention's completion writes evidence into the ledger the diary cites, but prose does not schedule and schedules do not narrate.
IMPLEMENTED: the typed intention store with the full field set, deterministic trigger evaluation, and evidence-gated completion, backing NIKO's scheduled verification checks. TESTING: live operation across real waitlist and publishing activity, with expiry visibility on. DESIGNED but NOT YET PROVEN: measured follow-through improvement over the pre-store baseline - we have not run a controlled comparison, and no reliability gain is claimed without one. NOT YET PROVEN: long-window behavior - multi-month intentions have not yet aged through a full cycle, so supersession and expiry under real churn remain untested claims until they fire for real.
Practical test: find your unowned obligations today
Do this in an hour. Open your agent's last week of memory entries, notes, or transcripts, and grep for future-facing language: 'follow up', 'renew', 'recheck', 'when', 'next week', 'after the'. Every hit is a candidate obligation.
For each, ask three questions: (1) What fires it - a date, an event, or nothing? If the answer is 'nothing', that obligation will execute only by luck. (2) Who owns it - and 'the model will remember' is not an owner. (3) What proves it done - which artifact would you accept as completion evidence?
Then build the minimum store: one table with the fields from this article, one scheduler pass over the trigger column, one completion-evidence check. Move the top three load-bearing obligations into it, and watch them for two weeks. You will learn one of two things: your obligations fire reliably now, or they were silently failing before. Both findings are worth an hour of work, and the second one is worth more.
What remains unknown
- Whether the structured-store advantage holds at frontier model scale or is primarily a small-model compensation - the study targets SLMs and does not establish the frontier-case answer.
- How event-triggered intentions behave when the triggering event source is itself unreliable or delayed - trigger observability is an integration constraint the paper leaves to the builder.
- The right permission model for intention creation - who may schedule effects is an authority question (Article 17's territory) that this paper does not address.
- Long-horizon behavior of supersession and expiry under real planning churn - our own store has not yet aged multi-month intentions through a full cycle.