Everyone's building a personal OS with Claude Code. But what happens when a second person needs to use it? That's a fundamentally different design problem.
Hey, my name is Anthony. I started Product In Your Pocket to help people build software that works. I hope you enjoy this read. Reach out to me on LinkedIn or contact us if you have any questions.
Skills, subagents, hooks, context files. Refined over time into something genuinely powerful. Highly customised to how you work.
And anyone who has built one knows how crazy it is. The quality of output when it's deeply embedded with your context, your workflows, your way of working. It's a genuine step change.
But I keep coming back to the same question: what happens when a second person needs to use it?
Most of us don't operate solo. We have teams. Partners. Clients. People who need to interact with the same systems, the same context, the same business logic.
That's where it gets interesting.
It's a fundamentally different design problem.
The reason a personal OS produces such high quality output is because it's deeply embedded with context. It knows who you are. How you work. What you're trying to achieve right now.
Strip that away and you're back to generic prompts and generic results.
So the real question is: how do you maintain that depth of context per user while sharing business-level context across a team? That's not a settings file. That's an architecture decision.
Your ops person wants to type a plain English command. Your developer wants to wire up a new subagent. Same system. Wildly different interfaces.
A Business OS needs to serve both without forcing either into the other's workflow. That means thinking about interaction layers, not just features.
Not everyone should be able to trigger every skill or action. But you also don't want to build a bureaucratic approval layer on top of something that's supposed to move fast.
The balance is hard. Too open and someone triggers a workflow they shouldn't. Too locked down and you've killed the speed that made the system valuable in the first place.
Two people updating the same client brief in different sessions. Who wins? How does the system reconcile that without someone manually merging?
This is a solved problem in version control. It's not a solved problem in AI context management. Not yet.
Here's one that almost nobody is talking about.
A Business OS isn't just people chatting with it. It's your other software triggering it too. A webhook fires from your CRM. A payment lands in Stripe. A form submission comes through your website. All of these need to hit your orchestration agent and kick off the right workflow, with no human in the loop.
So now your system needs to handle interactive users and background processes through the same brain. That's a very different beast to a chatbot.
Business-level defaults. Team-level overrides. User-specific preferences. MCP connectors that only certain roles need. Skills that only certain people should see.
That's not a flat file. That's architecture.
And it needs to be maintainable by someone who isn't the person who originally built it.
A personal OS works because you maintain it yourself. You know what changed and why.
A Business OS can't rely on one person babysitting it. It needs to be mostly self-sufficient. Learning from usage. Updating its own context. Surfacing when something is broken or contradictory. Human intervention should be the exception, not the norm.
I'm convinced this should all be built on top of Claude Code. Not because it's the best AI. Because it's the right abstraction layer.
It already solves the boring-but-hard infrastructure problems:
The alternative is stitching together LangChain, custom orchestration, your own context management, your own permissions layer. Now you're maintaining infrastructure instead of solving business problems.
Claude Code gives you the primitives. You compose them into a Business OS instead of building the whole stack yourself.
So what does this actually look like in practice? Five layers, each solving a distinct problem.
Layer 1: A shared configuration base. This is the team's operating system. It contains shared skills, agents, hooks, company context files, and MCP server connections. When the admin updates a skill or adds a new agent, those changes sync automatically to every team member. No redeployment. No migration. Just version-controlled configuration that Claude Code picks up natively.
Layer 2: Per-user overrides. Claude Code already supports local config files that stay personal to each team member. Everyone gets their own context (name, role, preferences) and their own MCP connections (personal email, calendar, credentials). The shared layer sets the defaults. The local layer customises the experience without touching anyone else's setup.
Layer 3: Your existing tools, connected via MCP. This is the key insight for the data layer. You don't build a custom database for CRM data, tasks, invoicing, or email. You connect the tools the business already uses (HubSpot, Linear, Xero, Gmail) through MCP servers. The only custom data store is a thin auth layer for user roles and an audit log. Everything else stays where it already lives.
Layer 4: Multiple interfaces, one backend. Your developer opens the CLI and runs Claude Code directly. Your semi-technical team member uses Claude Code on the web. Your sales person messages @Claude in Slack. All three hit the same shared config, the same skills, the same data layer. Different entry points, same brain.
Layer 5: Specialised agents. Not just one generic assistant. A sales agent that understands pipeline and proposals. An ops agent that handles task management and time tracking. A content agent that writes in your brand voice. Each one is a markdown file with domain expertise, specific tool access, and defined workflows. The orchestrator reads the user's intent and delegates to the right specialist.
The clever bit is what ties it all together.
Hooks enforce permissions at the system level. Not in the prompt (which can be worked around), but as code that runs before any tool executes. A junior team member asks Claude to delete a client record. The hook checks their role, blocks the action, and tells them to ask an admin. No prompt engineering required.
Corrections propagate across the team. When someone corrects Claude ("we don't format proposals like that"), the system can detect the correction pattern and route it to the right config layer. Update the skill definition. Commit. Push. Now that correction applies to everyone, not just the person who caught it.
Context stays fresh automatically. Post-action hooks compare new information against existing context files. If a conversation reveals a new stakeholder or a pricing change, the system flags it and suggests an update. A scheduled weekly audit catches anything that's gone stale. The system maintains its own state.
This is what separates an operating system from a chatbot. It doesn't just respond. It learns, enforces, and maintains.
This is what I find most interesting.
What makes a great OS is that it evolves naturally through use. You add a skill because you needed it. You refine a prompt because it wasn't quite right. Over time it becomes incredibly capable.
Scale that to a team and you get one of two outcomes: a beautifully emergent system, or spaghetti.
The difference is guardrails. Not rigid ones. The kind that guide growth without killing it.
I don't have all the answers. But I'm doing enough Claude Code setups and training with solo operators to know that this is the logical next step. The patterns are clear. The gaps are obvious. And I'm actively looking into what it takes to bridge them.
Because once you realise what's possible, you want the rest of your team using it too. No matter their skill level.
The personal OS was the proof of concept. The Business OS is the product.
Book a free consultation if you're thinking about building a Business OS for your team, or if you want help getting your personal Claude Code setup right first.
Keep reading
About us
A team of product engineers based in Queenstown, NZ. We work with you to understand the problem first, then build the right thing — not just the possible thing.
Book a consultation