PlexaraOne bucket is not enough
The simplest way to give an agent memory is to write everything it learns into one store and search that store later. It works in a demo and falls apart in production. A schema change from last quarter, a column definition, the name of the team that owns a dataset, and one user’s export preference all end up in the same pile, and recall returns whatever happens to be textually nearest rather than what is actually relevant.
The result is the opposite of what memory is for. Instead of sharpening the working set, undifferentiated recall fills it with near-misses, and the context window degrades under the weight of memories that should never have surfaced. The agent does not feel like it remembers. It feels like it ran a noisy search.
The memory research bears this out. Surveys of agent memory organize it by both how long it lasts and what form it takes, because a durable fact and a passing event are not the same kind of thing and should not be handled the same way. Benchmarks built for long-term conversational recall measure exactly the multi-session and temporal reasoning where a single flat store breaks down.
One store, or five
Everything in a bucket
One undifferentiated store
- A schema change and a formatting preference sit in the same pile
- Recall returns whatever is textually nearest, relevant or not
- No way to age out events without losing durable facts
- Context arrives noisy, and the working set fills with the wrong things
Stored by kind
Five typed dimensions
- Each kind of knowledge is indexed the way that kind needs
- Recall can target facts, history, people, links, or habits
- Events carry time; preferences carry a user; facts carry an entity
- The right context surfaces because it was filed correctly
Five dimensions
Plexara structures memory into five dimensions, so each kind of knowledge is stored, indexed, and recalled the way that kind needs. Knowledge is the durable facts: what a column means, what a business rule requires. Events are the things that happened: a migration, an incident, a schema change, each carrying a time. Entities are the people, systems, and teams in the data landscape and the roles they play.
Relationships capture how those entities and datasets connect, the links that let recall move from one thing to the things around it. Preferences hold the per-user details: a formatting choice, an export habit, the column a particular analyst always wants. None of these is reducible to the others, and that is the point. A fact has no timestamp the way an event does. A preference belongs to a person the way a fact does not.
Filing memory by kind is what makes targeted recall possible. When the agent needs the history of a table, it can ask for events. When it needs to honor how someone works, it can ask for preferences. The structure is what turns "search the memory" into "recall the right kind of thing."
The five dimensions
Knowledge
Facts about data, business rules, and domain expertise.
"Column amt is the gross transaction amount in cents; divide by 100 for display."
Events
Things that happened: migrations, incidents, schema changes.
"The revenue table was restructured in Q3 2025; the old columns are deprecated."
Entities
People, systems, teams, and their roles in the data landscape.
"The finance team owns all revenue datasets and prefers net_amt over amt."
Relationships
Connections between entities, datasets, and business concepts.
"The orders table feeds the revenue pipeline through a nightly ETL job."
Preferences
User-specific settings, formatting choices, and workflow habits.
"This user prefers CSV exports with headers and ISO date formatting."
Four ways to recall
Storing memory well is half the problem. The other half is retrieving it, and different questions need different retrieval. Plexara composes four strategies. Entity lookup fetches the accumulated context of a known dataset directly. Semantic search finds conceptually related memories when the relevant dataset has not been named yet.
Graph traversal follows DataHub lineage, so when an agent queries a derived table, memories about its upstream sources surface on their own. Auto mode runs all three and merges the results with deduplication, and it is the default, because most of the time the agent should not have to choose. When it does know what it needs, it can name the strategy directly.
The strategies and the dimensions reinforce each other. Lineage traversal is only useful because relationships were stored as their own kind. Entity lookup is only sharp because facts were filed against the entities they describe. Structure on the way in is what makes precision on the way out possible.
Four ways to recall
Entity lookup
Direct retrieval by dataset or entity reference, for the accumulated context of a known table.
Semantic search
Vector similarity over memory content, for exploratory questions where the dataset is not yet named.
Graph traversal
Follows DataHub lineage, so memories about upstream sources surface when you query a derived table.
Auto (combined)
Runs all three and merges with deduplication. The default, covering every recall path at once.
Personal, then promoted
Memory is scoped to a user and a persona. It captures what an individual taught the agent during their own work, and it does not leak into anyone else’s sessions by default. That isolation is deliberate: one analyst’s working notes are not automatically everyone’s.
Sharing happens through one explicit path. When an observation in someone’s memory is worth generalizing, an admin reviews it and promotes it through the insights pipeline, where it becomes catalog documentation every future agent can draw on. That is how usage turns into durable, organization-wide knowledge without turning every private note into shared truth.
Personal, then promoted
Personal
Memory is scoped to a user and persona. It captures what that person taught the agent.
Reviewed
An admin reviews an observation worth sharing and promotes it through the insights pipeline.
Org-wide
Promoted, it becomes catalog documentation every future agent can use. Nothing leaks by default.
The shape of memory is the point
Persistent memory is not a single feature you switch on. It is a structure: five kinds of knowledge, each stored as itself, each recalled by the method that fits it, scoped to a person until it is deliberately shared.
That structure is why memory across sessions can feel like the agent actually remembers. Not because it stored more, but because it stored the right things in the right shapes, and can find them again on purpose.
Further Reading
A Survey on the Memory Mechanism of Large Language Model based Agents
Zeyu Zhang, Xiaohe Bo, Chen Ma, Rui Li, Xu Chen, Quanyu Dai, Jieming Zhu, Zhenhua Dong, Ji-Rong Wen · 2024
A survey of how memory in LLM-based agents is designed and evaluated, organizing memory by temporal type (short-term and long-term) and structural form (episodic, semantic), and arguing that different kinds of knowledge call for different storage and retrieval.
Evaluating Very Long-Term Conversational Memory of LLM Agents
Adyasha Maharana, Dong-Ho Lee, Sergey Tulyakov, Mohit Bansal, Francesco Barbieri, Yuwei Fang · 2024
Introduces LoCoMo, a benchmark for long-term conversational memory built from very long multi-session dialogues. It evaluates recall across single-hop, multi-hop, temporal, and adversarial reasoning, the kinds of long-range recall where a single undifferentiated memory store tends to fail.
Memory for Autonomous LLM Agents: Mechanisms, Evaluation, and Emerging Frontiers
Pengfei Du · 2026
A recent survey framing agent memory along dimensions of temporal scope, representational substrate, and control policy, and surveying mechanism families from retrieval-augmented stores to reflective self-improvement.