You built a second brain over a long weekend. An Obsidian vault, a few hundred notes, an AI agent on top that finally knows what you know. Then your team asks for access.
Would you hand it over?
That question sits underneath a lot of the conversations we had on our booth at AgentCon in Amsterdam last month. Developers from government, education and even space agencies told us they could build something clever on their own. Getting it trusted inside their organisation was the hard part.
Why can’t you just share your second brain?
Because its security model is you. You wrote everything in it, anything the agent reads you were allowed to read anyway, and when it gets something wrong you fix the note and move on. Share it and all three of those assumptions break at once. A bigger context window doesn’t fix that. What has to change is who decides.
Think about how a hospital handles information. Your own notebook is a second brain: only you read it. The ward whiteboard is a team brain. Everyone on shift can write on it, which is useful right up until someone asks who wrote “allergic to penicillin”. The patient record is an enterprise brain, and what makes it one is governance, not size. Every entry is signed, what you can see depends on your role, and every change can be audited. When something goes wrong, the first question is what the chart said when the doctor made the call.
The comparison breaks in one place, and it matters. People write patient records deliberately. Most agent memory is written by an extractor running on a prompt, so a memory can be wrong before anyone has read it. Shared memory needs controls on what gets written, not just on who reads.
What does a team brain change?
Two builds from people we work with show the first two steps. Both were made in partnership with Oracle.
Linda Haviv’s self-improving second brain keeps her notes in markdown but moves the working layer into Oracle AI Database, because as her context grew, privacy in a folder of files was “just a convention”.
Cole Medin’s team brain takes the next step. Everyone keeps their own agent and personal memory, and the shared knowledge sits centrally behind a Model Context Protocol server, with row-level security in the database and deny by default. His reasoning is the line we would pin above every team-brain project: “You can’t have this second brain, the personal part of the system, responsible for security in any way.”
That’s the shift. In a second brain you trust the agent because it’s yours. In a team brain you assume you can’t, so the enforcement drops into the database. What Cole’s version leaves open is what the enterprise step has to close: the shared layer is read-only, access runs on static tokens, and nothing records what an agent saw.
What does an enterprise brain have to answer?
Three questions. Whose memory is this? Who else can read or write it? And what did the agent know when it acted?
The first is the easy one. Oracle AI Agent Memory scopes every record by user, agent and thread. On its own that isn’t enough, and our documentation says so plainly: a user ID passed in by the application “is a scoping value, not proof of identity”. The second is where release 26.8, published on 22 September, comes in. It connects Agent Memory to Oracle Deep Data Security, so the database itself decides which signed-in user can reach each memory. The user’s identity token travels to the database, which checks it and applies the policy on every read and every write. In our worked example, Alice can store a memory for Alice, and the database rejects her attempt to store one for Bob. The application never makes that call, so it can’t get it wrong.
The third question is the one a bank’s risk team asks six months later. Answering it takes two records. Log what the model was shown whenever an answer matters: the user, the time and the memories behind it. Then switch on Flashback Time Travel for the tables the agent reads, such as prices and policies, so you can see them exactly as they stood at that moment.
We should be straight about how new this is. The new Agent Memory version only shipped in late September, and our worked example is a learning environment rather than a production template. Deep Data Security itself runs on the free Oracle AI Database container from version 26ai, as well as on Autonomous AI Database, so you can try the pattern locally before you go near a cloud account. History also pulls against the right to erasure, so deciding how a deletion reaches it is a design choice to make before you switch it on. And there is no agreed standard yet for auditing what an agent knew: when US bank supervisors replaced their model risk guidance in April, they left agentic AI explicitly out of scope. What we are sure of is where the rules have to live: in the layer every agent has to go through.
Come and talk to us in New York
We’ll be at the Oracle booth at AI Engineer New York. Linda Haviv and Raj Saha will be with us, talking through how to take a second brain to production.
If you have built a second brain and are wondering what it would take to share it, come and tell us what’s in it. If you think the database is the wrong place for these rules, tell us that too. We’re early enough in this to still be changing our minds.
Learn more: pip install oracleagentmemory and the agent memory notebooks in the Oracle AI Developer Hub