AI made individual developers faster, but the team stayed slow because Git captured code without the reasoning and context behind it.
2
An enterprise agent includes tools, context, memory retrieval, and guardrails around the model, with memory carrying context between the agent and the work it performs.
3
Kay Malcolm argues that keeping agent memory in one database avoids conflicting sources of truth across relational, document, graph, and vector stores.
Summary
Kay Malcolm describes a problem from leading a distributed Oracle team. AI helped people write code faster, but developers in Europe could commit code while the US team slept, leaving behind little of the reasoning that produced it. Git stored the change, not the intent, so the team still spent time on testing, validation, and resolving disagreements. Malcolm defines an enterprise agent as a model with tools, context, memory retrieval, and guardrails. She separates memory into short-term, long-term, episodic, procedural, and semantic forms. She then argues that splitting these memories across specialized databases creates extra operational work and makes it harder for an agent to know which data is authoritative. Her proposed answer is Oracle's AI Database, with a memory broker and Oracle Agent Memory SDK to share context across team members and agent processes. The talk is also a product argument for keeping varied data types together.
AI sped up individuals while the team remained slow
Malcolm says AI made people on her team faster during the 2025 token-maxing period, but it did not make the team more productive. Her Netherlands team could commit code at 4:00 a.m. while the US team was asleep. The next morning, colleagues received the code but not the context from Codex that explained it. Repositories diverged, and managers still had to account for testing and validation work. Malcolm says Git records code, not human intent, so the missing layer was a way to share decisions and context.
An enterprise agent includes more than a model and workflow
Malcolm defines a real enterprise agent as a model surrounded by tools, context, memory, memory retrieval, and guardrails. Tools let it do things. Context is what sits in the prompt. Memory lets it retain information, while retrieval selects the relevant parts instead of returning everything. Guardrails matter because the agent can affect systems and data. Her analogy treats the model as a brain in a jar and the harness as the body that lets it act.
The harness carries context between the model and its work
Malcolm compares memory to the central nervous system. The harness connects the model to the actions it can take, while memory carries context through that system. This directly addresses her team's Git problem: the missing information was not more generated code, but shared memory about why changes were made, what decisions were taken, and what should happen next.
Five memory types describe different kinds of agent context
Malcolm distinguishes short-term memory within a session from long-term memory that persists across sessions. Episodic memory records what happened during a previous interaction. Procedural memory records tools and steps taken. Semantic memory stores meaning and facts. She presents these categories as a way to decide what an agent should retain and where each part might be stored.
Every specialized database added operational meetings
Malcolm tells a story from Southern Company, where each database system required a security meeting and a patching meeting every week. A relational system meant two meetings. Adding a specialized document database raised that to four. Adding Neo4j for relationship data raised it to six. She eventually quit because the operational burden had become a problem. The story frames database choice as an ongoing responsibility, not only a storage decision.
Multiple stores make the source of truth harder for an agent to find
Malcolm asks where an agent should look when related data sits in an Oracle database, a JSON database, a graph database, and a vector database. The agent has to work out which store is authoritative. She says it may get the answer right sometimes, but will usually get it wrong and spend tokens trying to reconcile the stores. She also warns that file-system memory or memory inside Claude or ChatGPT becomes difficult once more than one person or agent needs to use it.
One database can hold different memory forms together
In Malcolm's demonstration, four volunteers represent relational, unstructured, graph, and vector databases. She gives them one sentence and asks them to decide how to store it and which store owns the truth, while whispering to avoid using more tokens. The volunteers cannot coordinate. Malcolm uses this to argue that an agent should not have to reconcile disconnected stores. She says Oracle AI Database can store relational, JSON, graph, vector, spatial, and blockchain data in the same database.
A memory broker lets a distributed team share context
Malcolm says her team addressed the collaboration problem with a memory broker named Py. It tracks context, identifies the relevant fork, branch, and commit, and shares information across team members. Developers remain in control while the broker carries procedural, episodic, and long-term context between workstreams. She presents shared memory as the layer that can turn faster individuals into a faster team.
The database choice remains part of the agent design
Malcolm cites an OpenAI paper about an internal data agent that needed memory to filter correctly instead of relying on string matching. She also quotes Harrison Chase on owning the harness and memory. Oracle's Agent Memory SDK stores conversations, memories, and facts, and decides what is worth keeping. Malcolm says it can run with a chosen language model or a local model through Oracle Private AI Services, with storage in an Oracle Autonomous Database.
