SYSTEM
Second Brain
What it looks like to run the thing we advise other people to build. Plain files, written rules, and a system that checks its own claims against the live one.
100%
Plain markdown
6
Collectors
3
Databases watched
Daily
Health report
Every document this firm produces is a plain markdown file in one folder tree. No proprietary format, no database holding the text hostage, nothing that needs a vendor to still exist in ten years. That is not nostalgia. It is the precondition for everything else: an agent can read, write and reason over plain files without an integration, and a human can read them in any editor when the agent is wrong.
Three parts
01
The record
One tree of markdown, one set of written rules about where work lands and how it is filed, and a decision log where anything settled gets a number so it stops being relitigated. Every file carries the conversation that produced it, which means a claim can be traced back to where it came from months later.
02
The agent layer
Mail, calendars and files across five accounts reach the assistant through one MCP server written for the purpose, running locally on the machine rather than as a hosted connector. Scopes are per account and per capability: reading is easy, sending is deliberately two steps, and nothing sends on its own. The governance here is the point. The interesting question was never what an agent can reach, it is what it is allowed to do once it gets there, and who decides.
03
The monitoring
Collectors check credentials, DNS, mail authentication and website traffic across three databases on a schedule, and a brief lands every morning saying what changed. It remembers what it told you yesterday, so an open item gets one line rather than the same paragraph for the fifth day running, and it says when something cleared.
The machine is part of the record
A development environment is usually the one thing nobody writes down, which is why rebuilding one takes a week and the knowledge leaves when the person does. This one is documented to the same standard as everything else: installs, runtimes, shell and path, identity and auth, the agent harness, every project checkout, the editor and the fonts, what syncs and what exists in exactly one copy, and a rebuild sequence that starts from a bare machine.
Credentials are in it by name and location only. The section recording them was produced without reading a single value, and says so at the top. Knowing that a key exists, what it is called and which file holds it is what you need to reason about blast radius; the value itself is what you need to leak one.
It refreshes itself. A scheduled job collects the machine's state each week, reads the diff for anything credential-shaped the patterns might have missed, commits and pushes. A check then fails if that backup is more than nine days old or has anything unpushed, and it runs at the end of every working session, so a job that quietly stops firing gets reported rather than discovered later.
Drawings that cannot drift
The architecture diagrams live in Excalidraw and are referenced from the record rather than pasted into it, so there is one copy of each and no exported image going stale in a folder somewhere.
One of them is not drawn at all. The capability landscape is built: the band geometry, the taxonomy, the placement rules and the edge conventions live in a generator, and the scene is replaced by running it. Hand-editing that one is pointless, because the next build discards it. A diagram produced from the same source as the argument it illustrates cannot quietly disagree with it.
There are structural checks on the output: boxes that overlap, arrows crossing shapes they have no business touching, labels sitting on top of each other, text whose two stored copies disagree. Those are not sufficient and the record says so. Several defects passed every check and were caught only by rendering the thing and looking at it, including a band drawn right to left so the reading order reversed, and a six-row legend that came out as six copies of one label.
The part that matters
The record is verified rather than trusted. A script re-derives every checkable claim the architecture document makes, against the live systems, and fails when reality and the written record disagree. Documentation that is never checked is a story about the past; this is the difference between a diagram and a system.
The standing rule behind it: any statement about a live system carries the command that established it. If no check was run, the answer says so and names what would settle it. That rule applies to the assistant and to the person, and it is the single highest-leverage thing in the whole arrangement.
Why it is on this site
Because the advice and the practice should be the same thing. Most of what we tell a client about governance, agent boundaries and verifying your own claims was learned by running this, breaking it, and fixing it in public. It is not a product and it is not for sale.
Analytics
We count visits with Google Analytics, which sets a cookie on your device. You can turn it off here or from the Cookies link in the footer, any time.