Memory Architecture for an AI-Native Company

Most corporate AI systems remember conversations. Autonomous organizations must remember the company.

That difference is structural. A transcript can tell an agent what people said. It cannot reliably tell the agent which decision is active, who approved it, what it superseded, where it applies, or whether the underlying evidence is still valid. Once agents begin executing work, this ambiguity becomes operational risk.

“Organizational memory is not stored conversation. It is governed state with provenance, scope, authority and a lifecycle.

One company, five kinds of memory

A useful architecture separates information by the role it plays in execution. Collapsing everything into one searchable corpus makes retrieval easy and accountability difficult.

Separate the read path from the write path

Retrieval is permissive by design: the system gathers the minimum context needed for a task. Writing must be conservative. An agent hypothesis must not become a corporate fact simply because it appeared in a plausible answer.

The read path

1. Resolve the actor, task, organization and purpose of the request.
2. Apply access policy before retrieval, not after generation.
3. Retrieve current state first, then evidence, related knowledge and history.
4. Rank by authority, freshness, scope and task relevance—not semantic similarity alone.
5. Return compact context with source references and explicit uncertainty.

The write path

1. Classify the candidate as an event, state change, knowledge claim, policy or learning signal.
2. Attach provenance: source, actor, timestamp, evidence and originating task.
3. Validate schema, permissions, conflicts, duplicates and required approvals.
4. Write a new version; do not silently overwrite the record agents previously used.
5. Trigger downstream updates, evaluations and notifications through an auditable event.

A memory record needs an execution contract

Content alone is not enough. Every consequential record should carry metadata that explains how the organization may use it.

• Identity: stable record ID, type and owning domain.
• Authority: author, approver and confidence level.
• Scope: organization, project, team, process and applicable time window.
• Lifecycle: draft, active, superseded, disputed, expired or archived.
• Provenance: source events, documents, tools and transformations.
• Access: who may read, cite, modify or execute against the record.
• Relationships: dependencies, contradictions, replacements and derived decisions.

This contract lets the runtime answer a harder question than “what is relevant?” It can answer “what is authoritative enough for this agent to act on now?”

Conflict, decay and forgetting are first-class operations

Companies change. Prices expire, owners move, policies are replaced and plans are abandoned. A system that only accumulates knowledge becomes confidently wrong.

The memory layer therefore needs conflict detection, explicit supersession, time-to-review, retention rules and confidence decay. “Forgetting” does not always mean deletion. Often it means removing a record from the active context while preserving it as evidence.

The organizational memory loop

1. Work produces events and evidence.
2. Events update operational state through validated transitions.
3. Outcomes are evaluated against the original goal and constraints.
4. Useful patterns become knowledge; recurring failures propose policy or skill changes.
5. Approved changes alter future execution and remain traceable to their evidence.

This loop is what turns an AI-enabled company into a learning organization. The memory is not a passive archive. It is part of the control system.

Design principle

“Agents should retrieve broadly, believe selectively and write conservatively.

At AES, organizational memory is designed together with tasks, approvals, identities and outcomes. That is the only way memory can safely move from answering questions to coordinating work.