Agents everywhere, memory nowhere
Salesforce made Slackbot generally available this month as “your personal agent for work,” alongside seven named Agentforce agents, one per business function. OpenAI shipped Workspace Agents, which plug directly into Slack, Salesforce and the rest of the stack. Meta launched a personal agent the same week. Every vendor has now shipped an agent connected to your tools that gets things done.
Connecting is the part they’ve all solved. An agent can now reach your mail, your chat, your CRM and your files, and the connector count has become the spec-sheet number vendors compare.
Here’s the question the launches don’t answer: when the agent acts, what does it know?
Access is not knowledge
Plug an agent into everything and what it gets is raw material. When you ask it to do something, it searches that material and synthesizes an answer at that moment, from fragments. Contradictory emails, stale notes, a thread where someone floated a price that was never adopted. Run the same request tomorrow and it synthesizes again, and maybe differently.
Search has a second limit that matters more for agents than for people. It answers only the question somebody thought to ask. A person browsing results notices the surprising one; an agent retrieving context for a task takes what matches the query and moves. The message that quietly changed your return policy never contains the words “return policy,” so the agent acting on returns retrieves the old announcement that does, and acts on it, confidently.
Engineers will recognize the pattern as RAG, and retrieval is not the weak link. What matters is the corpus underneath it. Retrieval over raw fragments is archaeology. The dig turns up whatever survived, with no promise that it is the latest layer, which is how an agent quotes the old version of a document as if it were current. Retrieval over maintained conclusions is recall.
None of this is a model problem, and a better model doesn’t fix it. The agent is doing archaeology on every request because nothing between the raw material and the model holds what the company has already concluded.
Seven agents, whose memory?
Salesforce gave its agents names: Casey, Paige, Carter, Hunter and three more. Names are good marketing. I can still name all seven dwarves. Having seven agents raises a question: when Casey in service learns that a customer is closing a hundred of their stores, does Hunter in sales know it before proposing the upsell?
A team of human specialists is at their best when they share what they learn, in standups, in threads, in the CRM note somebody remembers to write. A team of agent specialists needs the same substrate, and a shared set of connectors is not it. What’s missing is the layer where conclusions live. This customer is shrinking, this price is current, this person owns renewals now. Captured once, corrected by a person at first, read by every agent before it acts.
That layer has a boring name. It’s memory, and it’s a different artifact from an index. An index gets bigger. Memory gets more useful.
Why nobody ships memory
Memory demos poorly. Connectors light up on stage. An agent answering a pricing question impresses everyone. What nobody in the audience can tell is whether it answered from the canonical sheet or from a stale thread that happened to match, and that distinction explains the value of memory. Maintained memory also builds slowly, out of a specific company’s traffic, corrected by that company’s people. None of that can happen in real time in front of an audience.
There’s a structural reason too. Every platform selling agents would prefer the durable context to live inside its own suite, so each one builds memory for its own territory and calls it complete. The knowledge in a company’s mail, chat, meetings and documents is required in virtually every context, which is precisely why nobody whose revenue depends on one platform is positioned to hold it.
I build software in this category, a brain that fills from a team’s messages and workflows that act on it with a person approving what gets written, so I have a position here. But the argument stands on its own. There are two ways to trust what an agent does. Approve the knowledge first and let it act, or let the knowledge accrue on its own and verify every action it produces. Both are coherent. The difference is where the human effort goes. Checking actions means re-verifying the same fact every time an agent uses it, while approving knowledge means verifying once, with every later action inheriting the trust. We build for the first path. It front-loads the work and defers the payoff, and it is the version that compounds.
The hard part
The agent launches will keep coming, and the agents will be good. Models improve, connectors multiply, and soon every vendor sells the same commodity: capable agents with access to everything and certainty about nothing.
What’s more difficult is creating an accurate representation of what your company knows. Much of it is in the email and messaging stream, and most of that can be extracted by AI. But it takes human oversight, at least at the beginning, to keep it trustworthy enough for people and agents to rely on. Vendors are busy shipping agents without company-wide memories. We’re aiming to tackle both.