How to manage multiple AI‑native companies.

One switch, not two laptops

I thought for a while the answer was separation by machine. A VN laptop, a Lemonbrand laptop. That's not true, at least not for me. I move between the two businesses all day, and so do my agents. What I needed was one switch.

So I built a tiny command called side. You ask it which side you're on and it tells you, based on the folder you're in: a repo can carry a one-line .side file that says verifiednode, and anything under it is VN. side vn in front of any command runs it as VerifiedNode, side lb as Lemonbrand. side doctor checks every login on both sides and tells me what's broken, without ever asking me for a password. An agent starting a session runs side first, the same way you'd look at which keys you're holding before you open a door.

The switch has to be dumb and visible. No magic that guesses. If an agent is about to send an email, it should be obvious, from one line, which company it's sending as.

Two Google admins, side by side

Each company has its own Google Workspace and I'm admin on both. The Google CLI I use (gws) keeps its login in one folder, so I give each company its own folder. Plain gws is Lemonbrand, always, so nothing old breaks. gws-vn is VerifiedNode, with its own login, its own encryption key, and it refuses to finish logging in if the account isn't on the verifiednode.com domain.

I've seen what happens when your personal Gmail ends up wired into a company tool. Never again.

The login app itself lives inside each company's own Google Cloud, set to internal only, so only people on that domain can use it. When Gab sets up his machine he uses the same one, with his own account. Nothing about VerifiedNode depends on a Lemonbrand project existing.

For jobs that run unattended, it's not my login at all. It's a service account the Google admin delegates to, with only the scopes that job needs. My personal login is for me and the agents sitting next to me. Anything that runs at night gets its own identity.

GitHub: the org says who owns it

Same idea. Lemonbrand work lives under my account and the Lemonbrand org, VerifiedNode work lives under the Verified-Node org where Gab is an owner. Every agent works in its own worktree (a separate copy of the repo on its own branch), so a bunch of them can run in parallel without stepping on each other, and nothing lands on main without a pull request.

Each company also has a repo that is its brain. Not code, context: what we sell, who we're talking to, what changed. The repo's instructions file is the first thing any agent reads. When the business model changes, that file changes first, otherwise every agent keeps working from last quarter's plan.

The shared skills (how I write, how a document gets made, how to schedule a job) live in one folder and both Claude and Codex read the same copy. One copy, never forks. A fork is how two agents end up with two different ideas of how I sound.

1Password: people and agents get different vaults

Every company gets two vaults. One for people, where the logins live. One for agents, that only holds what scripts actually read, and that a 1Password service account can open. A service account is a token with no person behind it: it reads one vault and nothing else.

Why bother? Because before this, every agent secret went through my unlocked 1Password app. The moment it locked, deploys stopped, all of them at once. The agent shouldn't need me awake to do its job.

The rules are short. Agents read secrets through one helper, side secret vn <ref>, which tries the company's agent token and falls back to my own login. A secret never goes in a repo, a chat, Slack, or a file someone else can read. It never gets copied from one company's vault into the other. And the servers never call 1Password while they run: at deploy time the secret gets written into a root-only env file on the box, and the box reads that. If 1Password is down, nothing in production notices.

Drive is for people, repos are for agents

I don't run my business out of Drive. Drive is where finished things go for humans: the PDF a client opens, the Google Doc they comment on, versioned and filed in a library. Every document gets made by a pipeline from named sources, then it lands in Drive. The source of truth is the repo or the database behind it, and Drive is the shop window.

That split matters with two companies. A VerifiedNode doc lives in VerifiedNode's Drive, sent from a VerifiedNode address, and a Lemonbrand client never finds a VN folder in their shared drive.

The boxes

The last piece is the servers. I don't use hosted agent platforms or cloud routines. I rent small Linux boxes (a VPS, a virtual private server) and the agents live there. One back office box for Lemonbrand, one box per company or per client trust boundary, so a client's data sits on a box that only does their work. VerifiedNode's support desk and sales agents run on their own box.

I like the droplet model because the attack surface is tiny. I'm literally a needle in a haystack. A box does a handful of jobs, every job is on a timer I own, every timer reports when it fails, and if one gets weird I can read every line of what it did.

The laptop is the cockpit, not the engine. I sit at the Mac and steer, the boxes do the work all night. If my laptop dies tomorrow, the businesses keep running. Don't get me wrong, I'd absolutely be in the car and on the way to my local Apple store. But nothing stops.

Every agent runs inside nono

Every claude and codex I start goes through a small wrapper before it runs. It does two things. If I start an agent in a company's main checkout, it moves it into its own worktree first, so nobody works on main by accident. Then it launches the agent inside nono (nono.sh), a sandbox that wraps the process at the operating system level and decides what it can read, write and reach.

I thought the answer was to lock everything down from day one. That's not true, it just broke every session. So the profile on my laptop is open on purpose: the home folder, the keychain, the network. What it gives me today is a name for every running session and an append-only log of what each agent did. The day I tighten it, I tighten one profile and every agent on both sides gets it at once. Never one agent at a time.

The jobs on my back office box run under nono too, and a script proves the sandbox holds before I trust it. The strict end, for client data, is a container that can only call out to an allow list.

My personal take: blocking secrets with prompt rules or hooks is theater. An agent can always find another way to read a file. You wall the file off at the operating system, or you take the file away.

History lives in AgentsView

Every session, Claude or Codex, Lemonbrand or VerifiedNode, lands in AgentsView, which runs locally on my Mac and indexes every agent conversation I've had. It's how I pick a conversation back up days later without re-explaining anything, and how I pass one between models: Claude starts a build, Codex picks up the same thread to critique it, or the other way around. When I can't remember why we decided something, the answer is usually in a session log, not in my head.

That's also why it stays local, with its telemetry turned off. The archive holds both companies' work, so it lives on my machine and nowhere else.

Why I'm sharing this

I'm putting this out because I've never written it down, and because I want to hear how you do it. Comments and suggestions are open. If you've solved one of these pieces better, tell me.

One thing though. I'm not one to blindly trust a recommended GitHub repo. Someone links a framework that does everything, and you're supposed to install it on the machine that holds both companies' keys. That's not how I work. I work from principles, and I like a singular tool for a singular purpose: one switch for which company, one sandbox around every agent, one vault for people and one for agents, one place for history. Each piece is small enough that I can read all of it, and swap it out when something better shows up.