Ever feel like your team is moving faster than ever, yet you're still spending hours in meetings just trying to figure out why a piece of code was changed? That's the hidden tax of the AI era.
The Simple Version
Most people think of an AI agent as a smart chatbot. But Kay Malcolm, a database veteran at Oracle, views it through an anatomical lens. She argues that a Large Language Model (LLM) is essentially a brain floating in a jar.
A brain is useless if it can't interact with the world or remember what it did five minutes ago. To make it an 'agent,' you need a body to act and a nervous system to carry context. In tech terms, the 'body' is the harness (the code that lets the AI trigger actions), and the 'nervous system' is the memory (the database).
How It Actually Works
To build a truly functional enterprise agent, you can't just throw a vector database at the problem. You need a sophisticated memory architecture that mimics human cognition.
The Five Flavors of Memory
Malcolm breaks down AI memory into five distinct categories. Each serves a different purpose in the agent's workflow:
- Short-term: Context held within a single active session.
- Long-term: Information that persists across different sessions.
- Episodic: A record of 'what happened last time'—the sequence of events.
- Procedural: The specific steps or 'recipes' taken to achieve a goal.
- Semantic: The underlying meaning and conceptual relationships of the data.
The Danger of 'Polyglot Persistence'
Many developers try to solve these memory needs by using a different database for every type of data. They use a relational DB for users, a document store for logs, a graph DB for relationships, and a vector DB for embeddings.
Malcolm warns that this leads to 'operational sprawl.' Every new specialized database adds a massive tax on the team in the form of security audits, patching schedules, and maintenance meetings.
Technical Deep Dive
For the developers and architects, the real problem isn't just the number of meetings—it's the reconciliation cost. When an AI agent is tasked with finding a 'truth' that is spread across four different storage engines, it has to act as the integrator.
In a distributed storage environment, the agent must query the relational store, the vector store, and the graph store, then attempt to merge those results into a coherent answer. Because these stores don't 'talk' to each other, the agent often guesses how to reconcile the data.
This leads to two major technical failures: token waste and hallucinations. The agent spends a huge portion of its context window just trying to figure out which database is correct, and when it can't find a clear answer, it simply makes one up to satisfy the prompt.
The Memory Broker Pattern
The solution is to move toward a unified store that can handle multiple data models. By storing relational, document, graph, and vector data in one place, the database itself handles the reconciliation.
This transforms the database from a simple storage bin into a memory broker. Instead of the AI agent trying to piece together a puzzle from four different boxes, the database delivers the completed puzzle directly to the model.
Why This Matters
This isn't just about database efficiency; it's about the difference between individual productivity and team velocity. Malcolm notes that AI has made individuals faster, but it hasn't made teams more productive because the 'reasoning' behind decisions is still lost.
Current tools like Git are excellent at recording what changed in the code, but they are terrible at recording why it changed. When a developer in the Netherlands commits code at 4:00 AM, the American team wakes up to the result but none of the intent.
By implementing a shared, unified memory layer, the 'intent' becomes part of the system's episodic and semantic memory. This turns the AI from a personal assistant into a team multiplier, ensuring that the reasoning behind the work is as accessible as the code itself.