In short
- The first rule is that it drafts and never sends. You test that yourself on install day.
- Seven rules, in plain English, at the top of your own file. You can change any of them.
- A rule in a file is a strong instruction, not a padlock. Safety is three layers, and only the third is absolute.
- Your files are plain text on your machine, read through your own AI account. There's no server of mine.
- Secrets never go in. A second brain holds the map of where they live, never the things themselves.
Once people get past "is this too complicated for me?", some of them ask a sharper question: am I about to hand an AI the keys to my inbox?
It's the right question. Here's what the rules are, what a rule can and can't do, where your files live, and what you should never put in one.
Will an AI assistant send emails on its own?
No. The first rule I write into a second brain is that it drafts and never sends. It writes the reply, puts it in your drafts folder, and stops. A person presses send, every time, without exception.
It isn't a setting buried three menus deep. It's the first line of the file the assistant reads before it does anything, and it's the first thing we test on install day. You ask it to send something. You watch it hand you back a draft instead. Then you believe it, because you saw it.
What are the rules, exactly?
Seven, and they fit on one screen. They're written in plain English at the top of your own file, in your words, and you can change any of them.
- Never send anything on my behalf.
- Never change my settings.
- Never delete anything without asking.
- Read-only on anything newly connected.
- Ask when unsure.
- Never invent facts about my life.
- When something is uncertain, say so. The doubt travels with the fact.
Rule seven saves you most often. An assistant that hedges when it's unsure is useful. An assistant that states everything with equal confidence is a liability, because you can't tell what it knows from what it assembled.
Is a rule in a file actually enforcement?
No. A rule in a file is a strong instruction, not a permission system, and it shouldn't be sold as one. It shapes behavior reliably, and it still isn't a padlock.
Safety here is three layers, and only the third is absolute.
- The rule sits at the top of the file and is read before every conversation. This is the layer that does the day-to-day work.
- Read-only first. Anything newly connected goes in able to read and not to write. You widen that deliberately, one tool at a time, after you've watched it behave.
- You press the buttons. The write actions that matter are yours. This is the layer that doesn't depend on the assistant behaving well, which is why the whole design leans on it.
You can reason about a system whose limits are written down.
Where does your data live, and who can see it?
On your machine, in plain text files you can open without any special software and without me. The assistant reads them through your own AI account, on your own subscription. Nothing is uploaded to a server of mine, because there's no server of mine.
So your second brain is subject to the privacy terms of the AI provider you already chose, and nobody else's. If you're comfortable with your current assistant reading a document you paste into it, you're in the same position, with better organization.
Your files stay on your machine. I don't keep copies of your data, and everything built is yours. An NDA is available on request, and asking for one is normal.
What should never go into a second brain?
Secrets. Specifically: seed phrases, safe combinations, backup codes and passwords. A second brain holds the map of where those things live. It never holds the things themselves.
It sounds obvious, and people still get it wrong, usually by trying to be helpful. Someone adds a password to a client note because it's convenient once, and now the most sensitive string in the business is sitting in a folder that syncs to a cloud drive and gets read by an assistant several times a week.
Keeping this rule is easier than cleaning up after breaking it. Password managers exist and they're good. Your second brain should know that one exists, and know nothing that's in it.
What happens if the person who built it disappears?
It keeps working, because there's nothing to disappear. The files are plain text on your machine. The assistant is your own subscription. Removing anyone else's access is a short written procedure you run yourself, and you test it on install day rather than taking my word for it.
Every build ships with a handover kit for exactly this: a recovery guide, a list of what anyone else can reach, a map of where everything lives, and the setup written down. It lives outside the system as well as in it, printed and in your email, because a recovery guide stored only inside the thing you're recovering doesn't help you recover it.
How do you know it works before you commit?
You use it yourself, from your own phone, away from your desk, before the work is signed off. A system that works while the person who built it is driving hasn't been tested yet.
There's a check-in ten days later too, and it exists because something went wrong. One of my installs worked on the day, and three weeks later it had stopped being used. Nothing broke, so nobody said anything. The ten-day call catches that while it's still cheap to fix.
A rules file shapes what an assistant does. It doesn't stop it. If that costs me the sale, it costs me the sale. The people who ask this question first usually get the most out of a second brain, because they think about what they're connecting.
If that's you, the second brain build page covers what gets built and how, and the four layers post covers the architecture. Then book twenty minutes and ask me the hardest version of this question. I'll answer it on the call, and if it's a good one, it becomes the next post.
Take this with you
Downloads from this post
No downloads on this post.
