Organizational memory is becoming an AI infrastructure problem.

The industry is putting more work into context.

The conversation about enterprise AI has moved beyond writing a better instruction. Teams building agents now have to decide what information to provide, when to retrieve it, what to retain between tasks, and how to prevent yesterday’s assumptions from becoming today’s confident answer. That is an infrastructure problem as much as a prompting problem.

Anthropic’s September 2025 context-engineering essay describes context as a finite resource that must be curated across an agent’s work. It discusses retrieval, compaction, and persistent notes as ways to keep long-running tasks coherent. Glean’s Enterprise Graph describes a related enterprise concern: connecting people, content, and activity so an AI system can interpret information in the context of an organization.

These are different products and technical approaches. Together, they show where builders are investing: the useful information around a model increasingly matters alongside the model itself. Neither source establishes that every company needs the same architecture. Our reading is narrower: an agent that acts across a company needs a dependable account of that company, not just access to its files.

Sources: [1][2]

A relevant document can still give the wrong answer.

Consider a customer rollout discussed in a contract, a project board, and a later email. The contract contains the original deadline. The project board contains the team’s working date. The email records a newly approved change. A search system could retrieve all three accurately and still leave the agent with the hardest part of the problem: deciding which statement applies, to whom, and from when.

Adding more text does not settle that question. The answer depends on relationships between the records. Was the email an authorized change or an informal suggestion? Did it apply to the whole rollout or one workstream? Did the change take effect before the agent’s task began? A fluent summary can hide these distinctions unless the underlying record keeps them visible.

This is why we distinguish organizational memory from a cache of previous conversations. Conversation memory can help one agent resume its work. Organizational memory also has to reconcile contributions from many people and systems, preserve disagreement, and support other authorized users who were not part of the original exchange.

History and access belong inside the context model.

An organization learns about changes after they happen. A commitment may be revised on Tuesday and recorded on Thursday. A reconstruction of Wednesday’s decision therefore needs two answers: what was effective in the business, and what information was available to the decision maker. Updating a single current-value field destroys that distinction.

Martin Fowler’s explanation of bitemporal history describes this as the difference between actual history and record history. The idea predates today’s agent systems, which is precisely why it is useful. We do not have to invent a new account of time just because a language model consumes the record.

Access adds another boundary. Information available somewhere in the company is not automatically available to every agent. A useful briefing should be relevant to the task and filtered to the requester’s permissions. It should also make uncertainty legible. A claim supported by an old note must not silently acquire the confidence of a current, authoritative source merely because it appears in a polished answer.

Sources: [3]

We are building memory around evidence and change.

Our response is to make the connected record the foundation for both people and agents. Sources contribute claims about decisions, commitments, relationships, and outcomes. Those claims carry provenance, confidence, and time. New evidence can update or supersede an earlier claim while preserving the history needed to understand how the organization’s knowledge changed.

That record supports answers and operational intelligence, and connected agents can request permission-filtered organizational context through supported tools. The aim is to give an agent a useful, bounded briefing rather than an unrestricted copy of everything the company knows. Private member knowledge enters shared intelligence only through an explicit contribution.

Context and authority remain separate. Learning that a customer expects a refund does not authorize an agent to issue one. A proposed action still needs the relevant permission and governance checks. Memory should improve the basis for a decision without becoming a hidden way around its controls.

Evaluate memory by how it handles a change.

A useful evaluation starts with a disagreement or late update, not a perfect knowledge base. Introduce two conflicting statements, then record a correction with a different effective date. Ask the system to explain the current position and reconstruct the earlier one. Repeat the task using a requester with narrower access.

The test is whether the answer preserves the distinctions that matter. Can a reader follow the evidence? Does the system identify what remains unresolved? Can an agent obtain enough context to continue without seeing information outside its scope? These questions tell you more about organizational memory than a demonstration that retrieves an easy fact.

Memory cannot compensate for a source that was never connected or a change nobody recorded. It can, however, make the limits of the available record clearer. That is the direction we are taking: context that helps work move forward while remaining accountable to the evidence behind it.

• Test conflicting and superseded claims, not only successful retrieval.
• Keep effective time distinct from the time a change was learned.
• Check the same question under different permissions.
• Verify that context access never grants action authority.