The cockpit. Henry (architect) and Margo (red team critic) on the left, five MiniClaude workers up top, Relay running the work-order queue in the centre, and the voice mic in the foreground, which is where the angry little monologues go in.
People keep asking what I actually mean by the synthetic company. The architect. The HR department. The test goblins. The board of management that doesn’t quite exist yet. It sounds like a joke, and to be fair, a lot of it is, I am incapable of building anything without immediately giving it a little hat, a job title and an HR problem.
But underneath the theatre there’s something concrete, and the photo above is most of it: one human architect running a small software organisation made entirely of machines. Workers along the top, orchestration in the middle, architects to the right, oversight off to the left, and a microphone in front of it all. That is the whole argument of this piece, already laid out in hardware. The rest is just how it got there.
It started simply. Early ChatGPT days, Pine Script, trading indicators, reusable snippets. The familiar loop, ask the machine, get code, test it, correct it, ask again. AI as a clever assistant.
Then the tooling got better. Claude arrived. VS Code became part of the workflow. The systems got serious. And I noticed something: one coding assistant is useful, but several coding assistants with one senior model sitting above them as architect is a different category of thing.
So that became the model. One LLM at the top of the tree. I’d voice dictate concerns, requirements, half formed objections and angry little monologues at the architect, that is the mic in the foreground of the photo doing its job, and it would turn that into structured work. Not vague instructions. Deltas. Small units of delivery. Touch these files, not those. Preserve this contract. Add this test. Give me a rollback point. Explain the risk. Do not wander off into the shrubbery.
Those deltas went to the coding agents, the MiniClaude workers across the top row. They implemented, reported back, the architect reviewed, I intervened where needed. For a while it was magical.
It was also ridiculous, because I was the integration layer. The meat based message bus. The woman in the middle copying responses from one agent into another like a frazzled Victorian clerk with a clipboard and a caffeine problem. It worked. It was stupid. And it produced the first rule of the whole project:
When the manual copying becomes a repeatable pattern, automate the pattern.
That’s where Relay began, the orchestration layer running the work order queue in the centre screen. Its job is to move work, context, trust and decisions around without me being the monkey with the clipboard. The baby version is “send this prompt over there.” The real version is harder: Relay has to know which agents are trusted for which work, when to delegate and when to escalate, when two agents should talk directly and when I need pulling in, and when something should be audited, blocked, summarised, retried, parked or killed.
This is why the corporate metaphor keeps surfacing. I thought I was joking when I called them architects, reviewers, HR and test goblins. But the moment you have several workers across several projects; you hit problems that aren’t coding problems at all. Who knows what. Who’s allowed to decide. Who’s blocked, who’s off in the weeds, who’s confidently wrong, who’s earned something harder, and who’s just made a mess and needs their crayons taken away. Those are management questions. The metaphor wasn’t decoration. It was load bearing.
Then I hit the next problem, and it’s the one most people miss.
Once I stopped being the manual integration layer, I discovered I was still the cognitive blocking layer. First, I was the integration layer. Then I became the bottleneck.
The constraint was never really the typing. Sometimes the constraint is that I’ve made three hard architectural decisions in a row and my head is full. One project wants me to reason about an authentication model, the next wants a delicate product call, the next wants me to review the interface between two systems, and I cannot context, switch endlessly like a machine, because I am the one part of this system that isn’t one.
So, the system has to understand the RAM tax on my head. Every blocking decision has a cost, and the costs aren’t equal. Picking a button colour is cheap. Reviewing a security model, resolving a cross, project interface, working out whether an agent has misunderstood the architecture or merely explained it badly, those are expensive. A good orchestrator shouldn’t just throw me the next decision because it’s next in the queue. If I’ve just spent two expensive decisions on unrelated projects, the right next task might be a cheap one. Let me rename the tab before I go back down the mine. That sounds trivial. It’s the difference between a system that technically works and one a human can actually survive at scale.
The other lesson is visibility. I don’t yet trust the workers to disappear into headless execution; they don’t get to work from home. Another joke, again not really. That is the entire reason for the wall of screens in the photo: I need to see the windows, and I need to see the drift.
I had this exactly with Opportunity Scout and Relay. Opportunity Scout finds opportunities; Relay turns them into objectives and work; the two need to talk. So, I let the workers explore the interface between them, and they went miles too deep, defining far too much far too early, polishing both sides of a fence nobody had finished placing. I had to step in like a tired manager and say: enough, lads. Rough it out. Diverge again and get back to your actual jobs.
That’s the part that surprised me. The system can’t only automate work. It has to allow interruption, governance, the breaking of the chain when the work is travelling the wrong way. That’s what the cockpit is for. The screens aren’t vanity, and I’m not sitting there because I want to look like a Bond villain who got lost in PC World. In time more of that visibility can be summarised, the orchestrator briefing me, a future board detecting drift, the system warning me when agents are looping or over, coupling or arguing themselves into a swamp. But I’m not handing it to a black box yet. Not because I doubt the technology, but because I’ve used it enough to know precisely where it’s brilliant and precisely where it’s a menace.
And that’s the actual point. The synthetic company isn’t an attempt to pretend the machines are people. It’s a way of organising machine labour around human judgement, turning LLMs from isolated chat windows into roles, workflows and delivery systems. The strangest part is that I can no longer build the system without the system. The synthetic company is building the synthetic company, which is absurd, and one of the most stimulating things I’ve ever worked on.
It started with Pine Script snippets. It became a room full of synthetic workers. And the real project stopped being software somewhere along the way. The real project is learning to run an artificial organisation without trusting it too much, or wasting my own mind doing work the machines should already have done, something alive enough to need management, dumb enough to need supervision, and capable of amplifying one person enormously, provided that person doesn’t become the exhausted little monkey carrying messages between the robots.
