Not All Memory Entries Are the Same Shape

Picture an assistant helping someone plan an event. Across a single conversation, it might hold five entirely different kinds of context at once: an established fact, a missing detail it still needs to track down, a long term goal unfolding over weeks, a promised follow up, and an interrupted thought waiting to be revisited.

Systems can mishandle these five kinds of context if they store all of them as a line of text with a timestamp. This flat shape schema can be a real problem, as each of these five behaves differently over time. If you treat them identically, you can produce predictable failures depending on which two collide.

Every memory entry that is logged can be placed using two things.

First: direction. Is this something that the system knows about the person, or something the system owes them? In most cases the answer is the former; only one category falls under the other one.

Second: a specific trigger, not a yes-or-no question. One might think an entry would need only two tags: whether it persists until something changes it, or resolves and closes once a condition is met. But three of the five shapes below are all about the person and all resolve eventually, so that yes-or-no flag can't tell them apart. Then what would distinguish them? It is how each entry is closed: an answer, steady progress, a resumed thread, or a promise that's fulfilled or broken. That has to be explicitly mentioned and not reduced to a flag.

When you put a 'direction' and a 'trigger' together, you get the five shapes below.

Fact. Direction: about the person. Trigger: none by default, only an explicit correction updates it. An example of this would be something that is stated directly, like the guest count or a budget limit. This shouldn't fade away just because the conversation moved on, nor should it need to be repeated to stay true. If the system mixes it with something that resolves later, like an open question, and treats it as temporary, it gets dropped the moment it falls out of whatever the system is presently paying attention to.

Open question. Direction: about the person. Trigger: answered. This is something the assistant still needs to find out, like which venue the person picked. It should close the moment it's answered, and it shouldn't get asked again. If the system treats it like a goal instead, it keeps asking about it long after the person already answered.

Goal. Direction: about the person. Trigger: steady progress completes it, or it's explicitly abandoned. This is something the person is working toward across multiple conversations, like staying under budget as decisions roll in before the event. If the system confuses it with an open question, it drops it too soon: the moment a conversation hints at partial progress, it closes the loop long before the goal is actually reached.

Commitment. Direction: owed by the system. Trigger: fulfilled, cancelled, expired, or broken. This is a promise the system made to the person, like checking whether a vendor confirmed availability for the date. It is the only category running in reverse: instead of tracking knowledge about the person, the system is tracking an obligation it owes them. If the system stores it the same way as a fact, it stops looking like a promise at all. Nothing about a fact's shape tells the system to check whether it's still valid, so an unfulfilled commitment looks identical to an ordinary detail nobody brought up again. The person only discovers the drop by following up manually, by which point the system has already failed silently. Of all five mix-ups, this one is the worst. Every other one is noticeable and correctable in the moment, but this one produces nothing visible at all.

Pending point. Direction: about the person. Trigger: resumed or released. This is a thread that was active and got cut off, like someone describing a seating chart right before getting pulled into a vendor call. This should be paused and handed back as soon as the interruption ends. If the system mixes up this shape with another shape, say a fact, it gets automatically stored in permanent memory instead of being addressed, and therefore the person never gets to finish their thought.

The shape that isn't on this list

One might think a correction can be the sixth shape, but it isn't. Let's say the person later mentions that the guest count is revised; however, this doesn't represent a new piece of information meant to stand alongside the old one, but rather an edit to the existing fact. A system that treats each update as a brand new entry will end up having two contradictory versions of the same fact, without any mechanism to determine which one should be considered current.

Why similarity search can't tell these apart

A common approach to long term memory turns every entry into an embedding and uses semantic similarity to retrieve whichever ones are most relevant to the current turn. That's useful for one question: what's related to what's being discussed right now? Semantic similarity can retrieve something relevant, but relevance alone can't reliably tell the system what lifecycle behavior to apply, because direction and trigger were never part of what got embedded in the first place.

A stated fact about venue capacity and an open question about the same venue can look equally relevant to a new message. But they require opposite treatment. One should be treated as settled. The other should be treated as unanswered. Similarity search can retrieve something relevant, yet the system can still mishandle it, because relevance was never the thing that needed deciding.

What should be stored and who will decide it?

In order to differentiate between the shapes, we need to store two explicit fields along with every entry, but the second one has to carry more than a plain yes or no.

• Direction: whether it is about the person or owed by the system to the user.
• Trigger: the specific condition that closes the entry, drawn from a small fixed set, such as none (only a correction updates it), answered, steady progress or abandonment, resumed or released, or fulfilled, cancelled, expired, or broken.

A plain persists-or-resolves flag isn't enough on its own. Three of the five shapes are all about the person and all resolve eventually, so that flag alone can't tell an open question apart from a goal or a pending point. The trigger has to name the actual closing condition, not just whether one exists.

A flat entry containing just the text and its timestamp has neither of these fields. And that is the reason why, even if a system stores all five categories as plain text, it can't actually act on the core difference between them.

What needs to be done is that an extra step needs to be added in this pipeline, which will consist of assigning both the above mentioned fields the moment a statement is heard. In a day-to-day conversation, an LLM can make that call directly. It needs to tag the statement with a direction and a trigger while processing the turn, prior to writing it to memory. More predictable phrases such as "I'll look into that" or "I'll get back to you" can be recognized using simple pattern matching. That's cheaper, and works reliably when phrasing is consistent. Either way, the tagging must happen at write time, not guessed later from raw text. Guessing later runs straight into the same failure mode similarity search already faces.

Once both fields are set, each category can follow its own maintenance rule instead of one blanket rule for everything. New facts get checked against existing ones for conflicts. Commitments get checked on a schedule, and surfaced the moment they're overdue, without anyone needing to ask. Open questions, goals, and pending points each close on their own trigger: an answer, verifiable progress, or being picked back up.

What the classification is actually for

None of this is about remembering more. A system that contains five correctly shaped entries and a system containing the very same five entries dumped into a flat list will have the same knowledge. But their behaviour will be entirely different, due to the fact that behaviour depends on which operational rules apply to which entry, not on how much data was stored.

Each of the five categories needs different maintenance logic. If a system flattens everything into one shape or relies purely on similarity scores, it loses the ability to treat anything differently. The real test is not about the ability of the system to recall information correctly, since almost any system can do that. It is whether an unmet commitment eventually gets raised again, as fulfilled or as broken, instead of quietly vanishing into the background alongside every other fact.