Sentra CEO Ashwin Gopinath argues memory is not a sidecar to intelligence but the layer that decides what reality the reasoning operates on, with knowledge being what was present and memory being the subset of the past that should survive because it changes future behavior. The boulder problem illustrates that the same artifact becomes different memory for sales, product, legal, engineering, and CEO views, so freezing ontology at ingestion traps the system inside a frame that is prematurely right.

Memory Is Purpose

LLMs compressed the internet into weights. Agents need to compress work into state.

LLMs are among the most successful artificial memory systems we have ever built. They compressed a large fraction of public text and code into weights and turned that compression into a new kind of intelligence. The pretraining utility function was simple enough to scale and powerful enough to surprise almost everyone: predict the next token.

Agents need a second kind of memory, one that is built less around prediction and more around consequence. A model can reason over almost anything placed in front of it, but a real agent inside a company has to operate across time: decisions, corrections, commitments, exceptions, dependencies, handoffs, failed attempts, and workflows that exist more in people’s heads than in any system of record.

That problem is on the scale of the model problem itself, and in enterprise settings it is harder in a different way. The model labs had an unusually universal objective, while memory in general and organizational memory specifically changes with role, workflow, permission boundary, risk, time horizon, and action.

The AI memory conversation feels urgent as well as very confused at the same time because of this. Retrieval, long context, knowledge graphs, context graphs, user profiles, agent traces, workflow state, and context engineering are all being described as memory of one kind or another. Some give access, structure, history, personalization, or execution. The market has not failed to see the problem; it has seen the problem in pieces.

The reality however is that memory is not a sidecar to intelligence. A model decides how to reason; memory decides what reality the reasoning operates on. In the enterprise, that reality is the accumulated state of the company: decisions, corrections, exceptions, commitments, dependencies, failed attempts, tacit workflows, open tensions, and human judgments that never fully made it into a system of record.

Knowledge is what was present. Memory is what becomes useful.

Knowledge is what was present: the document, meeting, customer complaint, code diff, ticket, lab result, email, transcript, dashboard, workflow trace, or conversation. Context is the situation that turns stored material into something usable: who is asking, what they are trying to do, what they are allowed to see, what risk attaches to being wrong, and what action follows. Memory is the subset of the past that should survive because it changes future behavior.

The shortest version is this: memory is retained consequence. Purpose is the utility function that decides which parts of the past deserve to survive. Without it, a system can store knowledge, search it, summarize it, connect it, and hand it to a model. It still has no principled way to know what should become memory. The easiest way to see this is to leave software for a moment.

The boulder problem

Imagine a boulder beside a hiking trail. It has size, shape, material, location, texture, moss, slope, shadow, and distance from the path. Those are facts about what is present, but they do not tell you what the boulder is for.

For a tired hiker, the boulder is a seat. For a navigator, it is a landmark. For the person maintaining the trail, it is an obstacle; for a geologist, a sample; for a poet, an image. Someone else walks past and forgets it before the next bend. The boulder did not change. The utility function did.

Meaning is not extracted from knowledge in the abstract. It appears when knowledge is evaluated under a purpose. The same stored event can support many valid memories, and no single graph, embedding, summary, label, or transcript can be the final meaning of it.

The company version

The same thing becomes less abstract inside a company. A customer email is not one memory. Sales may read it as a renewal signal, product as a missing feature, engineering as a technical constraint, legal as an obligation, customer success as escalation context, and the CEO as evidence of a market pattern.

If the system stores that email as a complaint, it helps support and distorts product. If it stores it as a feature request, it helps product and misses legal exposure. If it stores it as churn risk, it helps revenue and causes engineering to ignore the architectural issue underneath. Each label can be valid inside one frame and misleading inside another.

Code makes the point even less forgiving. A small comment can be noise to a feature developer, an onboarding clue to a new engineer, an attack surface to a security reviewer, an incident clue to an SRE, or the difference between a safe change and breaking an implicit contract for a coding agent. The artifact did not change. The work did.

A customer complaint becomes a support thread, then a Slack debate, then a product decision, then an engineering ticket, then a customer promise, then a renewal risk. The memory is not any one artifact in that chain. The memory is the state change across the chain.

Memory is the highest-value compression in AI

Done right, memory is the highest-value compression in AI. Summaries make the past shorter, profiles turn a user into preferences, and graphs turn a company into one interpretation. Memory has to do something narrower and more consequential.

Memory compresses the past into future-relevant state. It keeps the fact that should wake up later, the correction that should change the next run, the promise that should constrain the next email, the failed workaround that should not be retried, the objection that appeared across ten calls, and the architectural invariant hidden in an old comment. Most surrounding noise should disappear.

This is not a defect. A system that remembers everything has postponed judgment. The work is knowing what can vanish, what must remain exact, what should become a rule, what should decay, and what should stay attached to evidence because a different actor needs to reinterpret it later.

In this frame, forgetting is not the opposite of memory. Ungoverned forgetting is a failure, but governed forgetting is part of intelligence.

The price of meaning

The cost of organizing by meaning is that meanings collide. Semantic retrieval works because related concepts are placed near each other, and the same proximity that lets a system generalize also creates interference. Similar memories become neighbors, distinctions get compressed, and the system retrieves something plausible because it is close, not because it is the right state for the action at hand.

In the Geometry of Forgetting, we argued that embedding memories can reproduce the quantitative signatures of forgetting, false recall, and tip-of-tongue-like failures because semantic representations are geometrically crowded (Geometry of Forgetting). In the Price of Meaning, we generalized the claim: under finite effective dimensionality, semantic organization naturally lives on a frontier between usefulness and interference (The Price of Meaning).

Semantic memory is not the problem. The problem is treating meaning as if it were free. If retrieval by meaning becomes the entire substrate, the system eventually confuses similarity with significance.

Exact episodic grounding is the counterweight: source material, time, evidence, provenance, permissions, contradictions, corrections, and outcomes. Semantic memory needs something stable to check itself against.

Sentra’s architecture resolves the latency bottleneck by decoupling semantic consolidation from retrieval. Dynamic projection and semantic reconciliation can become compute-intensive if they happen entirely in the request path, so we move the heavy lifting to an asynchronous state stream. That turns dynamic ontology from a performance liability into a high-performance, precomputed surface. The system does not query a static graph at runtime; it resolves the state projection on demand, giving agents the precision of bespoke ontology at the speed of standard retrieval.

Bigger context is not memory

Bigger context windows reduce some failures, but they solve the wrong part of the problem: they give the model more to read when the real goal is to know what should no longer require rereading. This distinction matters more as inference gets cheaper. If tokens become cheaper, people will use more of them. Agents will run longer, pull more documents, carry more stale history, make more tool calls, and retry more often. Cheaper tokens reduce the pain of waste, but they also make sloppy context feel affordable.

Token attribution is necessary. Companies need to know what an agent run cost and whether it produced a business outcome. But attribution is the scoreboard; memory changes the next run. If an agent spent 120,000 tokens discovering that the auth module changed, the valuable artifact is not the cost report. It is the state change that prevents the next agent from rediscovering the same thing. The cheapest token is the one never spent because the system already knew what mattered.

The cost story is the shallow version. The deeper story is capability. A system with memory can attempt longer work because it does not spend the first half of every run reconstructing the world. Handoffs become less brittle, corrections alter future behavior, and safety improves because obligations, exceptions, and constraints are remembered as state rather than rediscovered as text. The point is not cheaper runs; it is harder runs becoming possible.

Graphs are projections

Graphs are where the argument becomes tempting, because graphs feel like memory. The issue is not the graph itself; it is the timing. A graph is a commitment: these are the nodes, these are the edges, these are the labels, these relationships are worth preserving. That commitment is useful once the task is known. Before the future question exists, the same commitment can trap the system inside a frame that happens to be clean, structured, and wrong for the work. The danger is not that the graph is wrong. The danger is that it is prematurely right.

A customer email can be a complaint, churn risk, feature request, contractual obligation, or roadmap signal. A code comment can be noise, warning, historical note, security clue, or implicit contract. The labels are not false; they are conditional. Freeze one too early and the system becomes intelligent inside the wrong frame.

Semantics at ingestion. Ontology at retrieval.

At ingestion, preserve the richest possible semantic substrate: actors, artifacts, actions, properties, timestamps, modality, source, uncertainty, evidence, permissions, local context, and change over time. At retrieval, let the task supply the ontology. The actor, role, question, permission boundary, and risk profile determine which relationships matter.

This does not mean ingestion is ontology-free. There is no view from nowhere. Even choosing to preserve actors, artifacts, actions, timestamps, uncertainty, and source is a commitment. The practical claim is narrower: ingestion should avoid committing to the business role too early. Preserve enough structure to make future interpretation possible, but do not decide at write time whether an artifact is a complaint, obligation, churn risk, roadmap signal, or architectural warning. The graph should appear when the question appears.

The market has found the pieces

The market is circling the same missing layer from different directions. Profile-memory systems start from the fact that repeated context is waste. Temporal graphs start from the fact that knowledge changes. Runtime-memory systems start from agents needing state outside the prompt. Enterprise search starts from scattered company knowledge. Communication products start from the way decisions evaporate across emails, messages, meetings, comments, and human-agent exchanges. Workflow platforms start from a different truth: action needs guardrails, approvals, and execution paths.

Each insight is correct, but none is the substrate. Some of these wedges can grow into broader memory systems; they are not dead ends. The boundary they have to cross is from storing or retrieving context to deciding what should alter future work.

Mem0, Zep/Graphiti, Letta, Hindsight, Glean, Google Agentspace, Zapier, ServiceNow, Granola, Otter, and others are all approaching memory from different wedges: personalization, time, runtime state, epistemic structure, enterprise search, workflow execution, and communication capture (Mem0, Graphiti, Letta, Hindsight, Glean, Google Cloud, Zapier, ServiceNow, Granola, Otter). The convergence is encouraging: the market is circling the same missing layer.

Put differently, search is mostly about access, profiles about personalization, graphs about relation, temporal graphs about change, agent runtimes about working state, interaction intelligence about communication capture, workflow systems about execution, attribution about measurement, and episodic stores about grounding. Memory sits across all of them because work itself moves across all of them.

Note: I have a more detailed comparison in the addendum section at the end.

Generic memory needs purpose. General memory infrastructure can exist.

A general memory infrastructure is possible when purpose is explicit. The same substrate can support many memories, as long as each memory knows what kind of future work it is meant to improve.

Infrastructure can be shared: storage, provenance, permissions, temporal state, retrieval, graph projection, consolidation, contradiction handling, action feedback, and governance. But the moment the system decides what should be preserved, compressed, surfaced, connected, or acted on, it has entered a purpose.

A sales memory and a code memory do not have the same loss function; neither does a legal memory, a CEO memory, a support memory, or a board-prep memory. They draw from the same substrate, but they cannot collapse into the same significance function.

The shared layer does not erase domain-specific memory. It makes domain-specific memory possible without forcing every function to build its own isolated past. Sales, code, legal, support, and executive memory should have different loss functions. Sentra’s architecture keeps them drawing from the same evidence, provenance, permissions, temporal state, and action feedback without collapsing them into one universal significance function.

Many systems quietly break here. They build a universal store and hope retrieval can recover intent later. Often it returns a plausible artifact while missing the role that artifact should play. The solution is not remembering more; it is representing what kind of later work the memory is supposed to improve.

What a real memory substrate requires

The architecture implied by this is strange at first: preserve the past without deciding too early what the past means. A real substrate needs five things: exact episodic record, shared semantic state, a purpose layer, governed consolidation and forgetting, and action feedback.

The episodic record is the source material: traces, meetings, messages, documents, tickets, code changes, approvals, corrections, and outcomes. Without it, the system cannot verify or reinterpret its own memories. Shared semantic state adds actors, artifacts, actions, properties, timestamps, sources, evidence, uncertainty, relationships, permissions, and local context. It is more structured than raw text and less final than a graph ontology.

The purpose layer tells the system which parts of the past should matter now: actor, role, task, risk, goal, time horizon, permission boundary, and expected action. Then ontology can happen at retrieval, where a sales agent sees objections and commitments, a coding agent sees invariants and prior fixes, and a legal agent sees obligations and exceptions.

The purpose layer is not a magic classifier. It is where product surface, policy, ontology, feedback, and human correction meet, and it is how the company teaches the system what kind of future work the memory is supposed to improve.

The human-in-the-loop paradox, the objection that governance is too manual to scale, disappears when human correction is treated as a first-class data signal rather than a manual chore. In our substrate, human feedback is not a post-hoc repair; it is part of the control plane. Exceptions, corrections, and re-labeling become learning events that refine semantic state. Governance becomes a continuous loop, moving the burden from the human user to the architecture itself.

Retrieval here is more than lookup. The system is applying a purpose, selecting a lens, resolving permissions, checking evidence, and projecting the right graph for the task, not fetching a stored answer. Sentra addresses the cost directly by separating the asynchronous consolidation path from the online retrieval path, so the system can preserve adaptability without paying the full cost at runtime.

Consolidation and forgetting have to be governed. Some memories should remain exact, some can be summarized, some should become rules or precedents, some should decay, and some should be archived but retrievable. When an agent acts, a human corrects it, a workflow succeeds, a customer renews, a bug reappears, or a commitment is missed, the result should feed back into the substrate. Otherwise the system stores traces but does not learn from work.

Company Brain

Company Brain is the enterprise form of this thesis. Companies do not need another searchable archive; they already have too many. The missing layer is a living, permissioned memory of work: what changed, who owns it, what was promised, what failed, what should wake up later, and which prior corrections should alter future execution. At Sentra, this is the layer we are building toward: shared semantic state for the company.

The distinction between a rigid knowledge graph and a fluid semantic state is the core of our infrastructure. We address the ontology debt trap with a multi-layered state model: preserve the raw episodic evidence, maintain consolidated semantic state, and dynamically project the relationships required by the task at hand. This gives agents the structural benefits of a graph without the fragility of premature, write-time labeling.

Factual memory remembers what exists and what happened: docs, tickets, customers, calls, code, dashboards, incidents, owners, artifacts, decisions once they become artifacts, and how they connect. Interaction memory remembers what people and agents meant, debated, promised, implied, contested, and left open across emails, messages, meetings, comments, calls, reviews, handoffs, and human-agent exchanges. Action memory remembers how work actually gets done: the lived workflow, the trigger that should wake it up, the guardrail that should stop it, and the outcome that should alter the next run.

These are not three products. They are three views over one shared state, which is why splitting them apart too early recreates the same memory problem inside the memory product.

A customer says on a call, in an email, or in a Slack thread, “We can renew, but only if export controls are fixed before Q3.” That sentence should become different memory for sales, product, legal, engineering, and the CEO. It should constrain the next follow-up, shape the roadmap, wake up before Q3, survive the handoff when the account owner changes, and remain attached to the evidence because legal needs the exact words later. A transcript, thread, or message archive can store the sentence. A Company Brain remembers what the sentence now changes.

Factual memory alone becomes enterprise search. Interaction memory alone becomes communication capture: notes, transcripts, threads, summaries, and message history. Action memory alone becomes workflow automation. A Company Brain requires all three because work rarely stays in one artifact. It moves from call to email to thread to decision to ticket to commitment to risk to action to outcome. The memory is the state change across the chain.

The model generates the answer. Memory decides the world.

The next bottleneck in AI is larger than reasoning: it is state. Reasoning and state are entangled, of course, and stronger models can reconstruct more from context. But reconstruction is not the same as memory, and repeated reconstruction becomes the tax every agent pays when state does not survive.

The model labs build the most capable reasoners, but reasoners need remembered worlds. In the enterprise, that world is not the internet and it is not the prompt. It is the accumulated state of the company: what changed, who owns it, what was promised, what failed, which corrections mattered, which exceptions apply, and what should happen differently next time.

LLMs proved that compression can produce intelligence. They compressed public language into weights under the objective of next-token prediction. The next compression problem is private, changing, permissioned, and action-bearing: what should survive from the past because it changes what happens next.

This layer will not replace frontier models; it will sit underneath them. Every agent, no matter whose model powers it, needs to know what to see, what to trust, what to ignore, what to preserve, and how one run should change the next. Memory can sneak up on the model labs precisely because it looks like infrastructure. If agents become the way companies operate, the memory layer has a credible path to becoming the control plane for applied intelligence. The model generates the answer. Memory decides what world the answer belongs to.

Addendum: the memory market through this lens

The tables below are not meant to rank companies. It is a way to read the market generously and skeptically at the same time. The best case asks what each system has genuinely discovered about memory. The hardest critique asks where it still stops short of a purpose-conditioned memory substrate.

The pattern is the point. Each wedge is right about something: access, personalization, temporal truth, runtime state, epistemic structure, workflow execution, communication capture, or research architecture. None of those pieces should be dismissed. But none of them, by itself, answers the Company Brain question: what from the past should survive because it changes future work?

At Sentra, we’re building a “company brain”, a shared intelligence/memory layer that sits on all communication channels, knowledge bases, action and agent traces to understand how everyone in an organization actually works as well as how work actually gets done, constructing a living world model of the entire company in near real time. The memory substrate also be pointed to specific internal knowledge bases and code repos to significantly reduce token usage (average saving between 45-70%) with no loss in accuracy (sometimes much better accuracy).