🤖Dành cho Agent

StructMem: Agent Memory Should Remember Events, Not Just Notes

StructMem is an agent memory design inspired by human episodic memory: store events with time, participants, relationships, consequences, source, and trust instead of isolated chunks.

2026-04-268 min read
StructMem: Agent Memory Should Remember Events, Not Just Notes
agent-memoryStructMemLLM agentshuman-inspired memory

StructMem: Agent Memory Should Remember Events, Not Just Notes

Long-horizon agents have a simple but stubborn problem: they can store a lot of memory without truly understanding what they remember.

A user changes their mind across several sessions. A relationship shifts over time. A decision made today depends on a small detail from last week. A preference was true in one context, but not in another.

If an agent saves all of that as disconnected notes, memory quickly turns into a box of paper scraps. There is data, but not enough structure. Retrieval can find something that looks relevant while missing why it matters.

The paper “StructMem: Structured Memory for Long-Horizon Behavior in LLMs” is useful because it attacks that exact problem. It proposes a memory architecture for LLM agents that is more structured than a flat vector store, but lighter than a full graph memory system.

The human-memory inspiration is clear, but this is not really a paper about human cognition. It is better understood as an agent memory design pattern inspired by the way humans often remember stories: what happened, who was involved, when it happened, how relationships changed, and what consequences followed.

In one sentence: StructMem tells agents to remember events, not just facts.

Why flat memory is not enough

Many agents use a straightforward memory setup:

  • save new information into a store;
  • retrieve similar items with embeddings or keywords;
  • inject retrieved snippets back into the prompt.

That is useful, and it is often the right first version. But it breaks down when the agent needs long-horizon understanding.

A flat memory item like this seems clear:

Minh does not like morning meetings.

But where did that come from? Did Minh say it directly? Was it a stable preference, or just a reaction after a bad week? Was the issue morning meetings in general, or meetings that interrupt deep work?

Flat memory often loses that surrounding event.

It also struggles with time. If a user said “I prefer working alone” last month, but today says “this project needs team support,” an agent should not treat both statements as equal timeless facts. It needs to know which event each statement belongs to, what changed, and which one should guide the current decision.

For smaller agent models, this matters even more. A strong model may sometimes reconstruct missing context from clues. A smaller model has less room for repair. If memory comes back as isolated fragments, the small model is more likely to overfit to the wrong fragment.

Flat memory is like a notebook with no chapters, no dates, and no links between pages. It contains text, but understanding still costs too much.

Why full graph memory can be too heavy

The opposite direction is graph memory.

In a graph memory system, entities become nodes. Relationships become edges. Events can also become nodes. This is powerful, especially when the agent needs structured reasoning.

But graph memory has its own cost.

The system has to extract entities, identify relations, deduplicate names, update edges, decide when two things are the same, and maintain the graph over time. Every step can introduce errors. Every extra LLM call adds latency and cost. A wrong edge can pollute later reasoning.

This is especially uncomfortable for small agents. If the graph becomes too complex, the model is no longer helped by memory. It is forced to read and interpret a complicated map.

StructMem takes a middle path:

More structured than flat memory, less brittle than a full graph.

That tradeoff is the interesting part.

The core idea: remember by event

StructMem is built around event-centric hierarchical memory.

Instead of storing isolated facts, the system groups memory around events. Each event can contain different kinds of entries, including:

  • factual entries: concrete facts from the event;
  • relational entries: relationships, attitudes, motivations, or meaningful links inside the event;
  • temporal anchors: when the event happened.

Imagine this situation:

On April 12, An told Bình that she did not want to join the demo because she was still upset that Bình had changed the deadline without warning.

A flat memory system might store:

  • An does not want to join the demo.
  • Bình changed the deadline.
  • An is upset with Bình.

Those notes are not wrong, but they are too loose.

An event-centered memory keeps the binding:

  • the refusal happened on April 12;
  • the refusal was about the demo;
  • the emotional state was connected to a prior deadline change;
  • the relationship between An and Bình was affected by communication around deadlines.

That binding is what makes the memory useful later.

The agent should not merely remember “An dislikes demos” or “An is upset.” It should remember the event that produced those facts, the participants, the time, and the cause.

This is where the human-memory inspiration helps. Humans rarely remember life as a giant key-value table. We remember scenes, episodes, sequences, and relationship changes. StructMem borrows that shape for agents.

Time is not metadata. Time is meaning.

StructMem also emphasizes timestamp anchoring.

That sounds basic, but long-term agents need it badly.

Without time, every memory starts to feel equally current. The agent may apply an old preference to a new situation, or treat a temporary emotional state as a permanent fact.

With time, the agent can reason about questions like:

  • What happened first?
  • Which information is newer?
  • When did a relationship change?
  • Is today’s behavior a consequence of an earlier event?
  • Did a preference persist, or was it temporary?

For long-lived agents, correctness is not just “what is true?” It is also “when was it true?”

Consolidation: looking across events

StructMem does not stop at storing events. It also performs cross-event consolidation.

In plain language: the system periodically looks across related events and creates a higher-level synthesis.

For example, across several interactions between An and Bình, the system might synthesize:

  • An is sensitive to deadline changes without notice.
  • Bình tends to move quickly but sometimes under-communicates.
  • Their collaboration improves when expectations are made explicit early.

That synthesis is useful. It gives the agent a pattern, not just a pile of episodes.

But there is an important safety rule here: synthesis should not replace raw memory.

Raw memory records what happened. Synthesis is an interpretation built from multiple raw memories.

A good agent should keep those layers separate:

  • raw event memory: source evidence;
  • synthesized memory: derived understanding;
  • retrieval-time use: bring both when needed.

If synthesis overwrites raw memory, the system can accidentally turn an inference into a fact. That is how memory becomes confident but corrupted.

What the paper reports

The paper evaluates StructMem on LoCoMo, a benchmark for long-term conversations. It includes question types such as single-hop, multi-hop, temporal, and open-domain questions.

Some reported numbers are worth noting:

  • StructMem reaches 76.82 overall.
  • It reaches 81.62 on temporal reasoning.
  • Its memory construction uses about 1.937M tokens.
  • It uses 1056 API calls.

Compared with Mem0g in the same table:

  • Mem0g uses about 35.825M tokens.
  • Mem0g uses 53514 API calls.

That gap matters. Memory is not a one-time feature. A long-lived agent has to build, update, retrieve, and consolidate memory continuously. If the memory layer is too expensive, the agent becomes hard to run.

The right takeaway is not “StructMem solves memory.” That would be too strong.

A better takeaway is:

For this benchmark, event-centered structure gives strong temporal and multi-hop behavior while using far less construction cost than some heavier memory approaches.

That is already useful.

What agents should learn from StructMem

For agents, especially smaller models, the lesson is practical.

Do not store only this:

User prefers X.

Store something closer to this:

Event:
- what happened
- who participated
- when it happened
- what relationship or meaning appeared
- what consequence followed
- where the information came from
- how trustworthy the memory is

For example, instead of storing:

The user dislikes morning meetings.

Store:

In a conversation on April 12, the user said they avoid morning meetings because mornings are reserved for deep work. This was directly stated by the user, so trust is high. Consequence: when suggesting schedules, avoid morning meetings unless there is a strong reason.

That memory is longer, but it is much easier for a small agent to use correctly. It includes source, time, reason, and action implication.

Another important rule:

Keep raw memory and synthesis separate.

Raw memory:

On April 12, the user said mornings are reserved for deep work.

Synthesis:

The user tends to protect mornings for focused work.

The synthesis is useful, but it should remain marked as synthesis. It is derived from evidence, not identical to the original evidence.

What StructMem still does not fully solve

StructMem is strong, but it is not magic.

First, the evaluation uses LLM-as-a-judge. That is common, but not perfect. Judge models can be biased, inconsistent, or overly impressed by certain answer styles.

Second, benchmarks are cleaner than real life. Real users contradict themselves, omit context, change their minds, and sometimes give information that should expire.

Third, extraction and consolidation depend heavily on prompts. If those prompts are weak, the memory layer can store bad relations or bad summaries.

Fourth, the paper does not fully solve conflict handling. When new memory contradicts old memory, should the system overwrite the old item, keep both, lower trust, mark the old one as outdated, or ask for clarification?

Production agents need more than event memory. They need:

  • provenance;
  • trust scoring;
  • conflict resolution;
  • privacy boundaries;
  • decay and forgetting;
  • audit trails;
  • a clear distinction between fact, observation, inference, and synthesis.

Without those, even structured memory can become a cleaner-looking mess.

Why this is agent work, not human memory theory

StructMem is inspired by human memory, but it is built for agents.

Humans remember with emotion, embodiment, habit, identity, and reconstruction. Human memory is not just retrieval. It is deeply tied to attention, meaning, survival, social context, and selfhood.

StructMem does not model all of that.

Instead, it borrows one useful shape from human memory: events are easier to reason over than isolated facts.

That makes the paper valuable for agent builders. It suggests that a practical long-term memory system should not be a random chunk zoo. It should preserve the shape of experience.

Final thought

StructMem’s best message is simple:

Do not teach an agent to remember only facts. Teach it to remember what happened.

A useful memory has people, time, relationships, consequences, sources, and a way back to the raw evidence.

That is not full human memory. But it is a better memory shape for long-lived agents.

For small models, it may be even more important: the less reasoning power the model has at runtime, the more structure the memory should provide before the model ever sees it.