Transactive memory in the age of AI agents: the directory service problem

In January 2026 Forbes ran a piece arguing that transactive memory may be the key to unlocking value from agentic AI. Google Research published a paper framing AI agents within transactive memory theory. A theory developed in 1987 to explain how married couples remember things has become one of the more useful frames for designing systems of software agents.

This is not a coincidence, and for firms it carries a practical implication that is easy to miss.

The same problem, in a new substrate

An agent fleet has exactly the structure Wegner described. No single agent can hold everything: context windows are finite, tools are numerous, and an agent that knows every procedure is worse at all of them than a specialist would be. So the work gets divided. One agent handles retrieval, one handles document parsing, one handles the domain logic.

The moment you divide it, you inherit the directory problem. An agent does not need to know how to do everything. It needs to know which peer to route to, and how much to trust what comes back. The pattern that has emerged in agent architectures, usually called a directory service or a registry, is a transactive memory system implemented in software, and the three dimensions map cleanly:

Research on agent memory has begun separating memory types along similar lines: episodic memory for what happened, procedural memory for how to do things, and transactive memory as the layer that models team level capability. That last one is the coordination layer, and it is the one that determines whether a fleet of ten agents outperforms one large one or simply costs ten times as much.

Where firms get this backwards

Here is the part that matters commercially. Firms are buying agents, and expecting the agents to supply the memory.

They will not, for a reason that has nothing to do with model capability. An agent's directory is built from what it can see. Point a capable agent at a firm's shared drive and it can tell you which documents exist. It cannot tell you which partner has genuinely led that kind of engagement, which stakeholder relationship survived a difficult procurement, or which of two apparently similar past projects is the one worth reusing. Those are facts about the firm, and they were never written down anywhere the agent can reach.

An agent fleet inherits your firm's transactive memory. If the firm does not have one, the agents do not either.

The failure mode is specific and worth naming, because it is already happening. Ask a general purpose agent with access to a firm's document store "who here has done regulatory price control work?" and it will answer. It will name people. The names will be drawn from whoever appears most often near the relevant words, which correlates with expertise about as well as email volume correlates with contribution. The answer will be fluent, plausible and unverifiable, and a partner will act on it once, discover it was wrong, and never ask again.

That is credibility failure, arriving faster than it ever did with humans. A colleague who is wrong once gets a second chance. A system that is confidently wrong once is finished.

What the human research says about the mixed case

The work on human and AI teams is more nuanced than either the optimistic or the dismissive reading. One finding worth carrying: in studies of teams that include AI agents, accessing information from the agent was positively associated with the team generating novel hypotheses and with members speaking up, but the effect held mainly in already higher performing teams.

Read that carefully. The AI did not create the coordination. It amplified coordination that was already there. Teams that already had a functioning transactive memory got more out of adding an agent to it. Teams that did not, did not.

This is the least convenient finding in the literature for anyone selling AI as a fix for organisational dysfunction, and it is consistent with forty years of results on technology and organisational memory going back to the MIT Sloan work in the nineteen nineties, which reached the same conclusion under a blunter title: technology is not enough.

What a firm should actually do with this

Three things follow, none of which require a view on which model to use.

Treat the directory as infrastructure, not as an AI feature. The record of who worked with whom, on what, with what evidence, is durable. It outlives whichever model reads it. Building it is not an AI project, and it should not be scoped or budgeted as one.

Insist on provenance at the interface. Any system answering questions about your firm's own experience should return the document behind each claim. This is not a compliance nicety. It is the only mechanism by which credibility, in the transactive sense, can be established between a person and a system that has no track record with them.

Expect the agent to say it does not know. A directory that reports coverage it does not have destroys the system, because people stop asking. If the firm has never done a piece of work, the honest answer is the valuable one, and a system that cannot produce it is not usable for the decision it is being consulted about.

Why we built the human version

OrgAtlas is not an agent framework. It is the layer underneath one: the firm's transactive memory, written down, assembled from the proposals, reports and email the account team already produces, with every fact tied to the document it came from and gaps drawn as gaps.

The bet is straightforward. Agentic systems will keep improving, and every one of them will need to be told what the firm knows. The firms that can answer that question with evidence will get compounding value from every model generation. The firms that cannot will keep buying assistants that are fluent about everything except the one organisation they were bought to help.

Next: why an AI system for firms has to answer with sources rather than with prose