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

Half of Kay Malcolm's team sits in Europe and half in the United States, so when the Netherlands side commits code at four in the morning her time, the Americans wake up to the code and none of the reasoning behind it. Git records what changed, not why anyone decided it. AI had made every individual on the team faster without making the team any more productive, and she went looking for the missing layer. Malcolm runs outbound database product management at Oracle, where she has spent twenty years, and her framing is anatomical. If the model is a brain floating in a jar, the harness is the body that lets it act, and memory is the central nervous system carrying context between the two. She walks through five kinds worth distinguishing: short term within a session, long term across sessions, episodic for what happened last time, procedural for the steps taken, and semantic for meaning. Then comes the storage question, and she answers it with a story about a previous job where every specialized database she took on added two standing meetings a week, one for security and one for patching. Relational made two. Document made four. Graph made six. She quit. The live version of that argument puts four audience volunteers on stage as a relational, document, graph, and vector store, gives them one sentence to remember, and forbids them from talking above a whisper. They cannot agree on who holds the truth, which is the point: an agent asked to reconcile four stores will often guess wrong and spend tokens doing it. Speaker info: - https://www.linkedin.com/in/kaymalcolm - https://blogs.oracle.com/authors/kay-malcolm Timestamps: 0:00 - The team, and why AI was not helping 3:36 - Git records code, not human intent 5:24 - What an enterprise agent actually is 7:14 - The harness as body, memory as nervous system 8:09 - Five kinds of memory 10:54 - Counting meetings, one database at a time 13:29 - Where should memory actually live? 14:24 - Four volunteers, four databases, one sentence 15:16 - Storing every type in one place 17:01 - A memory broker for a distributed team 18:46 - Shared memory as a team multiplier