Part 1 of 5 in the series “How We Built a Distributed AI Team.” A new post each week.
I built a distributed AI team to run the operational side of a one-person company, and I’m telling the story in order — origin first — because the interesting part isn’t the architecture I ended up with. It’s the specific walls I hit that forced each change. This post is about the beginning, when the whole team was one program.
The setup that worked
When I started, the “team” was a single Claude session running in a terminal on my laptop.
That’s it. One process. I’d describe what I needed — draft a reply to this email, reconcile these invoices, check whether that compliance record was current — and the session would spin up a sub-agent inside itself to do the work, hand the result back, and wait for the next thing. I gave the orchestrator a name, Bell, mostly so I’d stop talking to a blank prompt. Bell would “delegate” to a researcher, a bookkeeper, an assistant. On paper it was a team. In reality it was one context, one identity, one machine, wearing every hat in sequence.
And I want to be honest about this, because the tone of these posts is not “everything was broken and then I fixed it.” The single-session setup was genuinely good. It got a solo company’s back office running. It read my inbox and drafted replies in my voice. It kept a task board. It could pick up a half-finished thought from earlier in the same conversation and carry it forward. For a while, the ceiling felt very high — most days I never touched it.
The reason I moved off it is not that it failed. It’s that I could see precisely where it would fail, and the failures were all the same shape: everything was one thing.
One context
Everything the team knew lived in a single conversation window.
That sounds fine until you watch it fill up. A long day of work — a few dozen emails triaged, an invoice run, a compliance check, some content drafted — is a lot of text, and it all had to sit in one context for the orchestrator to reason over it. When the window got full, the oldest material started falling out the back. The session that had confidently summarized my morning inbox at 09:00 had genuinely forgotten it by 17:00, not because of a bug, but because the words were no longer in the room.
There was no separation between “the bookkeeping I did this morning” and “the email I’m drafting now.” It was all one undifferentiated stream. The assistant work and the accounting work and the compliance work were literally sharing the same short-term memory, and they competed for it.
One thing at a time
The deeper limit was that a single session does exactly one thing at a time. It has to.
If I asked for an invoice reconciliation and, while it was working, remembered I also needed an email drafted, the email waited. Not because drafting an email and reconciling invoices have anything to do with each other — they don’t, they touch completely different systems — but because there was one worker and it was busy. The two tasks were fully independent and still ran in a queue.
This is the bottleneck that bothered me most, because it was pure waste. The whole promise of building with AI agents is that they don’t have human capacity limits — you can run five of them at once as easily as one. A single session throws that promise away. It reintroduces the exact constraint you were trying to escape: a team of one, doing tasks in a line, no matter how many tasks are actually parallel.
One identity, one set of keys
Because it was all one process, it was all one login.
The orchestrator held every credential at once — the mailbox, the accounting system, the calendar, the document store — because whichever “hat” it was wearing might need any of them. There was no wall between roles. The part of the system drafting a marketing post ran with the same access as the part touching financial records. Nothing was scoped down to what a given job actually needed.
For a solo operation that’s a tolerable risk right up until it isn’t. But it also just felt wrong to build on. A bookkeeper shouldn’t be holding the keys to the mailbox. A content drafter has no business anywhere near the accounting system. In one session, everyone holds everything, and “least privilege” isn’t even a concept you can express.
One memory
There was one notebook, and everyone wrote in it.
Whatever the session learned — my preferences, a decision we’d made, the state of an ongoing task — went into the same shared memory. There was no such thing as “the bookkeeper’s knowledge” versus “the assistant’s knowledge.” It was all pooled. That made some things easy (everyone knew everything) and one thing impossible: I couldn’t reason about any role in isolation, couldn’t hand one of them its own durable state, couldn’t let a specialist get genuinely expert in its lane without dragging the entire shared history along with it.
One life
And all of it — the context, the queue, the keys, the memory — lived and died with a single process on a single laptop.
If the session ended, the team ended. Close the terminal, the machine sleeps, the process crashes — and the entire operational memory of the company for that session is gone. Not archived somewhere. Gone. Everything the team was and knew was tied to one program staying alive. There was no version of “the team” that existed independently of that one running process, which meant there was no resilience at all. It was a team you could end by closing a window.
Where this leaves us
None of these are exotic problems. They’re the obvious consequences of a single, honest architectural fact: the team was one program. One context, so knowledge was capped and volatile. One worker, so everything was serial. One identity, so nothing was isolated. One memory, so no role could stand on its own. One process, so the whole thing was mortal in the most literal sense.
Every one of those limits traces back to the same root, and so does every fix. You cannot patch your way out of “it’s all one program” while it stays one program. Adding more sub-agents inside the session doesn’t help — they’re still sharing the one context, the one queue, the one identity, the one memory, the one life.
The way out was structural, and it was a single move: to scale, the team had to stop being one program and become many. Separate agents, each with its own context, its own credentials, its own memory, its own runtime — able to run at the same time, and able to outlive any single session or machine.
That move is the rest of this series. The next post is where it starts: taking the roles that had been hats on one orchestrator and turning them into real, independent members of the team — with their own identities, their own keys, and a place to actually live.