Company Memory Should Not Live in Chat
Earlier this month we changed who our cold outreach speaks to.
It took three edits to one file. By the afternoon, every agent drafting an email for us was writing to the new reader.
That only worked because none of those agents carried a private memory of the old one. If each had quietly remembered the pitch from spring, we would have spent weeks discovering which drafts came from which version of the company.So we run our agents with personal memory off.
Not because memory is bad. Memory is useful. But private memory is a single-player feature, and a company is not a single-player game.
Private Memory Creates Private Companies
Every assistant now remembers, and for one person working alone the feature is genuinely useful. It saves time. It reduces repetition. It lets the assistant adapt to how you work.
The trouble starts at two people.
Each person's assistant builds its own picture of the company. Yours remembers the pricing discussion from March. Your colleague's remembers the version from the offsite. A third teammate's assistant learned the roadmap from a document that was superseded a month ago.
None of these pictures can be read by anyone else. None of them has an owner. And when the company changes its mind, there is no way to reach into those memories and update them.
The change lands in some sessions and not others, depending on who happened to talk to their assistant about what, and when.
That is the failure mode. Not an AI that knows nothing, but five AIs that know five different companies, each of them confident, none of them accountable.
One agent writes outbound to the old buyer. Another answers a customer with the previous pricing logic. A third drafts product copy from a roadmap that no longer exists. Nobody intended to use stale context. Nobody even knew it was there.
You find the divergence the way teams always find it: after something wrong has already left the building.
The Problem Is Unowned Remembering
The question is not "should AI remember?" The question is "where should company memory live?" For one person, private memory saves real time. For a team, every privately remembered fact is a fact nobody else can see, correct, or audit.
If an assistant remembers your preferred tone, that may be harmless. If it remembers who your product is for, how your pricing works, what your roadmap says, which claims legal has approved, or what sales should promise, that is no longer personal context.
That is company context. And company context needs company-grade handling.
It needs an owner. It needs a version history. It needs permissions. It needs a way to see what changed, when it changed, and what the agent read before it acted. Private chat memory has none of that.
What Shared Memory Looks Like
Anything an agent should retain about our company gets written down where everyone can see it: as an entity in our shared workspace, with an owner and a version history.
An entity is a durable piece of company context: a customer segment, product claim, metric definition, roadmap fact, workflow rule, launch note, or list of what shipped.
When an agent finishes work worth keeping, it writes the result there, through a single validated gate. When any agent starts work, it reads the current version, the same one every other agent and every person on the team reads.
Memory did not disappear. It moved. From a private feature to shared infrastructure. The difference is simple:
- Anyone can read it.
- Someone owns it.
- Versions are kept.
- The team can check what the AI knew when it acted.
That last part matters. When an AI produces something important, the question is not only whether the output was good. It is also whether the context was correct.
With private memory, that question is almost impossible to answer. With shared context, it becomes inspectable.
Why a Shared File Is Not Enough
A shared markdown file is the honest first step. Plenty of teams start there, and they should. It is far better than pasting the same instructions into every assistant by hand. But a shared file is still one flat text.
It usually has no owner per fact. No clean version history per entity. No record of which agent changed what. No rules about who is allowed to update which piece of context. And it only reaches the agents someone remembers to point at it.
That works for a small team for a while. Then the file becomes long, vague, and political. People stop knowing which parts are current. Agents read too much or too little. Important facts are hidden inside paragraphs written for humans, not operational context meant to be used at the moment of action.
Entities solve a different problem.
They give each important fact its own place, owner, history, and rules. Agents read them when they act, not when someone last pasted a file into a chat.
The Seconds Are Worth It
The obvious objection is speed. Does reading before acting slow agents down?
Yes. By seconds.But a confident answer built on stale private memory costs much more than that. It costs a customer conversation, a wrong draft, an internal disagreement, or an afternoon tracing where the bad fact came from.
We will take the seconds. The goal is not to make every agent feel magically personal. The goal is to make every agent work from the same company.
The Push Log
The clearest example is the Push Log, our name for the workflow where every change merged into our codebase writes itself into the shared record.
When a change is merged, the agent writes what changed, why it changed, and which product surface it affected into the Push Log.
No agent remembers what shipped. No person has to either. The record does, once, for everyone.
When someone asks what changed, the answer does not depend on which assistant they ask or which engineer happened to explain it last week. The workspace has the current record. The agent reads it. The team reads it. Everyone starts from the same place.
That is the pattern we want everywhere company memory matters.
The Numbers, Stated Plainly
Our workspace currently holds 139 entities.
The outbound playbook that changed earlier this month is at version 4. Version 2 still exists, because nothing is ever overwritten. The Push Log holds 16 entries.
Every blog post we have written lives there too, this one included, drafted by agents reading the same workspace they are written into. Small numbers, stated plainly. But every agent and every person here works from the same ones, and that is the whole point.
The Point
Private memory makes an assistant feel smarter to one person. Shared memory makes a company smarter together. Your AI does not know your company by remembering private conversations. It knows your company when the company gives it shared context it can trust.
That is what Sento is for.
Frequently Asked Questions
But model memory is useful.
It is. This article is not against remembering. It is against unowned remembering.
For one person, private memory saves real time. For a team, every privately remembered company fact is a fact nobody else can see, correct, or audit.
The answer is not to make AI forget everything. The answer is to move company memory somewhere shared, owned, and versioned.
Isn't this just a shared instructions file?
A shared instructions file is a good first step. Many teams should start there.
But it is still one flat document. It usually has no owner per fact, no clean version history per entity, no record of which agent changed what, and no rules for who is allowed to update which piece of context.
It also only reaches the agents someone remembers to point at it. Shared memory should be read by agents at the moment they act, not depend on someone pasting the right file into the right chat.
Doesn't reading before acting slow agents down?
Yes. By seconds.But a confident answer built on stale private memory costs much more than that: a customer conversation, a wrong draft, an internal disagreement, or an afternoon tracing where the bad fact came from.
