Agent memory is only a moat if you can export it

Teams are pouring months into company-brain memory layers: shared context that helps agents remember customers, decisions, policies, exceptions, and prior work. Slite describes “company brain” as a 2026 category term tied to a plain operational problem: agents were failing in production because they lacked organizational context (Slite).

The tools under those memory layers keep changing. The memory is supposed to last longer than the tool.

That makes ownership the buying question. Your agents’ accumulated context is valuable to your business when you’re the controller of record, you can get it out in a usable format, you know the deletion window, and your content trains no model.

Memory still needs evaluation. If you’re mapping how agents keep what they learn, ownership is the next question to ask.

Whose asset is your agent’s memory?

Whoever can export the memory owns the asset in practice.

LangChain’s April 2026 analysis warned that proprietary agent scaffolding and memory storage are tightly coupled, so interaction history often sits with the vendor that owns the surrounding system (LangChain). Baheet’s essay makes the argument in business terms: whoever owns the memory owns the agent, because memory is the record of what the agent learned, decided, and did (Medium).

Category marketing already knows how to talk about control features: SSO, encryption, audit logs, permission-aware retrieval, and bring-your-own model keys. Sentra’s company-brain checklist is a useful representative example of that control language (Sentra).

Those controls matter. They leave the hardest question open: whether you can leave with the accumulated context your team paid to create.

A customer list is valuable because you can take it with you. Agent memory works the same way. If the memory can’t move, your operations are filling someone else’s moat.

What does ownership look like in the contract?

Ownership has four parts. Ask these questions out loud on the vendor call.

1. Who is the controller of record for the content your agents produce, and who keeps IP in inputs and outputs? “Your data is safe” is too vague. Ask who controls Customer Content and who owns the work created from it.
2. What is the export format, and does it include the resolved entity graph or only raw documents? A folder of transcripts is different from a usable memory layer. Ask whether relationships between customers, contacts, accounts, policies, tasks, and decisions come with you.
3. What is the deletion window after termination, and what is retained past it? Get the off-ramp before renewal pressure appears. Ask when content is available, when it is deleted, and what logs or account records survive.
4. Is any of it used to train a model, ever? Fine-tuning, evaluation sets, anonymized improvement programs, and “service enhancement” language all belong inside this question.

Levain answers those questions this way: the customer is controller of Customer Content and keeps IP in inputs and outputs. Content is available on request within 30 days of termination, then deleted. Customer Content is never used to train any model.

Expect that level of specificity from any vendor before deciding where your company’s operating memory lives.

Why does a company brain take months?

The slow work is deciding what things mean, then keeping those meanings stable.

Ingestion is the visible work: connect the docs, sync the CRM, pull in tickets, import Slack, scrape the wiki. The months usually go into ontology and entity merging.

Ontology is the working map of your business: customers, products, policies, roles, processes, and how they relate. Entity merging is the decision that “Acme Corp,” “Acme,” “ACME Inc.,” and account ID 4471 are one customer, then keeping that decision true as systems drift.

Stripe’s Kai shows the shortcut many companies lack. According to Lenny’s Newsletter, infrastructure Stripe had already built for human developers turned out to be exactly what agents needed, and Kai scaled to roughly 2,000 packaged skills with evals and telemetry around it (Lenny’s Newsletter).

That is why export format matters more than export existence. If an export gives you raw documents without the resolved entity graph, you get the ingredients back while the vendor keeps the recipe.

Should agents share one memory?

Shared memory should be scoped per workspace.

A shared company brain helps agents carry context across workflows. Sales support can know what implementation promised. Finance can understand why a contract has an exception. Operations can see which policy applied the last time this edge case appeared.

The same shared context creates a breach surface. If an agent can reach everything, a bad instruction, bad permission, or bad tool call can travel farther than the task requires.

Stripe’s experience is a useful warning. Lenny’s Newsletter reports that agents nearly took down production systems, and that Stripe’s “Projects” functioned as a governance mechanism, with employees retaining control over what their agent could reach (Lenny’s Newsletter).

A project boundary acts as a safety boundary. Levain’s knowledge base is per workspace for the same reason: memory should follow the work context, the people allowed to use it, and the risk of the actions attached to it. That is where containment beats detection rates.

Shared context makes agents better informed. Keep evaluation beside memory, especially when an agent has access to systems that matter; that is one lesson from what production agent architecture converges on.

Run the four questions against whatever memory layer you’re evaluating now. If Levain is on that list, ask us the same four on a call and expect the answers in writing.

Estimated reading time: 4 min