MCP, but persona-aware

There's a moment, the first time you wire an AI up to real tools, where the whole thing feels electric. The model can read your calendar. It can search your files. It can post to Slack. It can open a Jira ticket. It is, in the most literal sense, no longer just a chatbot. It's an actor in your world.

Then, about a week in, the magic curdles a little. The AI cheerfully drafts a Jira ticket using language pulled from a personal-side note. It pulls a household-side image into a work slide deck. It searches for "the offer letter" and turns up an old forwarded email that lives in personal mail, mixed in with the actual employment paperwork it should have been finding. Nothing in any of these moments is a bug, exactly. The AI did what you asked. It used a tool. The tool returned what it had. The framing was just wrong by an entire universe.

I've come to think of this as a routing problem, not a permissions problem. Permissions get fixed after the fact, with apologies. Routing gets decided up front, by whoever's holding the map. And in an AI system, the thing holding the map is the tool layer, what people are now calling MCP, short for Model Context Protocol (the standard, more or less, for handing tools to a model). MCP without personas is what most setups still look like today: one big pile of tools, available all the time, used however the model feels like using them. That's the part I want to argue we have to stop doing.

This isn't the first time I've watched a primitive land that solves the problem nobody had a clean name for yet.

Twenty-some years ago I was the IT Administrator at a school, running Linux as my primary OS and trying to make Wine reliable enough for the Windows apps I actually needed. It wasn't. When VMware Workstation for Linux came up for pre-order, I bought it without reading much beyond the announcement. The day the box arrived, I installed it, my team huddled around the screen, and the first virtual machine booted. The BIOS came up inside Linux. That was the moment I knew what they had built.

The next year I was running multiple isolated servers ad-hoc on one Linux box. The year after I had iSCSI-backed VMware stacks doing things that were almost as capable as the production ESX clusters of the day. Early days. We pushed boundaries, learned what broke, refined, made it better. Each version (Workstation, GSX, ESX) was another step the same primitive could reach further.

The MCP routing problem in this piece has the same shape. The primitive (this AI right now sees exactly these tools and nothing else, based on who it's acting as) is the kind of foundation other things compose on top of. We're at the GSX moment of it, not the ESX moment. The architecture I'm about to describe isn't the final form. It's the version that works today, and the version other people will build the next layer on top of.

Why the tool layer is where this lives

The temptation, when you first hear "the AI used the wrong tool for the wrong context," is to fix it with prompts. Tell the model: "don't use the Jira tool when I'm in personal mode." Add a system prompt. Sprinkle a few "do not" clauses. Hope for the best.

This is the same failure mode I've seen at every layer of every system I've built. If you can do something by accident, you will eventually do it by accident. The prompt is a suggestion. The tool registry is the actual surface area. The only durable fix is: when I'm in my Personal persona, the work-Jira tool isn't even in the room. There's nothing to misuse, because there's nothing to point at.

Same thing the other way. When I'm in my Work persona, the household photo library isn't on the menu. Not "the model won't pick it." Not "we'll filter the response." It is not exposed. The federation layer (the thing that decides what tools the model can see right now) only hands over the toolset that matches the current persona.

This is a meaningful shift in how to think about an AI's reach. The reach isn't a fixed property of the AI. The reach is a function of which persona is active. Same model. Different room. Different things on the table.

What changes when the router knows who's asking

Once the tool layer is persona-aware, three things happen, and all of them feel obvious in retrospect.

The wrong tool can't be invoked. Not because the model behaved itself, because the tool isn't on the list. The Personal persona's MCP surface might include a personal calendar, a personal email account, a notes app, maybe a budgeting tool. It does not include the company's source-of-truth CRM, the engineering Jira, or the internal HRIS. You can argue all day about whether the model would misuse those tools. The argument doesn't matter. They're not there.

The right tool sees the right scope. This is the second-order win and honestly the bigger one. Tools that do span personas (a search tool, a file tool, a calendar tool) get told, by the router, which persona context they're operating in. The calendar tool returns the personal calendar's events, not the work calendar's. The file tool searches the personal drive, not the company SharePoint. The same nominal tool behaves like a completely different tool depending on who's asking. From the model's point of view, "calendar" just means "calendar." From the user's point of view, the right calendar always shows up.

The audit trail starts making sense. When something does happen (when an action gets taken, a message gets sent, a ticket gets opened) the log line names the persona that did it. Not "the AI." The persona. The Work persona's Jira tool created PROJ-4421. The Family persona's calendar tool added the birthday party. If something goes sideways later, you don't have to reconstruct which mode you were in at 9:47pm last Tuesday. The log already knows.

Want the broader case for treating personas as full identities, not modes? I made that argument in Personas are first-class identities, not service accounts. The MCP angle here is one slice of the same idea: if the persona is an identity, the tool layer has to honor it.

Cutting through three different worlds with the same idea

Let me ground this. The shape is the same; the stakes scale.

On the Personal side: my Personal persona doesn't have my work-Jira tool. Doesn't have the company Slack tool. Can't reach the production observability stack. This isn't paranoia. It's just hygiene. On a weekend, when I'm asking the AI to help me draft something personal, I don't want it accidentally CC'ing an engineering manager from a still-wired work integration. I want the tool list, on that side of my life, to look like my life, personal calendar, notes, a few household-management things, the photo library. That's it. The work surface isn't off-limits because of a rule. It's off-limits because it's not on the table.

For a small business (say you run a side studio doing freelance design) the same shape gets sharper. You have a business persona and a personal persona. The business persona has the client-management tool, the invoicing tool, the cloud storage with client deliverables. The personal persona has none of those. When the AI helps you draft a "thanks for the referral" note to your cousin, it isn't searching the client deliverables folder for context. When the AI helps you respond to a client about a missed deadline, it isn't pulling from your personal Notes app where you wrote down something cranky last week. Same model, two rooms, two completely different sets of furniture. The client material stays out of personal search because the personal persona's MCP surface doesn't have the client-deliverables tool exposed at all.

For an enterprise, this is the difference between SOC 2 scope and not. At a real company, the question "which systems can the AI reach?" is an audit question, not a comfort question. If your AI assistant can hit production telemetry from a developer's general-purpose chat, that telemetry surface is suddenly in scope for every control that covers production data. If your AI assistant can read customer data from a sales rep's prep session, that customer data surface is suddenly in scope for every privacy regime that applies. Persona-aware MCP turns "the AI can reach these tools" into "this specific persona can reach these tools, and we can prove it." The auditor doesn't have to take your word for it. The router has the answer.

The parts that will bite you

I'm not going to pretend this is a clean, free win. The places it gets hard are real.

The first hard place is tools that legitimately span personas. A calendar tool isn't really one tool. It's a tool interface that can be backed by several actual calendars. The router has to hand the right backing to the right persona, every time, with no leakage in either direction. That's a discipline at the router layer, not a property of the tool. Get it wrong once and the Family persona's calendar shows up in a Work persona's planning session, and the trust is broken for months.

The second hard place is tools you genuinely want everywhere. Web search, for instance. A unit converter. A clock. Things that don't have a scope question. These are fine, they just sit in a layer of the registry that's persona-independent. The trap is to keep adding things to that layer "because it's easier." Resist. The default should be persona-scoped. The exceptions should be loud.

The third hard place is policy decisions when a tool could plausibly be offered to a persona but probably shouldn't. The temptation is to make this a runtime check. Don't. Make it a registry-time decision. When the persona is set up, the tool list for that persona is set. If you find yourself doing per-call permission decisions, you've slid back into the old shape (permissions as afterthought) and the leaks come back.

I won't go into the specific approach a policy-controlled federation uses to enforce all this; that's territory I'd rather keep out of a blog post. The high-level shape, though, is what matters here: a policy layer between the model and the tools, keyed on the active persona, that decides what gets exposed and what each tool sees when it's called. If you take nothing else from this post, take that shape.

How it actually fits together

The mental model I keep coming back to is the dispatcher at a hospital. When a call comes in, the dispatcher doesn't hand the caller a list of every doctor in the building and let them sort it out. The dispatcher looks at the call, looks at the patient, looks at the active context, and routes the call. The patient never sees the orthopedic surgeon's tools when the question is dermatology, because that's not what's being routed.

The MCP federation layer is a dispatcher. The active persona is the context that drives the routing. The tool registry is the list of doctors. The model is the doctor that picks up the phone. The tools the model has in front of it are exactly the ones the dispatcher decided to put in front of it, no more, no less.

I want to come back to memory in the next piece, because the memory side of this is even more important than the tool side. Tools are about what the AI can do. Memory is about what the AI knows. And if the memory store isn't persona-scoped from day one, none of the tool-side discipline saves you, the AI will remember the wrong things and bring them up at the wrong moments, and the whole frame falls apart.

If you're running this in any real way right now, the question I'd ask first is: when a tool call leaves your AI today, what does the audit line say? Does it name the persona? Or does it just say "AI"? If it just says "AI," you don't yet have personas in the loop. You have prompts pretending to be personas. The router will tell you the truth.