Richmond Alake on Memory and the Intelligence Plane for AI Agents

Richmond Alake opens by asking the audience about agent memory. He says awareness has grown since he began discussing it, and defines memory as the mechanisms an agent uses to retain, reuse, recall and refine information: his four Rs.

Memory can be categorized by duration, such as short- and long-term, or by function, such as semantic, episodic, procedural and working memory. Alake uses this taxonomy as a starting point before introducing a broader way to think about an agent system.

He defines a control plane as centralized management for how agents are governed: their identity, policies, guardrails, orchestration, permissions and auditability. Various companies provide control-plane components, and he considers those systems necessary.

Alake then discusses the software factory: a system that follows repeatable processes to produce software reliably, potentially using multiple agents in parallel. He notes that the phrase predates modern agents and attributes an early use to Bob Bemer at General Electric in 1968.

His proposed next layer is an intelligence plane. He cautions that he is offering a way to think about existing components rather than claiming all the underlying ideas are new. It spans the agent stack and concerns how systems learn from data and memory.

To illustrate the difference between access to information and interpretation, Alake recounts the World War II code-breaking effort that identified the Japanese code AF with Midway. He contrasts an intelligence team's accumulated context and hypothesis with centralized control. The historical story is his analogy for the talk's architectural argument.

His point is that teams may have access to the same models and data but still differ in how they turn information into useful decisions. He proposes adding an intelligence dimension across the stack, alongside orchestration and governance.

Alake defines that dimension through four questions: what should the agent know, what should it remember, what is it allowed to see, and how does it improve? He associates these with knowledge, memory, governance and data access, and continual learning.

He sketches an evolution from prompt management to context management, control planes and the proposed intelligence plane. His recurring distinction is that information alone is not intelligence: systems must also organize, govern and use what they acquire.

Across the stack, he connects user identity to data access, orchestration to context assembly and memory, and the data layer to ontologies and semantic definitions. Infrastructure then supports inference, fine-tuning and learning beyond the initial deployment.

Alake points to earlier networking proposals for a knowledge plane above management and configuration systems. His agent architecture borrows that framing. He uses a conceptual equation in which an agent combines a model and harness, control adds governance and security, and intelligence adds knowledge, memory and learning.

His reference architecture includes an agent runtime, a memory manager, a data platform and traces that can feed a continual-learning loop. These components can be supplied by different providers. The diagram separates data, control and intelligence planes as a way to organize responsibilities.

He says newer decision models prompted him to reconsider which steps in an architecture could be handled by specialized models, including stages of retrieval. He then presents a recorded demonstration because the conference internet connection is unreliable.

The demo compares a governed analyst agent with a naive analyst. Alake says the governed system achieved 99% correctness and used around 32,000 tokens versus 200,000. The screen instead shows 97% across 29 questions and 32,999 versus 234,267 tokens. These are conflicting figures from one demonstration, not a general guarantee or independent benchmark.

In one example, an ontology helps the governed agent reason about a counterparty. In another, a semantic definition helps distinguish the meaning of concentration. Alake argues that even small differences in error rates may matter in financial or other mission-critical work.

For teams beginning this work, he recommends treating memory as data, writing down entities and definitions, placing entitlements in the data layer and capturing traces. He argues that owning memory gives a team control over how its system improves.

Alake maps his architecture to Oracle's products, describing the presentation as a set of components for building an intelligence plane. He highlights agent memory, data security, private inference, ontologies and semantics. These are vendor-specific examples within his broader framework.

He describes an Oracle Python package for agent memory that creates context cards and abstracts some memory-engineering work. He also recommends retaining memory traces as potential fine-tuning data, connecting memory engineering with context engineering.

For security, he describes propagating a user's identity and data entitlements into the data layer. In the example, an agent acting for an analyst inherits the analyst's permitted access, including row-level restrictions, rather than receiving unrestricted access.

He describes private inference infrastructure for running embeddings, language models and rerankers on premises, as well as cloud-hosted alternatives. His point is that teams can choose deployment components according to their data and infrastructure requirements.

A second demonstration uses his open-source Memories tool. He identifies three model roles in an agent-memory system: a decision model, an embedding model and a reranker. Captured memory gives a team data it can use to fine-tune models for its own workflow.

The example focuses on memory routing: deciding whether information produced in a conversation belongs in conversation memory or workflow memory. Instead of expressing every routing decision as application code, he demonstrates a fine-tuned decision model trained on classified examples.

Alake suggests memory routing, embeddings and reranking as accessible starting points. The proposed loop is to capture and format traces, train or fine-tune suitable models, then measure whether quality or latency improves for the actual use case.

He briefly describes Oracle's private agent factory and the memory components beneath it, then returns to the importance of ontology and semantic definitions for critical work. He closes by encouraging teams to own their memory, capture traces deliberately and build a path for continual learning.