The most-quoted prediction in my world right now is Sam Altman's — that we are close to the first one-person billion-dollar company, a thing that was unimaginable before AI.1 Dario Amodei, asked when the first billion-dollar company with a single human employee would arrive, answered "2026" with 70–80% confidence.2 I find the framing useful and slightly beside the point. I am not trying to be a company of one. I am trying to run several companies with one small senior team, which is the same leverage aimed at a different target.
The frontier is leverage, not headcount
Strip the headline off the one-person-unicorn idea and what is left is the real claim: the output that used to require an organisation can increasingly be produced by a few people who are very good and a lot of agents that are reliable enough. My whole operating thesis at Gigaverse is that if that is true, the best use of it is not to shrink to one person — it is to point that leverage at a portfolio. One senior team, running Gigabit, GigaCommerce, Top Dentistry and FormBridge, on machinery that is built once and reused everywhere.
One senior team, shared machinery
The structural bet is the one I made the case for in Services become software: the expensive parts of building an AI-native company — the engineering scaffolding, the deployment and ingestion kits, the telemetry, the brand system, the back-office apparatus — transfer between ventures, while the domain knowledge does not. So you build the machinery once, centrally, and let each venture draw on it. Four companies do not need four platform teams. They need one, and four thin domain layers on top.
Headcount is what you add when you do not have leverage. The studio bet is that shared machinery plus agents is leverage, so the team stays small on purpose — not as a constraint, as the design.
The delegation line: what runs on agents, what stays human
The single most important decision in an operation like this is where the line sits between the work agents own and the work people keep. My rule of thumb is the one I argued for in production agents: agents take the high-volume, reversible, instrumentable work where a wrong answer is cheap to catch and undo; humans keep the irreversible, high-judgement, relationship-bearing decisions where being confidently wrong is expensive.
In practice the line runs like this. Agents own the work that is high-volume, well-specified, and cheap to check or reverse: drafting and first passes, research and summarisation, catalogue and data hygiene, the front-desk and support surfaces, monitoring, the routine glue between systems, and a steadily growing share of the code. Humans keep the work that is irreversible, relationship-bearing, or genuinely novel: what to build and what to kill, hiring and the calls that shape a team, the first conversation with a customer who is deciding whether to trust us, and any decision where being confidently wrong is expensive and hard to walk back. The test I actually apply is not "can an agent do this" — increasingly it can attempt almost anything — but "if it is wrong here, how fast and how cheaply do we catch and undo it." Cheap-to-catch goes to the agent with a check around it; expensive-to-catch stays with a person. The line moves left every quarter as the checks get better, and the discipline is moving it deliberately rather than by accident.
The stack itself
The abstract version of the operating system is above; the concrete version is a specific set of tools wired together, and that specificity is exactly what makes this kind of essay useful rather than aspirational.
By layer, then. The build layer is frontier models plus a small, shared set of scaffolding the ventures all draw on — the eval harnesses, the ingestion and deployment kits, the component and brand system — so a second venture inherits most of its plumbing instead of rebuilding it. The orchestration layer is where agents get wrapped in the discipline I keep going on about: evals in front, bounded actions, escalation, telemetry behind, so an agent is a monitored worker and not a loose cannon. At the infrastructure layer I am deliberately boring — this very site, for instance, is a standalone Next.js app on our own Dokploy boxes with a single Postgres table behind it, because unglamorous and self-hosted is cheaper to reason about than clever. Knowledge lives in one shared place the ventures and the agents both read from, so context compounds instead of fragmenting. And the back office — formation, banking, tax, compliance across two countries — runs on FormBridge, because we had the problem before we sold the solution. I will not pretend this is a fixed, finished toolchain; the specific tools churn constantly. The shape is what is stable: shared machinery, agents on a leash, boring infrastructure, one memory.
The rituals that keep it coherent
Machinery without rhythm drifts. Running several companies off one team only works if there is a cadence that keeps them coherent without drowning the team in coordination — the weekly shape of how work moves, gets reviewed, and gets shipped across ventures.
The rhythm that holds it together is deliberately light. The organising question each week is not "what is everyone doing" but "what is the one thing across the whole portfolio that most needs a senior brain on it right now" — and the machinery exists so that most weeks, most ventures do not need one. There is a regular pass where the shared team looks across all four ventures together, decides where the scarce senior attention goes, and lets the agents and the mid-level owners carry the rest with their checks around them. My own job, done well, is to stay out of the critical path: make the decisions that unblock, set the direction, and then get out of the way — because the fastest way to cap a small team's leverage is to route everything through one person. When I find myself in the critical path, I treat it as a signal that something upstream is mis-designed, not that I need to work more hours.
FormBridge is the back office
There is a nice recursion in the operating model: the cross-border apparatus that a global, dual-hub studio needs — formation, banking, tax, compliance — is exactly what one of the ventures, FormBridge, is built to deliver. The studio's own back office is the first customer of its own product, which is both efficient and the best possible way to find out where the product is still rough. It is the same follow-the-sun, Wyoming-and-Dhaka setup I wrote about in Building from Dhaka, with the boring-but-critical operational layer handled in-house.
What this means if you are building one
Three sentences for anyone tempted by the leverage. Build the machinery once and centrally, because a second and third venture are nearly free only if the expensive parts were designed to be shared. Draw the agent-versus-human line explicitly and revisit it, because the whole model rests on delegating exactly the work that is safe to delegate and no more. And keep the team small as a deliberate design choice rather than a temporary state, because the moment you solve a leverage problem by hiring, you have quietly traded the thing that made the model work.
The honest caveat: leverage has a ceiling, and I do not yet know where mine is. Running several companies on one team is exhilarating when the machinery holds and brutal when it does not, and there is a real failure mode where "small team, high leverage" quietly becomes "small team, everything on fire." I am writing this as a working hypothesis I am actively testing in public, not a victory lap — and I will keep updating it here, honestly, as the answers firm up.