I'm a product designer. Not a developer. When Claude Code shipped, I spent a few weeks treating it like a smarter autocomplete. Pasting in snippets, asking questions, closing the window. That's not what it's for. Took me embarrassingly long to figure that out.
What it's actually for is a persistent layer between you and your computer. The thing that knows where everything is, remembers what you decided last week, handles the boring parts. So you can spend your attention on the rest.
I've been building that for two months. I call it Carson OS.
The problem
You know that moment when you open a new chat and the AI answers like a stranger who met you five seconds ago? No memory of your project. No sense of your tone. No idea what you decided last Thursday.
That's not a model problem. That's a context problem.
The model is smart enough. What it's missing is everything that makes you you. Your opinions, your voice, your current priorities, the decisions you've already made and don't want to relitigate. Every session starts from zero because you never gave it a place to live.
I had 169 pages of notes in Obsidian at this point. Product thinking, design principles, project logs, a playbook for how I write. None of it was visible to Claude. I was keeping the most useful reference document I'd ever built completely hidden from the tool I was using most. Which, in hindsight, is sort of stupid.
So that was the fix. Make the wiki the brain. Load it into every session. Stop starting from zero.
What Carson OS actually is
Three layers.
The wiki is the memory. An Obsidian vault with playbooks (how I design, how I write, how I push back on product decisions), topic pages, project logs, a map of every page. When a new Claude session starts, it automatically loads a hot-topics file, a playbook index, and my privacy rules. About 1,900 tokens. Roughly 1% of available context, and I never start from zero.
Carson is the conductor. He's the Claude Code instance running on my Mac, named after Mr. Carson from Downton Abbey. He reads the wiki, knows the playbooks, responds in a consistent voice. He doesn't do the work himself. He dispatches.
The staff is a roster of 13 specialist subagents. Each one runs in isolation, does its job, reports back. Lord Grantham handles code. Lady Mary handles writing. Lady Sybil reviews Figma designs. The Marchioness of Hexham reviews pull requests. Each one has a focused system prompt, a model matched to the task weight, no access to each other's context.
The mental model: Carson is the household manager. He fields requests, routes them to the right person, presents their findings. The specialists are better at their domains than he is. He knows that, and delegates accordingly.
The household-naming model
I want to be honest about this. I named them after Downton Abbey characters because it's fun, and because the names are easier to remember than "code-agent-3."
That's it. That's the whole reason.
"Lord Grantham handles code" is a complete sentence. It sticks. "Subagent-implementation-specialist" is something I'd have to look up every time. The side effect, which I didn't plan for but enjoy, is that the roster feels like a team rather than a config file. When I type "I'll have Lord Sinderby poke holes in this before we publish," I'm genuinely less likely to skip the step than if I wrote "running counterargument pass."
If the conceit isn't your thing, ignore it. Call them whatever you want. The mechanism is the same.
How it's structured (the concrete version)
The whole thing lives in two places.
~/.claude/ is the live executable layer. CLAUDE.md is the global instruction file that loads on every session. agents/ holds the specialist system prompts. skills/ holds reusable procedures.
~/Documents/Obsidian/Osaka/wiki/ is the wiki. Obsidian is the interface, but it's just a folder of markdown files. Claude can read all of it.
The connection between them is three @import lines in CLAUDE.md:
@import ~/Documents/Obsidian/Osaka/wiki/_hot.md
@import ~/Documents/Obsidian/Osaka/wiki/playbook/_index.md
@import ~/Documents/Obsidian/Osaka/wiki/people/personal/joey.md#Privacy rules for LLMs
That's it. Three lines. Every session has context.
The specialists are markdown files in ~/.claude/agents/. Each one has a name, a model, a description of when to use it, and a system prompt. Claude Code's native subagent feature runs them in isolated threads, so their output doesn't pollute Carson's context.
Carson also reaches Telegram. There's a bot running on a 2017 MacBook Pro home server so I can message him from my phone. That setup deserves its own write-up, which I've put in a separate post. Cloud Routines handle scheduled tasks: a morning brief at 07:00, an evening review at 21:30. The home server runs its own instance called Mrs Hughes, who handles smart home automation and stays separate from the main Carson instance.
Rides on the Claude Max plan I already use. No new subscriptions.
A mini manual: set up something similar
You don't need the full Edwardian household to get value from this pattern. Start with the context layer.
Step 1. Build the brain. Create a folder of markdown files about yourself. One file for how you write. One for your current projects. One for decisions you've made. This is your wiki. It doesn't need to be big. Five pages of genuine signal beats 50 pages of notes you never re-read. (Mine started at maybe 12 pages. The 169 came later.)
Step 2. Wire it into Claude.
Create ~/.claude/CLAUDE.md. This is the file Claude Code reads at the start of every session. Write a short description of who you are, what you're working on, what rules you want it to follow. Add @import lines pointing to your most important wiki pages.
Step 3. Run the teammate test. Open a fresh Claude Code session. Ask a real question about your current work. Does it answer like a teammate or like a stranger? If it's a stranger, your context isn't loading. If it answers from what you wrote, you've passed.
It's a vibe check, basically. But you'll feel the difference instantly.
Step 4. Add specialists when you feel friction.
You don't need 13 subagents. You need one for the task you do most that benefits from a focused prompt. Writing? Make a writer. Code review? Make a reviewer. Each is a markdown file in ~/.claude/agents/ with a system prompt and a model: field. Don't pre-build a roster. Add them when you notice yourself wishing one existed.
Step 5. Add cadence last. Routines and scheduled tasks are Phase 5 work. Don't automate before you've built a context layer worth automating on top of. I made this mistake. Don't recommend it.
Context first. Connections second. Capabilities (specialists) third. Cadence last. Each layer compounds the one below it.
What this isn't
It's not magic. The quality of what comes out is directly proportional to the quality of what's in the wiki. A sparse, vague context layer produces sparse, vague responses. The model doesn't fix your thinking for you.
It's also not fully autonomous. Carson doesn't send emails without me pressing a button. Lord Grantham writes code but I review it. The Marchioness of Hexham reviews pull requests but I merge them. The AI does more. The human still decides.
And it's not finished. It's a living system. I run a weekly skill-hygiene pass to retire unused procedures, and a bi-monthly audit that scores the OS out of 100. The score was 62 when I started. I'm not going to tell you what it is now because I'd rather not jinx it.
I should also address a fair charge. Strip the costumes and you've got a CLAUDE.md with three @import lines and stock subagents. That's not wrong. None of the substrate is novel. It's Claude Code's documented features used deliberately. The novelty isn't the plumbing. It's the wiki — 169 pages of accumulated thinking that becomes the brain. The architecture is dead simple on purpose. The value is what you put in it.
Here's what that actually looks like.
I needed to write a post-meeting Slack message to a colleague after a difficult product call. Stock Claude, no context, gave me: "Hi [Name], just wanted to follow up on our conversation today. I think there are some really interesting points we could explore further. Happy to chat more if that would be helpful!"
Inoffensive. Generic. Nothing I'd send. Reads like the email a CRM autodrafts when it's trying to sound human.
Carson, with the tone-of-voice playbook loaded, gave me: "Good call earlier. I'll push the timeline concern to Jira and flag it before sprint planning. Want to make sure we're aligned on the trade-off before we commit."
One sentence of acknowledgement, one concrete next action, no throat-clearing. Same model. The wiki is doing the work.
What I didn't expect, honestly, was that the thing I'd reach for most isn't the code specialist or the design reviewer. It's the context layer itself. Just having the wiki visible. Knowing that Carson can pull my own thinking back at me when I need it. That changed how I work more than any individual agent did.
The staff is useful. But the brain is what matters.