Everyone in my industry, including me, has built elaborate AI systems for themselves, highly customized to serve them in everything they do. We understand the importance of context engineering: giving each prompt and each agent exactly the information it needs to produce the best results. It's a large part of what separates the people getting extraordinary things out of AI from the people getting generic answers back. And it's genuinely hard to understand and apply if you're not already deep in it.
This post is about what happened when I tried to give that advantage to someone who isn't deep in it.
Caitlin built her context by hand. Mine is automatic.
I regularly sit down with my girlfriend Caitlin and help her with using AI to run her business. One session, I essentially guided her through thinking through her goals and explaining those goals to Claude — because that’s what was needed to actually get her the results she was looking for. And I thought: wait, this should be automatic. Claude should know how to do that. This should be baked into Caitlin's workflow.
The difference between how I use AI and how Caitlin uses it intuitively is this: She only ever looks at what's right in front of her, and expects the AI to know things about her, and know what direction she wants to take things in. She’s never heard of context engineering or why that would be important. What I taught her is that you really need to be very explicit about all of it in order to get good results — which can feel tedious.
In my own system, I've built a complex Claude Code setup that automatically understands my midterm goals, my long term goals, my strategies, who I am, what I want to achieve, what my values are, how I talk, everything about my business. All of it is baked in. Caitlin had to do a lot of "prompt engineering" to get there by hand.
I see the people in the industry — who know the tech — getting accelerated exponentially by all of this. And I see the people who don't understand the tech being left in the dust.
So I built her a system that does it for her.
I wanted Caitlin to get the same benefits without having to think about the technical side of it. So I built a prototype and kept working on it here and there.
What I wanted was a piece of technology that supports her in understanding what her goals are, so that whatever she does with Claude, and all the advice she gets back, is always aligned with those goals. And that comes with a nice side effect: To align everything to Caitlin’s goals, Claude first has to know them, which means she has to work them out. It forces her to think about her goals and articulate them clearly, which is something most people rarely ever do.
Let me rephrase this more clearly: To give advice aligned with Caitlin’s goals, Claude first has to ask what they are. In providing the answer to Claude, Caitlin sees those goals clearly for the first time.
This was huge for her.

Used wisely, AI becomes a mirror to help us understand ourselves better.
I wasn't working from nothing. This is all uncharted territory, and I try to keep my finger on the pulse, watching for the thing that actually moves the conversation forward and helps people in their real lives. There are patterns emerging that industry experts are seeing and using to their advantage. The people I'm influenced by are the ones who think this way and share their ideas openly, so that people like me can build on them. I want to do the same. My idea came together from three places.
1) Daniel Miessler - Building a system that knows you deeply
What pulled me in was a phrase of his: "we're all building a single digital assistant." The idea is that you build a system that knows you deeply. Who you are, what you want in life, where you've been, your preferences, the people in your life — he calls it Life OS. Essentially an agent harness that holds all of your life's context. He does it with Claude Code, people are digging it, and I use it myself every day.
The power is in what it actually lets you do: ask very little, get accurate and powerful results back.
Say you get a job offer and you're not sure whether to take it. You ask, "Should I take the job offer I got yesterday?" A well-built personal assistant goes and looks up everything it needs. It pulls the offer from your email, the other offers you've had to compare against, your goals, your savings, how the offer lines up with your values and your abilities. Standard Claude might ask you a couple of questions and hand you generic advice. PAI looks at your whole life first.
2) Andrej Karpathy - Data you can read and edit yourself
What makes Karpathy's wiki idea interesting to me is how it has the LLM organize data: as interlinked Markdown files, instead of databases and vectors. A source of truth that both the AI and the human can read and edit. Nothing is locked in a format only a machine can open. The person in charge needs zero technical knowledge to see their own data and change it.

A visualization of a Karpathy-style knowledge base (source)
So powerful.
Yet, the technical hurdle remains. Any real-world implementation I’ve seen so far is aimed at developers managing Markdown files in git repositories. Works for me, does not work for Caitlin.
3) Building Companions for coaches
Most of the coaches I build for are non-technical. At JourneyLoop, their single interface with the platform is a DM / chat window with their Companion. That is the whole surface they see. Everything else is engineering under the hood: the knowledge each Companion draws on, memory that persists across sessions, context window management, the tools it can reach for, its personality.
There's a fleet of these Companions running, each one isolated so it only ever sees its own coach's data. Memory is tiered, and the context gets compacted in the background as it grows, so a Companion can hold months of a coaching relationship without drowning in it.
None of that reaches the coach. It shouldn't. The point of my work is that the hard parts stay invisible and what's left is a conversation. Building that has taught me most of what I know about making digital assistants that non-technical people can actually live inside.
There's one more piece that matters to me though: In Claude, whenever it saves a memory, that memory is pretty much invisible. You have no intuitive visibility into what Claude actually knows about you, where it's stored, or how it's organized. So having one place where I can see all of it, the pages and the stream of memories and thoughts in my second brain, is a big deal. It creates a bit more trust, and a bit more observability.
The gap keeps widening. Brain is where I start closing it.
That prototype I built is now a side project. I call it Brain, and it's live at brain.arcane.engineer. Some screenshots of what my personal second brain looks like:

“Pages” store information that describe everything about me and my life - goals, preferences, projects - anything I want Claude to remember and access during our conversations.

“Thoughts” are more unstructured. At any point, I can say to Claude “capture this as a thought”. It will automatically save and tag whatever is on my mind - half-formed ideas, links, etc - without needing to think about format or structure.
How it works
Brain is an MCP server. Setup is deliberately simple:
Get your secret link
Add it to Claude as a custom connector
That is the entire technical bar. From there you send one prompt — "Initialize my brain" — and Claude goes to work. It looks at whatever data sources you've connected (Gmail, docs, Notion, etc), finds the context of your life inside them, and starts building out your second brain. While it does that, it guides you. It teaches you the ideas and concepts as it goes and gathers what it needs at the same time, asking about your goals and drawing them out of you while it files them.
This is the same move from before, now built into the very first thing you do. The setup is the education.
What it taught me about building MCP servers
Building Brain was also how I taught myself to build efficient and robust MCP servers, with well-designed tools and primitives. There was a lot I didn't know going in: how and when Claude actually loads tools and instructions, and the sheer importance of progressive disclosure, which has become one of my favorite topics lately. MCP as a standard has come a long way, but a badly designed server will quietly eat through your user’s token budget and slow every workflow down, and you won't even know it's happening. Getting that right, so the server stays lean and the tools surface only when they're needed, is most of the work nobody sees.
Where it all converges
In Brain, everything converges:
From Miessler, a system that knows you deeply enough to act on your behalf.
From Karpathy, a source of truth you can actually read and edit yourself, no technical knowledge required.
From building Companions, the discipline of keeping the hard parts invisible so that what's left for the user is just a conversation.
The whole point of combining them is that none of it shows. You get the depth of all three and the setup of none.

Yesterday, I just asked Claude “Help me write a blog post”. It automatically called my Second Brain and saw that one of my goals right now is to sell out my upcoming retreat. It then understood my target audience and suggested blog topics that could be relevant to them. So amazing! I would have never thought of that.
shared.image.missing_image
Why this is the work I want
That gap is real, and it's widening. The people who understand this technology are being accelerated exponentially. Everyone else is getting left behind. I've spent enough time at both ends of it, deep in the engineering and sitting next to someone who just wants the thing to work, to believe the last mile is the part that matters most. Brain is my bet on it. I'm starting with the people closest to me, and I'm building it to see how far I can take it.
If you're reading this and you love getting nerdy about harness engineering, MCP servers, or building AI that actually reaches non-technical people, reach out. That's the work I want to be doing, and the people I want to be doing it with.

