I let AI agents run my life. They can read everything and send nothing.
I'm Johannes. I build systems that run on their own without going off the rails: a security product during the day, and this at night. If there's a thread through everything I make, it's that autonomy should be earned structurally, not hoped for.
Right now, while I'm writing this, software I built is reading my email. It knows my calendar. It has my contacts. Every morning it hands me a brief of what matters, and overnight it files what came in, drafts the replies I owe, and keeps my tasks in sync across my devices. I did not check any of it this morning. I did not have to.
If that sentence makes you slightly uncomfortable, good. It should, and the discomfort is the whole point of the design.
Everyone who builds a "second brain" builds one to remember: a place to capture notes and organize them so a human can read them back later. Storage. Mine does almost none of that. I built one to act. It is ten small autonomous agents, running on a schedule on my own laptop, that do the boring, consequential, easy-to-drop work of a day: triage the inbox, file what's filable, draft what needs a human, brief me, and once a week think about my own notes and tell me what I'm circling.
The idea of an external memory is old, and it has a good lineage. Vannevar Bush imagined the Memex in 1945. Douglas Engelbart spent the 1960s on a research program he simply called augmenting human intellect. Niklas Luhmann kept a paper slip-box of ninety thousand notes that out-wrote entire departments, a method Sönke Ahrens later made usable for the rest of us. And more recently Tiago Forte gave the whole thing a name, the Second Brain, while tools like Roam and Obsidian handed a generation of us bidirectional links and a cult. I have read most of it, and I owe it. But notice what every one of those is about: remembering. Capturing, connecting, recalling, so a human can think better later. I wanted the other end of the problem. I did not need help remembering. I needed the remembering to do something without me.
Handing that much of your life to AI agents is either reckless or it isn't, and the difference is entirely in two design decisions. The first: it can read everything and send nothing. It will draft an email; it will never send one. Anything that would reach another person waits for me. The second: none of it touches a cloud. Not "we promise not to look" - it physically cannot leave the machine, and I'll show you exactly why in a moment.
This is the same bet I make when I let AI agents commit to my codebase overnight, just pointed at my life instead of my work: give them real autonomy, and engineer it so the autonomy is safe rather than trusted. And as with anything I actually run, I'll tell you which parts earn their keep and which parts I built, admired, and quietly switched off.
A normal morning
Here is what it actually looks like, because the abstraction is less convincing than the Tuesday.
I wake up and there is a brief waiting. Not a wall of everything, a brief: what's on today, what came in overnight and where it went, who I owe a reply, the two things I flagged that are now due. The inbox has already sorted itself while I slept, most of it filed to the right place, a couple of things deliberately held back because they needed a decision only I could make. My tasks are on my phone, in sync, because something reconciled them at 6am. A draft or two sits ready, written with the context already pulled in, waiting for me to read, fix a line, and send.
The difference from before is not that I do less work. It's that I start the day oriented instead of excavating. I used to open a full inbox and spend the first hour reconstructing where I was. Now the reconstruction happened without me, and I get to start at the part that needs a human.
Read everything, send nothing
That morning only works because the agents can see the whole picture: the mail, the calendar, the notes, the running record of what's owed. Broad read access is the entire reason the thing is useful. It is also, obviously, the scary part, so here is the rule that makes the scary part safe.
Reading is reversible. If an agent mis-files a note or misreads a thread, the worst case is I move something back, and I've lost thirty seconds. Sending is not reversible. An AI that emails the wrong person the wrong thing at 3am cannot be un-emailed, and no amount of "it's usually right" makes that risk acceptable when the downside is a relationship or a deal. So I made the one irreversible action the one thing the system cannot do on its own.
Every outward action is drafted and queued. The email is written and sits until I press send. The follow-up is composed, with the context, and waits for my yes. The human is the only path from the system to another person, and as a second layer, a draft can only even be addressed to someone already in my world, never a new recipient the system invented. This is exactly the shape of how I let agents work on my code: they can commit all day, but they cannot deploy. Automate the reversible, put a human on the irreversible, and you can hand over far more than feels comfortable without handing over the thing that can actually hurt you.
Private by construction, not by promise
Here is the part I care about most, and the part almost every other version of this skips.
Your email, your calendar, your contacts, the running record of who you owe what: that is the single most sensitive corpus you own. It is a map of your relationships, your money, your health, your leverage. The default move in 2026 is to pipe all of it into someone else's model, because that is where the convenient assistant lives, and to accept a sentence in a terms-of-service page as the entire privacy architecture. Most people make that data-flow decision without ever noticing they made it.
I build a company whose whole premise is that a claim is only as good as the evidence you can trace it to. I was not going to run my own life on a promise I can't verify.
So Brain is local. The agents run on my laptop, against files on my disk, and the assistant they talk to is reached in a way that keeps the corpus on the machine. That is a stance, not a feature, and stances are easy to say and easy to quietly break the first time cloud sync would be convenient. So I made it structural. The safety net that versions and backs up the whole vault every hour has one hard rule wired into it: if it ever finds that the vault has been pointed at a remote, any remote, it refuses to run and says so. The system that protects my data is built to stop working the instant that data could leave. Privacy here is not something I intend. It is something the code enforces against my own future laziness.
That is the difference I want you to take from this. "We don't train on your data" is a promise, and a promise is a thing you audit and hope about. "The data physically cannot leave this machine" is a property, and a property is a thing you can check. When the corpus is your entire personal life, I think that difference is the only one that matters, and I think most people have it exactly backwards: they will agonize over a password and then hand a decade of their correspondence to whichever assistant had the nicest onboarding.
It costs me things to run it this way, and I owe you honesty about those.
What running it locally actually costs
Local is not free and it is not automatically virtuous, and pretending otherwise is how you lose the reader who has actually tried it.
It lives on one machine. When I'm out with just my phone, the agents are not running for me in the moment; they run on a schedule, where the data is. I gave up the seamless assistant-on-every-device experience that a hosted service hands you for nothing. I gave up someone else keeping it running, which means when an integration breaks there is no support desk, there is me on a Sunday. And I pay for it in exactly the friction you'd expect: the edges that a polished cloud product would have smoothed over, I smooth over myself or route around.
I took that trade on purpose, and only because of what the corpus is. For my entire personal and professional correspondence, I will pay real friction for a privacy property I can verify. For a shopping list I would not bother, and I'd use whatever was easiest. That's the honest calculus: local is right when the data is sensitive enough to earn the friction, and the mistake is treating it as a religion instead of a trade.
What I built and don't use
Every post like this is a victory lap, and every system like this is half-abandoned. So let me tell you which parts of mine actually survive contact with a normal week, because the honest answer is not the flattering one.
The parts I use every day are embarrassingly boring. The morning brief. The inbox getting triaged and filed while I sleep. My tasks staying in sync so I stop dropping things. That's it. That's the core, and if I'd stopped there I'd have ninety percent of the value for a fraction of the code.
The parts I'm proudest of are the parts I barely touch. I built a "thinking" layer that runs structured passes over my own notes: challenge an assumption, connect two ideas, surface the patterns I'm circling. It is the most intellectually satisfying thing in the whole system and it is the thing I open least, because it turns out the bottleneck in my thinking was never a lack of prompts to think harder. I built a reconciliation engine that detects duplicate and drifting notes and proposes merges, production-grade, the kind of thing you'd want across a million records. My vault has a few hundred notes. I built it because I could, and because it mirrored a real problem in the product I sell, and it solves a problem I do not have. And I built a whole graphical cockpit to see all of this at a glance, and then I kept living in the terminal, because the terminal was already where I was.
Then there are the edges that just quietly don't work and that I route around instead of fixing. A calendar integration that needs re-consenting more often than it should. A capture path I set up, tested once, and never wired all the way through. None of it is broken enough to force a fix, which is exactly why it never gets one. The gap between "works in a demo" and "works on a Tuesday when I'm busy" is where personal software goes to die, and mine has its share of graves.
If there's a lesson in that, and I think there is, it's this: the usefulness of a feature turned out to be almost inversely proportional to how clever it felt to build. The dull scheduled job that files an email is load-bearing. The elegant engine that reasons about my notes is a trophy. I keep both, but I've stopped confusing which is which, and I no longer let the fun of building a thing stand in for evidence that I'll use it.
What to take from this
- Build systems that act, not archive. The value is in the doing, not the storing.
- Put the human on the only outbound path. Automate the reversible, gate the irreversible.
- Enforce privacy as a property, not a promise. If the data can leave, eventually it will.
- The boring scheduled job is load-bearing; the clever engine is a trophy. Do not confuse them.
- Local is a deliberate trade, not a default virtue. Make it where the data earns the friction.
- Most of the value is in the least impressive tenth. Build that first, and maybe only that.
I've been running this for a while now, and the honest state of it is: the boring core is indispensable and the clever parts are a museum. If you've built something like this and made the clever parts stick past the honeymoon, I would genuinely like to know what survived for you, because mostly they haven't for me.
And if the instinct underneath all of this is familiar to you - keep the sensitive corpus where you can verify what happens to it, make every claim traceable back to its source, never let the system take the one action you can't undo - that is not just how I run my own life. It is the whole idea behind what I build during the day. That's here.
On whose shoulders this stands
The second-brain idea has a fifty-year lineage, and this post is a departure from it, not a discovery. The sources, if you want them:
- Vannevar Bush, "As We May Think," The Atlantic, 1945 - the Memex. https://www.w3.org/History/1945/vbush
- Douglas Engelbart, "Augmenting Human Intellect: A Conceptual Framework," SRI, 1962. https://www.dougengelbart.org/pubs/augment-3906.html
- Sönke Ahrens, How to Take Smart Notes, 2017 - the modern systematization of Niklas Luhmann's Zettelkasten.
- Michael Nielsen, "Augmenting Long-term Memory," 2018. https://augmentingcognition.com/ltm.html
- Andy Matuschak & Michael Nielsen, "How can we develop transformative tools for thought?", 2019. https://numinous.productions/ttft/
- Tiago Forte, "Building a Second Brain: The Definitive Introductory Guide." https://fortelabs.com/blog/basboverview/