No Memory, No Harness: Why the Database Is the Last Line of Defense — Kay Malcolm, Oracle
Kay Malcolm discusses how AI, while boosting individual performance, often hinders overall team productivity due to fragmented context. She introduces the concept of an "agent harness" with "memory" as its central nervous system, vital for sharing context. Drawing on personal experiences with database sprawl, she highlights the inefficiencies of storing diverse memory types across multiple data stores. Malcolm then presents Oracle's AI database (26AI) as a unified solution, capable of natively managing all memory types in a single platform, thereby enhancing team collaboration and solving the context problem for enterprise AI agents.
Kay Malcolm, from Oracle’s outbound database product management, presents a critical challenge faced by distributed teams leveraging AI: while AI enhances individual productivity, it often fails to improve overall team output due to a lack of shared context. She illustrates this with her own team, where code commits from Europe at 4 AM US time arrive without the underlying human reasoning, as Git records “what changed,” not “why.” This led to AI making individuals faster but not the team more productive, creating a bottleneck in collaboration rather than code creation.
The Anatomy of an Enterprise Agent
Malcolm defines a true enterprise agent as more than just a model and workflow. It comprises:
- Tools: How it performs actions.
- Context: Information within the prompt’s context window.
- Memory: Essential for retrieving relevant information, not everything.
- Guardrails: Crucial for security and operational safety.
She uses a compelling analogy: the model is the “brain floating in a jar,” and this collection of components forms the “harness,” which acts as the agent’s “body” allowing it to interact. The “memory” component serves as the “central nervous system,” carrying context between the brain and the body, directly addressing the initial problem of missing context.
Five Kinds of Agent Memory
Malcolm distinguishes five crucial types of memory:
- Short-term memory: Pertains to the current session (e.g., within a chat or code generation interaction).
- Long-term memory: Persists across multiple sessions.
- Episodic memory: Recalls specific past interactions or events (“what happened last time”).
- Procedural memory: Stores the steps taken or tools utilized.
- Semantic memory: Captures the underlying meaning and knowledge, particularly vital for enterprise applications.
The Data Storage Conundrum
The discussion then shifts to the practical challenge of where to store these diverse memory types. Malcolm recounts a past experience at Southern Company where each specialized database (relational, document, graph) introduced significant overhead, adding two weekly administrative meetings (security and patching) per database type. This exponential increase in operational burden ultimately led her to leave and join Oracle, seeking a solution to this fragmentation.
She highlights that in modern AI applications, agents need to access data across various stores—relational, JSON, graph, and vector. The core problem is identifying a “single source of truth” amidst this fragmented landscape. An agent attempting to reconcile data from multiple, disparate stores often “gets it wrong and it’s going to burn up a whole bunch of tokens” in the process.
To vividly illustrate this, she conducts a live demonstration with four volunteers, each representing a different database type (relational, document, graph, vector), tasked with remembering a single sentence and determining who holds the truth. Their inability to agree without high communication cost underscores the inefficiency of siloed memory.
Oracle’s Unified Approach to Agent Memory
Malcolm asserts that “Oracle is not the Oracle that you think.” She introduces the Oracle AI database (referring to 26AI), which can natively store and manage diverse data types—JSON, graph, vector, spatial, and immutable blockchain—within the same table and partition. This unified approach supports “any data type… any workload, anywhere” (AWS, GCP, Azure, OCI, on-prem), offering unprecedented choice and flexibility.
This architecture enables storing all five types of agent memory—short-term, long-term, episodic, procedural, and semantic—within a single, integrated database. This eliminates the communication overhead and token wastage associated with querying multiple data stores, making the Oracle AI database an ideal platform for powering an agent’s harness.
Shared Memory as a Team Multiplier
Returning to her initial team problem, Malcolm explains how they solved it with a “memory broker named Py” utilizing the Oracle Agent Memory SDK. This SDK, stored in an Oracle Autonomous Database, facilitates the sharing of context—including procedural, episodic, and long-term memory—across team members (human agents). This system ensures developers maintain control while Py manages context, linking it to relevant code forks, branches, and commits.
She emphasizes that “memory is the thing that becomes non-negotiable in an agent’s harness.” She cites insights from:
- OpenAI: Stating their in-house data agent critically requires memory for correct filtering, beyond mere string matching.
- Harrison Chase: Declaring, “Your harness, your memory. And if you don’t own your harness, you don’t own your memory,” highlighting the importance of memory ownership.
- Claude’s memory: Described as a file system-like memory that works for single instances but fails to scale in enterprise environments.
Ultimately, Malcolm concludes that while “AI makes individuals faster, shared memory on an Oracle AI database makes teams faster.” She invites the audience to explore Oracle’s AI developer hub and LiveLabs for resources, emphasizing the always-free OCI tier for experimentation.