No Memory, No Harness: Why the Database Is the Last Line of Defense — Kay Malcolm, Oracle

Kay Malcolm runs an outbound database product management team at Oracle, split across platform development, LiveLabs content, QA, and front-end work. AI made each person faster, but the team did not become correspondingly more productive. The bottleneck had moved: code generation accelerated while coordination still ran at human speed.

The concrete failure appeared during an overnight handoff. Developers in the Netherlands committed code around 4:00 a.m. Malcolm’s time. When the United States team woke up, it received the changed files but not the context from the AI-assisted session that produced them. The artifact survived; the reasoning did not.

That missing context had observable consequences: repositories diverged, managers could not explain why overall work was not moving faster, and testing and validation continued to consume time despite increased spending on models and tokens. Git could show which lines changed, but, in Malcolm’s phrase, “Git records the code and not human intent.”

The team therefore needed a collaboration layer that could preserve progress, next steps, and the rationale behind agent decisions while helping people resolve questions and conflicts. AI had effectively become another team member, but one whose working context disappeared at the end of a session.

To identify the missing layer, Malcolm expands the definition of an enterprise agent beyond a model and workflow. Tools let the system act. Context is the information currently placed in the prompt or context window. Memory preserves information for later use. Retrieval chooses which retained information should return, rather than dumping everything into the next prompt. Security and guardrails constrain what the resulting system may do.

Her anatomical analogy separates these responsibilities cleanly. The model is a “little brain floating in a glass jar.” The harness is the body that gives it tools and lets it act. Memory is the central nervous system carrying context between reasoning and action. A model can generate code without this connective tissue, but it cannot preserve continuity for the next person or session.

The five memory categories answer different questions:

• Short-term memory — what is active now? It holds information within the current session.
• Long-term memory — what should survive? It persists across sessions.
• Episodic memory — what happened last time? It records a prior interaction or event.
• Procedural memory — how was the work done? It retains tools and steps.
• Semantic memory. Malcolm names this fifth category but does not develop its definition in the talk.

The first two categories emphasize duration, while episodic and procedural memory distinguish kinds of retained content. The taxonomy does not specify schemas, retention rules, or retrieval methods.

This taxonomy reframes the original Git problem. The next team did not merely need yesterday’s chat transcript. It needed durable decisions, an account of what happened, and the steps associated with the resulting code. That immediately raises the next architectural question: where should these different forms of memory live?

Malcolm answers the storage question through her earlier work as a performance tuner at Southern Company. The original environment centered on rows, columns, and SQL. When a developer needed unstructured storage and did not get a timely answer, the developer installed a specialized database instead.

Every database system created two recurring obligations for its DBA: a weekly security meeting and a weekly patching meeting. One relational system meant two meetings. Adding the unstructured store raised the count to four. A specialized database solved a data-model problem, but it also introduced another system to secure, patch, understand, and operate.

A safety-critical power-restoration application then needed relationship analysis. False positives or negatives could misdirect workers repairing damaged infrastructure, so the team wanted to compare nearby poles. Malcolm implemented the relationship traversal as a five-level nested UNION ALL query. She remembers it fondly—“some of my best work”—but says it could take about 20 minutes. The team then installed Neo4j, raising her recurring meeting count to six.

This is the tradeoff behind polyglot persistence. A specialized store may be introduced for a particular data requirement or workload, but every new system adds operational work. Once agents need relational records, JSON documents, graph relationships, and vectors together, the cost also moves into the agent: it must decide which store is authoritative and reconcile conflicting or duplicated information.

Malcolm says that reconciliation can waste tokens and often produce the wrong answer. The talk provides no error rate or controlled comparison, so the supported architectural concern is narrower: distributing related memory across independently governed stores creates an additional authority and coordination problem for the agent.

Four audience volunteers make that coordination problem physical. One represents a relational database, another an unstructured store, another a graph database, and the last a vector database. Malcolm gives them one sentence—“The cow jumped over the moon”—and asks them to decide how to store it and who owns the single source of truth. They must stay apart and whisper; louder communication incurs a fictional fivefold token cost.

The exercise is an analogy, not an interoperability test. Its question is: where does reconciliation happen when several specialized systems hold different representations of the same memory? If the stores remain separate, the burden moves to an agent or another coordination layer. The volunteers cannot establish authority under the imposed communication limits, which makes the hidden coordination work visible.

Malcolm’s proposed alternative is to keep multiple representations in one database. She describes Oracle AI Database as supporting JSON, graph, vector, spatial, and blockchain-related capabilities together, including storage in the same table and partition, with deployment across several clouds and on-premises environments. These are product capabilities presented in the talk rather than demonstrated configurations or performance results.

Different representations still serve different jobs. Malcolm maps relational and JSON structures to retained session and long-term context, graph structures to procedural relationships and steps, and vectors alongside text to episodic and semantic memory. The precise mapping is presented at a high level rather than as a strict schema. Consolidation does not make the representations identical; it places them under one persistence system so the harness does less cross-database reconciliation.

The talk now returns to the overnight handoff. The team’s memory broker, Poly, preserves more than the committed code. It captures context from the working session—including procedural, episodic, and long-term information—and makes it available to other team members across forks.

The important mechanism is association, not merely storage. Poly determines which fork, branch, and commit the context belongs to. That metadata turns a free-floating conversation into context attached to a concrete point in code history. The United States developer can therefore continue from the relevant reasoning instead of reconstructing it from the diff alone, while developers remain in control of the work.

What must survive the handoff? The diagram follows the observable change: before Poly, the receiving developer gets only code; with Poly, the code arrives with session context anchored to its Git coordinates. The database supplies persistence, while the broker performs capture and association.

Malcolm describes the implementation as using Oracle’s agent memory SDK with storage in an Oracle Autonomous Database. The SDK holds live conversations, memories, and facts and decides what is worth retaining. The surrounding design remains model-independent: the team can use an LLM of its choice or a local model through an Oracle private AI services container.

The architecture is concrete, but its reported outcome remains qualitative. The recording does not specify Poly’s retention criteria, access-control model, conflict-resolution protocol, retrieval accuracy, or measured team-speed improvement. It establishes how shared context is attached and transferred, not how much productivity the system adds under controlled conditions.

Malcolm extends the team example into a broader claim: memory becomes non-negotiable when an agent must operate across people and sessions. She points to an account of an in-house data agent that used memory to filter correctly rather than relying only on string matching, and to Harrison Chase’s framing that ownership of the harness determines ownership of memory.

A local memory file can work for one agent or one user, but shared enterprise work introduces identity, concurrency, authority, and access questions. The talk does not prove that file-backed memory cannot scale; its practical point is that a team memory system must coordinate multiple participants rather than preserve context for only one session.

The closing distinction is between individual and organizational speed. AI can shorten one person’s implementation loop. Shared memory aims to keep that work useful after the session ends, across a time-zone handoff, a new branch, or another collaborator. That is why the database is presented as the “last line of defense”: it is the persistent layer that remains after context windows close and models change.

For experimentation, Malcolm points attendees toward the Oracle AI Developer Hub for coding materials and applications and toward LiveLabs for temporary hands-on workshops. She also describes an OCI Always Free offering with a free Oracle Database, free compute, 3,000 emails per month, and 200 gigabytes of storage. Those quantities describe the offering presented in the recording, not verified current terms or eligibility. She closes by inviting attendees to build something and tell her what they made.