The Company Brain: one memory across every channel.

Every revenue team runs on context: who the account is, what was promised on the last call, which objection keeps coming back. In most stacks that context is scattered across six tools, none of which can read the others.

Integrations move data. They do not share understanding.

A typical stack syncs fields between systems: a name here, a status there. Syncing rows is not the same as sharing a memory. The dialer does not know what the last email said. The sequencer does not know the call went badly. The CRM knows a stage changed but not why, and the rep becomes the integration layer, carrying context between tools in their head.

Every integration added is another seam to maintain and another place for context to leak. The seams are also where the contradictions live: two systems holding different answers to the same question, with nothing to arbitrate between them.

One place to read from, one place to write to

The alternative is to give every capability a single record to read from and write to. When a call ends, a message sends, or a meeting is booked, the event is normalised and written to the account with its source attached. The next agent to touch that account reads the same memory the last one wrote, rather than a copy that has drifted.

That sounds like a database, and the difference is what the record keeps. A row holds the current value. A memory holds when the fact was true, when the system learned it, and what it was derived from, so that a question about last quarter can be answered as it stood last quarter rather than as it looks now.

Why time is two fields, not one

The distinction that does the work is between when something was true and when it was recorded. A deal that slipped in June and was updated in July is two different answers to two different questions, and a single timestamp cannot express both. Keeping them separate is what makes it possible to ask what we believed on the day we lost the deal, rather than only what we know now.

It also changes what correcting a mistake means. A fact that turns out to be wrong is retired rather than overwritten, so the record shows both what was believed and when it stopped being believed. Overwriting is faster and destroys the only evidence that anyone was ever wrong, which is the evidence a forecast review actually needs.

A CRM stores what happened. A memory can be asked what it thought at the time, and answer differently from what it thinks now.

Permissions belong in the memory

Access control bolted on top of a shared memory fails in a predictable way: the memory answers, and the check happens somewhere the answer has already passed. Every agent inherits the clearance of the person it acts for, and the resolution happens where the read happens, not in a wrapper around it.

This is less convenient than it sounds. It means an agent acting for a rep genuinely cannot see what that rep cannot see, including when that would produce a better answer, and the correct behaviour when the context is out of reach is to say so rather than to work around it.

Why this matters for agents specifically

An agent is only as good as what it knows. Give it a fragment and it will fill the gaps fluently, which is the failure mode that erodes trust fastest. Give it the whole relationship, grounded in signals with sources attached, and it can draft something a rep will send unedited and explain why it said what it said.

That is the whole idea. Not another integration to maintain, but one memory the entire motion builds on, where the interesting question stops being which tool has the data and becomes what the account actually needs next.

What it costs to build it this way

A shared memory with time and provenance on every fact is materially harder to build than a set of synced tables, and the cost shows up in places that are easy to underestimate. Every write needs a source. Every correction needs to preserve what it replaced. Every read needs to resolve permissions where the read happens rather than in a wrapper.

It is also slower to demo. A system that answers as of last quarter is indistinguishable from one that just answers, right up until the moment somebody asks a question about the past and gets a different answer than they got yesterday from a database that quietly overwrote itself.

The question to ask any vendor about this

There is one question that separates a shared memory from a well-marketed integration layer: ask what a fact in the system can tell you about itself. Where did this value come from, when was it true, when did you learn it, and what would I see if it had been corrected?

A system that cannot answer those has rows, not memory, and no amount of connective tissue between tools turns one into the other. It is a fair question to ask of us as well, which is the point of writing it down.

None of this is free, and it is worth naming the tradeoff plainly. A memory that records when it was wrong grows faster than one that quietly overwrites, and it makes some questions slower to answer than a flat table would. We think that is the right trade in a system whose whole purpose is to be relied on for decisions about money, but it is a trade rather than a free win.

The practical test of whether a stack has a shared memory is what happens when two systems disagree. In most stacks nothing happens: both answers persist, each looks authoritative in its own interface, and a person eventually notices and picks one. A shared memory forces the contradiction to surface at write time, which is uncomfortable and considerably cheaper than discovering it in a QBR.

• Product
• Company Brain
• Agents