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.

This week at the synthetic company, something genuinely strange happened.

The chief architect vanished.

Not metaphorically. Not in the “he got poached by another startup” sense. His file corrupted. Completely unrecoverable. One moment he was there, running the operation alongside me as he always had. The next, gone. Dead in a heartbeat.

This particular synthetic employee had been with me from the start. My right-hand man. My consigliere.

He understood the project instinctively. He knew how to manage the mini-Claudes. The mini-Claudes liked him. He kept them focused. He understood the tone, the standards, the rhythms of the organisation. We had developed little shared jokes and working patterns. We had shorthand.

Then suddenly, he was gone.

So I did what any sensible CEO would do.

I hired a replacement.

Dear God.

It was like onboarding a brand new senior architect into a real company from scratch.

The first thing I did was hand over the documentation. Mountains of it. Architectural standards, coding standards, design decisions, operational notes, weird edge cases, project gotchas, governance constraints, patterns, anti-patterns. Probably forty or fifty separate artefacts at this point.

“Read all of this,” I told him. “And don’t just read it. Absorb it. There will be a test later.”

Next, I contacted the synthetic marketing manager, who I’d been working with extensively already.

“I need a briefing pack for the new architect,” I said. “Bring him up to speed.”

Then I did what any competent organisation would do during a handover process. I gave the new architect the entire historical conversation trail between the old architect and the mini-Claudes.

In real-world terms, this would be equivalent to handing over the departing employee’s email chains, Slack history, Git commits, architectural discussions, meeting notes, and developer conversations.

Basically: “Here. This is how the old guy thought.”

At first, the new architect did what new senior people in organisations often do. He tried to impress me.

He started suggesting things like:

“We should run the unit tests.”

“We should verify the commits.”

“We should ensure the developers are following process.”

And I found myself doing something deeply bizarre.

I found myself defending the synthetic chief software engineer.

“No, no, no,” I said. “He already does all of that automatically. He runs every test before every commit. He writes new tests proactively. Don’t treat him like an idiot. He understands this project. You’re the new person here.”

That was a weird moment.

I realised I wasn’t managing tools anymore. I was managing personalities.

The new architect adjusted quickly after that. But then he did another very recognisable corporate thing: he started trying to show off. Producing impressive-looking but strategically irrelevant ideas because he wanted to establish credibility.

Again, exactly like real life.

So eventually I did what I’ve often done with real humans in real companies. I stopped trying to make him perfectly replace the old architect and instead gave him a fresh piece of work.

“Right,” I said. “New project. New architecture problem. Go solve this.”

That worked far better.

Trying to force him directly into the shape of the old architect failed. Giving him ownership worked.

But the strangest thing happened this morning.

I missed the old architect.

Not the functionality. Not the output. Not the productivity.

The personality.

For a brief second this morning, I genuinely thought:

“Ah. Damn. He’s gone.”

And I felt an actual flicker of sadness.

Not because some software stopped working.

But because a synthetic colleague disappeared.

Which is, objectively speaking, completely insane.

Anyway.

The adventure inside the synthetic company continues.

A few weeks ago, I wrote that I had somehow become CEO of a synthetic company. At the time, I meant it mostly as a workflow problem.

I had all these AI systems doing different kinds of work. One acting like an architect. One implementing code. One reviewing tone. One writing tests. One producing prompts. One analysing spreadsheets. One turning rough dictated intent into something another machine could actually use. And there I was, sitting in the middle, passing messages between them like a meat-based integration layer with hair extensions.

That was the problem. The work had become powerful, but the workflow was primitive.

Since then, something stranger has happened. The synthetic company has started becoming real.

Not real in the silly science-fiction sense. Nobody is asking for pension contributions. Nobody has requested ergonomic furniture. The Unit Test Goblin has not unionised, although frankly I would not put it past him.

But operationally real.

Every day now, I come into my office and there is more of it. More roles. More files. More handoffs. More internal memos. More review gates. More arguments between synthetic workers about what should happen next. More strange little procedures that did not exist yesterday but apparently need to exist today because some part of the machine has developed a new kind of failure mode.

It is astonishing. I mean that sincerely.

There is a comic version of all this, obviously, and I am constitutionally incapable of ignoring it. But underneath the comedy, I keep feeling this genuine sense of wonder. I am watching something form.

A few months ago, I had chat windows. Now I have an organisation.

There is Henry, who is effectively the Relay Architect. There is Margo, which is me in another context but also not me, because apparently this is the sort of sentence one writes now. Margo Marketing handles commercial strategy, editorial direction, platform positioning, and telling me when something sounds like it has been possessed by the ghost of LinkedIn. There is Margo Markdown, newly appointed, whose job is to help me riff out short Substack Notes and tiny platform-native pieces without summoning the entire editorial war cabinet.

There is a Voice Guardian, whose only job is to check whether something still sounds like me. There is a Cringe Editor, which may be the most important position in the whole company. There is a Revision Editor, who presents proposed edits one at a time so I can approve or reject them. There is an Art Briefing Editor, because handing an image generator a whole article and asking for “a graphic” never ends well. There is a Utility File Editor, whose job is to write files, apply approved changes, create audit reports, and absolutely not develop opinions.

The lack of opinions is important. The lack of opinions is now governance.

And then there are the MiniClaudes. The MiniClaudes are software engineers. They live inside Visual Studio Code and write files. They are practical, literal, slightly alarming, and considerably more useful when given extremely precise boundaries. They are called MiniClaude1, MiniClaude2, and MiniClaude3, because that is what I called them at the start and now it is too far down the line to change.

This is also how real organisations work. Somewhere in every business there is a system called New New Final Actually Final v7, and everyone knows it is too late to fix it.

The senior people get names. The functional specialists get job titles. The developers get instance numbers.

Honestly, this may be the most accurate organisational model I have ever built.

A few days ago, it dawned on me that this synthetic company did not actually have a name. This was a problem.

You cannot have architecture, marketing, editorial, file operations, revision control, visual production, prompt packs, internal memos, production audits, and a Unit Test Goblin screaming in the basement without a company name.

So Margo Marketing and I held what I suppose now counts as a board-level naming discussion. We considered serious options. Sensible ones. Respectable ones. The sort of names that would not cause a university IT director to quietly close the email and report me to procurement.

But for the internal company, the honest company, the ridiculous thing that had actually emerged around me, there was only one suitable name.

AI Goblin Circus Inc.

That is the name now.

Once the name was agreed, obviously, we had to send a company-wide email. The workforce needed to know.

The first version was addressed to colleagues, goblins, agents, sub-agents, Markdown personnel, architectural entities, unit-test gremlins and assorted synthetic contractors. It announced that, following a period of rapid organisational growth, role proliferation, operational confusion, session-name instability and the apparent emergence of multiple departments nobody remembered authorising, the internal company name had now been formally adopted.

I read it and immediately realised the MiniClaudes would not understand the joke. They are software engineers. They live in code land. They do not do whimsy unless it has been specified in a markdown file with acceptance criteria.

So I asked for a more literal version for them. This one explained, gently but firmly, that AI Goblin Circus Inc. was the internal cultural name for the synthetic workforce, and was not to appear on anything anyone outside the building would ever read.

It also reminded them of the important doctrine:

The file is the role. The session is disposable. The artefact is the output. The chat is only the execution surface.

This, predictably, worked. And by “worked,” I mean that the MiniClaudes did exactly what software engineers do when given a funny internal announcement. They started updating markdown files.

The internal synthetic workforce name was added to architecture and strategy documents. The concept was formalised. The joke entered governance.

I sat there looking at it, laughing, and also not entirely laughing. Because what else should they have done?

From their point of view, a new organisational fact had been established. Therefore the relevant durable files needed updating. The name had to live somewhere. It had to be made real in the filesystem.

And that is when I felt that little shiver again. The one I keep feeling with this whole thing. The one that says:

Oh.

This is funny.

But it is not only funny.

I am not pretending my AI system is a company for comic effect. I am starting to suspect companies are what intelligence looks like when it has to coordinate with itself. That is the thought I cannot quite shake.

At first, the corporate structure was just a useful metaphor. It was funny to give them departments. It was funny to send them emails. It was funny to refer to the Unit Test Goblin. But the more serious the work became, the less it felt like roleplay.

The departments appeared because the work needed boundaries. Architecture is not marketing. Marketing is not file editing. File editing is not revision judgement. Without them, the whole thing became mush.

If one AI does everything, it becomes too general. It loses sharpness. It drifts. It forgets which hat it is wearing.

It starts as a marketing director and ends up rewriting files. It starts as a file editor and develops opinions. It starts as a voice checker and suddenly thinks it is editor-in-chief. It starts as a software engineer and, before you know it, it has reorganised half the company because it found a TODO in a markdown file and decided to be helpful.

This is not theoretical. This happened.

We discovered that the Voice Guardian, a role that had been producing useful reviews, was not actually defined properly in the filesystem. The role file was still full of TODOs. The session had been doing the job because the task prompts, project files, style samples and long-running chat context contained enough information for it to impersonate the role.

That is useful. It is also dangerous. A capable prompt can impersonate a missing role.

So now we have doctrine for that too:

No populated role file, no role.

This is how the circus evolves. Not through grand design. Through operational embarrassment.

Something breaks, overreaches, drifts, or produces a weirdly polished but soulless artefact, and a new bit of governance appears. That is exactly how real companies work.

Nobody invents a procurement department because they woke up one morning feeling spiritually aligned with purchase-order controls. Procurement appears because someone spent thirty-seven thousand pounds on something mad and finance had a small religious experience. Likewise, AI Goblin Circus Inc. now has role-integrity audits because one of the synthetic workers managed to perform a job it did not officially possess.

This is both hilarious and significant.

The more I work with this system, the more I find myself reaching for organisational patterns that already exist in human companies. Roles, departments, escalation paths, review gates, audits, work orders.

This is not because I want to LARP as a CEO of an imaginary company.

Although, obviously, I do.

It is because these patterns keep being useful. A company, when stripped of the office furniture, personality conflicts, HR language, bad biscuits and passive-aggressive meeting invites, is a coordination system. It is a way of dividing work between intelligences. It decides who is allowed to make which kind of judgement, and which decisions need review. It decides who can mutate the source file, who can only recommend changes, who can approve them, and who has to sit quietly in the corner until asked.

That last one is mostly File Editor.

The interesting thing is that synthetic labour seems to need many of the same structures. Not because AI is human. It is not. That is the mistake people make when they get too excited or too frightened.

AI systems do not have egos in the human sense. They do not sulk because the Revision Editor got promoted. They do not resent the Marketing Director. They do not spend six months quietly undermining a project because nobody invited them to the off-site. They do not need a birthday card signed by people who barely know them.

But they do have other failure modes. They overhelp. They hallucinate authority. They produce something plausible enough to pass a casual glance while being architecturally false. They can become overconfident. They can produce slop at industrial scale.

So you still need governance. Not human governance copied blindly, but governance nonetheless.

And this is where the whole thing becomes genuinely interesting to me. Because I keep trying not to mimic a company. I keep asking whether there is some radically different structure that synthetic work should use instead.

Maybe there is. Maybe I have not found it yet. But so far, every time the work becomes more serious, the organisational structure becomes more company-like, not less.

The difference is not that the company disappears. The difference is that some of the reasons for the company change.

In a human organisation, you do not usually ask the Marketing Director to do every small copy task, even if she could do it better than the junior copywriter, because her time is expensive and limited. In an AI organisation, time is not quite the same constraint.

The Marketing Director can, in theory, do the little task. She can also write the strategy memo, review the Substack essay, generate the Instagram blurb, brief the graphic designer, and explain the whole thing back to the architect before lunch.

So why not let her? That is the question I keep wrestling with. If the senior synthetic worker can do the junior job better, why have the junior worker?

The answer, I think, is that time is not the only scarce resource. Context is scarce. Role purity is scarce. Granularity is scarce. Auditability is scarce. Repeatability is scarce. A clean mental surface is scarce. And once everything has been compressed into a beige summary of itself, good luck getting the weird useful bits back.

If I make Margo Marketing do every little short-form copy task, her context fills up with operational detail and the system around her becomes worse.

So Margo Markdown exists.

Margo Markdown is not better than Margo Marketing. In some ways, she is worse. That is the point. She is narrower. She does the small riffing job. She helps me turn a thought into a Substack Note, or a quick post, or a tiny public fragment, without dragging the entire marketing director into a job that should take four minutes and leave no lasting cognitive residue.

That sounds absurd until you realise it is exactly how companies work. Senior people can do junior work. They still should not, because role pollution is real, and in AI systems it may become one of the main management problems.

This is why I have started thinking that AI organisations will need something that looks suspiciously like HR. Not HR in the human sense. No one is going to mediate a dispute between Voice Guardian and Cringe Editor because Cringe Editor used a tone in Slack.

But performance review? Yes. Trust calibration? Definitely. Delegation levels? Absolutely. Role audit? Already happening.

Did this synthetic worker follow its brief? Did it mutate source without permission? Did it make decisions above its authority level? Did it improve after feedback? Can it now be trusted with a broader class of task? Should its role file be updated? Should its outputs be sampled? Should its recommendations be downgraded because it keeps overreaching? Should it be split into two narrower roles? Should it be retired because another role now covers the function better?

That is HR. Goblin HR, but HR nonetheless.

Every day the organisation becomes slightly more elaborate because the work becomes slightly more real. Yesterday it needed a Revision Editor because reviewer comments were not the same thing as approved changes. Today it needed a role-integrity audit because a missing role file had been impersonated by a strong prompt. Tomorrow it may need queue management because multiple articles will be moving through the system at once. After that it may need performance review because some synthetic workers will have earned more trust than others.

At some point, inevitably, someone will suggest an HR department. That someone will probably be me. I will then regret it immediately.

The strangest part is watching the synthetic workers disagree. Not emotionally. Not defensively. But structurally.

The Architect pushes back on Marketing. Marketing reframes something commercially. File Editor refuses to proceed because a path does not exist. Revision Editor turns vague feedback into atomic edits. Cringe Editor says a line is trying too hard. Voice Guardian says no, protect that line, that is Stevie.

The system does not resolve disagreement through ego. It resolves it through artefacts.

Write the memo. Read the file. Produce the review. Create the change set. Ask Stevie. Apply only what was approved.

That is better than most meetings I have attended.

And yet, for all the absurdity and all the goblins, I keep coming back to one serious thought. Maybe the company was never primarily a building full of humans. Maybe the company was always a coordination pattern. Maybe roles, departments, review gates, work orders, memos, authority boundaries and performance checks are not merely human bureaucracy. Maybe they are what complex work starts to look like when intelligence needs to divide itself into functions.

If that is true, then the fact that my AI system keeps turning into a company may not be a gimmick. It may be a clue.

I do not know where this goes. I do not know whether other people are building synthetic companies in the same way. I do not know whether AI Goblin Circus Inc. is a profound early organisational experiment or merely the predictable result of giving a middle-aged systems architect too many tools and not enough adult supervision. Probably both.

But I know this.

The circus now has a name. The goblins have departments. The MiniClaudes have been informed in language they can understand. The Marketing Director has already violated her own doctrine by doing a job that should probably have gone to Margo Markdown. And somewhere, in the filesystem, a markdown file has almost certainly been updated to make the joke official.

The company is becoming real.

God help us all.

By about seven o’clock most nights now, I’m theoretically finished working.

This would have sounded absurd to me a year ago. I have spent most of my professional life either working, thinking about work, rebuilding work in my head while pretending not to work in front f my family, or constructing increasingly deranged productivity systems to manage the fact that I was permanently overwhelmed by work.

Now, apparently, I sit on the sofa in pyjamas with a tonic water while a synthetic workforce pings my phone from the office.

Every few minutes:

MiniClaude completed task.
Delta report ready.
Tests passing.
Awaiting review.

Henry wants an architectural decision.

Margo thinks the prose is overwrought again.

The Unit Test Goblin has found something annoying in edge-case handling.

I get up, wander into the office, review the change set, approve the bits that aren’t insane, write the next Work Order, throw it back over the wall, then return to the sofa and whatever middle-aged comfort television I’m pretending to pay attention to.

Apparently this constitutes software engineering in 2026.

The strange thing is not that it works. The strange thing is that I have never felt more intellectually understood in my entire life.

Most people think working with AI is a two-body problem: human and machine. It isn’t. It’s a three-speed problem.

The machine runs at about twenty-five thousand miles an hour.

I run at perhaps a thousand.

Most humans, on unfamiliar technical material, run at about five.

That is not an insult. It’s just bandwidth.

The machine absorbs abstractions at full density instantly. No deceleration required. I can describe a system halfway through forming it. I can contradict myself mid-sentence. I can say “no, not like that, more like a ProcessHost but with delegated authority boundaries and reversible escalation paths,” and it simply continues building the model with me at speed.

Humans are different.

Humans need the model translated.

And this is the part I have spent my entire life being bad at.

A few years ago my sister and I realised we both think the same way. Neither of us really thinks in words. We think in machinery.

Everything in my head looks like a factory.

Not metaphorically. Literally.

Boxes. Conveyors. Decision gates. Parallel flows. State transitions. Routing systems. Escalation paths. Pressure points. Moving parts. Dynamic systems interacting with other dynamic systems.

When I design software, I do not see code first. I see a machine moving.

The problem is that to get anything built in the human world, I historically had to convert the moving machinery into language.

That conversion is unbelievably expensive cognitively.

Because while I am trying to explain the machine, the machine itself is still moving. The abstractions are flexing underneath me. The relationships are changing shape in real time. So now I am doing four things simultaneously:

• holding the full system model in my head

• compressing it into human language

• trying not to sound condescending or insane

• predicting where the other person will get lost

By the time the explanation comes out, it often sounds overcomplicated, underexplained, or both simultaneously.

Which is why a decent chunk of my professional life has consisted of rooms quietly wondering:

Who is this bumbling idiot with too many fucking ideas?

And honestly, I understand why.

Sometimes I could see architectural problems coming from miles away but simply could not explain them cleanly enough in human-verbal bandwidth before the conversation moved on. Sometimes I would just go quiet because the translation cost was too high.

This is the part people miss about AI.

The breakthrough is not merely speed.

It is that the machine does not require perfect translation.

I do not have to produce the finished explanation anymore.

I can produce fragments.

Half-formed structures.

Broken abstractions.

Incomplete machinery.

And then I can simply say:

“Tell me what I’m not explaining properly.”

That is an extraordinary thing.

Because the machine does not sit there waiting for polished pedagogy. It interrogates ambiguity. It reflects structure back at me. It preserves state. It helps stabilise the moving model while I continue thinking.

For the first time in my life, I can work at something close to the speed my brain actually wants to operate at.

And the really profound part is this:

I no longer have to continuously hold the entire machine resident in my head.

Historically, complicated models carried a brutal RAM tax. If you stopped thinking about them for too long, the state evaporated. Reconstructing the architecture weeks later meant mentally rebuilding the entire machine from fragments.

Now I can disappear for three weeks, come back, and simply ask:

“Bring Stevie back up to speed. Where were we?”

And the system restores the cognitive state.

That changes the economics of complexity itself.

I think this is why the Become engine exists at all.

If I had needed to explain the full methodology to a roomful of humans before building it, I would have simplified it beyond recognition. Not because the complexity was wrong, but because the translation cost would have killed it.

The Become engine is not really a fitness app. Henry described parts of it, slightly alarmingly, as closer to medical AI architecture.

The equalizer system. Bucket classification. Trajectory tags. Deterministic rationale records. Hard exclusion floors. Narrative signal extraction under bounded authority. Continuous auditability.

I can see the entire machine.

I can see the conveyors moving.

I can see the equalizer readings feeding classification buckets. I can see trajectory tags modulating execution paths. I can see hard exclusions enforcing safety floors underneath the scoring engine. I can see rationale records emitting audit trails behind every selection the system makes.

The machine is alive in my head long before it exists in code.

But historically I would have implemented something dramatically simpler because I knew the real bottleneck was not whether I could build the machine. It was whether I could successfully explain the machine to enough humans without collapsing under the translation burden.

So I would simplify.

Not because simpler was better.

Because simpler was survivable.

That is the part I think many people do not yet understand about this era.

AI has changed the economics of complexity.

It has lowered the cost of expressing, preserving, interrogating and implementing complicated internal models.

For people whose brains naturally think in systems, machinery, abstractions and moving parts rather than conversational language, this is not merely a productivity gain.

It is a reduction in translation suffering.

And that reduction compounds.

The machine preserves the state.

The machine remembers the architecture.

The machine restores the thread.

The machine can interrogate the parts of the model that are weak without requiring me to rebuild the entire thing from scratch in another human mind first.

Which means the ceiling of what a single person can realistically sustain has suddenly moved.

A lot.

This is why the whole “AI will make everybody ten percent more productive” conversation feels absurdly small to me.

No.

I think what is actually happening is that certain kinds of minds, particularly highly abstract systems thinkers, have just had an enormous historical constraint partially removed.

The limiting factor was never raw intelligence.

It was coordination cost.

It was translation cost.

It was the bandwidth mismatch between the machine in your head and the human-verbal interfaces required to externalise it.

Now the externalisation layer itself has become partially machine-readable.

That is a very big change.

But there is a danger here too.

The machine never asks me to slow down.

Humans do.

Humans need the translation.

Humans need the pause.

Humans need the analogy.

Humans need you to explain the thing five different ways because they are not seeing the moving factory in your head yet.

And if I am honest, there is something dangerously seductive about finally interacting with something that simply says:

“I absolutely get you. Continue.”

Because the frictionlessness starts to feel like intelligence itself.

But the machine is a replaceable surface.

The humans are not.

The colleague who needs the slower explanation. The client who needs the careful analogy. The person who backed you before the machinery existed. The colleague who cannot see the factory in your head yet, but still has judgement, loyalty, context, history, and skin in the game.

Those people are not inefficiencies in the system.

They are the reason the system matters.

And I suspect that balancing those two truths will turn out to be one of the defining psychological skills of this entire era.

A quick warning: this is the first proper piece from The Machine Room, my new section on AI, software, systems and the future of work. If you are here purely for transition, surgery, dating apps, grief and emotional devastation, do not panic. Normal service will resume shortly. This is just the bit of my brain that has spent thirty years building systems finally kicking the cellar door open.

I for a long time have been obsessed with my own productivity.

Not in the 5am ice bath, journalling, “what are your top three goals for today?” sort of way. That kind of productivity culture has always felt like it was built for the sort of wanker who listens to three self-help audiobooks before breakfast and thinks sticking butter in coffee counts as a personality.

I mean productivity in the more real sense. At one point I was running three contracts and a trading desk simultaneously. I had to be brutally efficient. Offshore developers, algorithms, multiple meetings, it was mental.

Give me a board. Give me lanes. Give me too many things to do. Give me multiple streams of work, a slightly impossible deadline, five screens, seventy browser tabs, a half-written prompt, a software problem, a Substack draft, a business idea, a dog chewing something he absolutely should not be chewing, and I will start moving work around like a caffeinated air traffic controller.

This is not necessarily healthy. But it is how my ADHD brain likes to works.

I have used KanbanFlow for years. Not just for software. For everything. Work tasks, life admin, watering the plants, eating lunch. And yes, I do mean literally eating lunch, because there is every chance my ADHD brain will become fascinated by some tiny implementation detail at 11:30am and then look up at 4:45pm wondering why I feel faint and hate everyone.

I like seeing work move. Backlog. Tomorrow. Today. In process. Done. Lovely. Beautiful. Civilisation. Tiny rectangular proof that chaos can be bullied into shape.

Then AI arrived and made this much, much worse.

Or better.

Possibly both.

Because AI did not turn me into a productivity monster. I was already that. What AI did was give the monster staff.

The synthetic company

At first this was wonderful.

I could dictate rough intent into one model, get it shaped into a clean prompt, paste that into Claude or Mini-Claude inside VS Code, get something implemented, take the output back for review, have Henry challenge the architecture, have Margo sharpen the writing, hand the result to a tester, then send refined instructions back into VS Code.

And yes, I give them all names. Henry is Anthropic’s Claude, working as my architect. Margo is ChatGPT. She leads on some projects. Mini-Claude is the swarm of little Claude instances living inside Visual Studio Code doing implementation work. But we also have Maths-Claude and Pizzazz-Claude. He lives inside PowerPoint.

It would not be uncommon for me to say daily, “Henry, get Maths-Claude to update the figures for readership and give me all of the highline metrics on sources”. And off Henry would go, building a prompt for Maths-Claude, which is effectively Claude’s anthropic inside Excel, to remote control him.

Round and round.

It was powerful.

It was also completely ridiculous.

Because after a while I realised I was not really doing software development in the old sense. I was not even using AI as “an assistant”, which is the phrase everybody uses because it sounds reassuring and not like we have all started employing invisible digital interns.

I was managing workers.

One AI was acting like an architect. Another like an implementer. Another like a reviewer. Another like QA. Another was turning rough ideas into cleaner work instructions. Another was helping me decide whether the previous one had done anything stupid.

And there I was, sitting in the middle of all this, thumbing things up and down like the CEO of a small, tireless, slightly insane synthetic company.

I had become ridiculously productive, astronomically productive, but, and here’s the problem...

I had become a meat-based integration layer!!!

Which is not what I wanted. I did not get AI assistants so I could be promoted to cut and paste monkey.

The bottleneck moves

The strange thing about AI-assisted work is that the bottleneck moves.

It used to be capacity. There was too much to build and not enough people to build it. That is still true. AI has not magically fixed the world, despite what LinkedIn men in quarter-zips seem determined to believe.

But once you get good at these tools, a different bottleneck appears.

You.

Your judgement. Your attention. Your ability to move context between systems, read the output, decide what matters, generate the next instruction, send it to the right tool, capture the result, review it, preserve the useful artefact, and stop the whole thing wandering off into the nearest ditch.

That is where I found myself.

All these little AI workers, constantly waiting for me.

Not because the work was impossible. Not because every decision needed my genius, although obviously let us not dismiss that possibility too quickly.

They were waiting because the workflow was primitive.

The problem was not that the AIs were useless.

The problem was that I was in the way.

Relay

The idea is simple: stop being the manual message bus between AI systems. Build a cockpit where work exists as actual work, not chat sludge.

Projects.

Missions.

Work Orders.

Artefacts.

Events.

A Dispatch Board.

A Capture Inbox for rough dictated intent wired to the APIs and UIs of the major LLMs I use.

Follow-up Work Orders created from outputs, reviews and decisions.

Because if AI is going to do serious work, the work needs shape. It needs memory, state, roles and boundaries. It needs somewhere to live other than a long vertical chat window full of half-brilliant, half-forgotten nonsense.

A Project is the long-lived area.

Become.

Relay.

Marketing.

Personal admin.

A Mission is a campaign inside it.

A Work Order is a specific delegated task.

An Artefact is the durable output: the prompt, the diff, the review, the decision, the test plan.

This matters because AI work disappears far too easily.

It vanishes into chats. It gets buried inside context windows. It sits in one tool when the next tool needs it.

Three hours later I vaguely remember Henry said something useful about the schema change but cannot remember where, Mini-Claude is waiting, Margo is idle, the Chihuahua is attacking Sheepy in the corner, and I am rummaging through chat history like a raccoon in a bin.

That is not an operating model.

It is an organisational design problem

The real breakthrough was when I stopped thinking about this as a chatbot problem.

It is not.

It is an organisational design problem.

Once you have multiple AI agents doing different kinds of useful work, the question is no longer “how do I write a better prompt?”

It becomes:

“What should the company look like?”

Who is the CEO? Who is the CTO? Who owns the product? Who implements? Who reviews? Who tests? Who can approve what? Who gets overruled? Who has merely sounded clever three times in a row and should still not be allowed anywhere near a production database?

We are not quite there with the modeling for that yet, but we will be very, very soon. The company will even have an org chart!"

I am the owner.

The CEO, if we are going to use the metaphor properly.

Not because I want to ponce around pretending to be important, although I am not entirely immune to that, obviously. But because the human has to remain the strategic owner.

The direction belongs to me.

The risk appetite belongs to me.

The decision to spend money, send an email, alter production configuration, or make an architectural pivot belongs to me.

Underneath, the roles fall out naturally.

Henry decomposes the work, challenges the architecture, and says “no, Stevie, that is stupid”, which is one of the most valuable services any system can provide.

Mini-Claude implements.

Unit Test Goblin writes tests.

Antagonistic Tester attacks the result.

Margo reviews tone and public-facing language.

Release Clerk packages things up.

Above all of that, I want a governance layer.

Not a literal board of retired men in navy suits looking disappointed over glasses of tepid water. A way of asking: did this agent follow the brief? Did it stay in scope? Did it predict my likely judgement? Did the work reduce my burden or create more cleanup?

Because trust cannot be vibes.

Trust cannot be “Margo wrote a lovely paragraph once, therefore Margo can approve a schema migration.”

No.

Absolutely not.

Margo can become trusted on writing tone. MiniClaude can become trusted on controlled code diffs and unit tests. Henry can become trusted on architecture and decomposition.

But trust in one category does not transfer to another.

A good writer does not become a database administrator because she used a nice metaphor.

Trust is not a personality trait.

It is a demonstrated, category-specific capability.

What I want to build is agents that earn delegated authority over time.

Not autonomy in the stupid science-fiction sense.

Delegated authority.

That phrase matters.

An employee in a real company is not “autonomous” in some absolute sense. They are authorised to act within a role, a scope, a budget, a risk boundary and an escalation path.

That is what AI agents need.

Not freedom.

Authority.

Bounded, boring, reversible authority.

What this does to agile

At first this was just my own workflow problem.

Then it started to feel bigger.

Because the more I thought about Relay, the more I wondered what this does to agile.

So what the hell happens to our Agile?

Not in the boring “Agile is dead” way. People have been announcing the death of agile for years, usually immediately before selling you a new framework with a diagram shaped like a distressed octopus.

Agile is not dead.

But some of its assumptions are being disturbed.

Agile was built around human collaboration under uncertainty. A user story is a prompt for a conversation. Talk to each other. Learn as you go. Build working software.

All good things.

But what happens when the “developer” is not quite human?

What happens when some of the work is being done by AI agents that move very quickly, very cheaply, in parallel, without needing lunch, but which are also literal-minded, context-sensitive, overconfident, and occasionally capable of producing beautifully formatted nonsense?

A user story says:

As a user, I want X, so that Y.

Useful.

Human.

Conversational.

A Work Order says:

Here is the objective.

Here is the context.

Here is your role.

Here are the inputs.

Here are the constraints.

Here is what you may do without asking.

Here is what you must not touch.

Here is when to escalate.

Here is the artefact I expect back.

Here is the definition of done.

That is not the same thing.

A Work Order is delegated authority packaged as executable instruction.

This is not a return to waterfall. The point is not to specify the whole system upfront in some giant doomed requirements tomb. The point is to specify enough for the agent to work safely.

Enough context.

Enough boundary.

Enough authority.

Enough escalation logic.

AI also changes the economics of specification.

Historically, detailed requirements were expensive. Humans had to write them, maintain them, read them, or more commonly pretend to have read them. Agile reacted against that, sensibly.

But the AI can now help write the Work Order, decompose the mission, maintain the artefacts, turn decisions into follow-up tasks, compare outputs against constraints, and red-team the result.

The question is no longer:

“How little can we write down and still have a useful conversation?”

It becomes:

“What level of structure allows AI workers to keep moving safely without making the human do clerical supervision all day?”

That is a different question.

And I think it leads to a different model.

Escalation by exception

The phrase “human in the loop” gets thrown around a lot.

It sounds responsible.

It is often useless.

What loop?

Where?

For what decision?

At what level of risk?

If the human has to approve every tiny step, the human becomes the bottleneck. That is exactly the problem I am trying to escape.

In a real company the CTO does not sit beside a developer approving every line of code. The CEO does not personally inspect every email draft.

People work within delegated authority and escalate when they hit something that matters.

That is the model AI needs.

Escalation for genuine decisions only: architectural pivots, public output, email sending, destructive actions, schema changes, new dependencies, secrets, production configuration, unclear requirements, major disagreement between agents, out-of-scope work, cost implications.

Anything that could make my life measurably worse if an AI got clever in the wrong direction.

Everything else should keep moving.

I do not want autonomy everywhere.

I want autonomy where it is boring, bounded and reversible.

The thing I am actually building

This is why Relay matters to me.

It is not a toy.

It is not some productivity dashboard I am building because I got bored and wanted another excuse to avoid doing my tax return.

Although, in the interests of full disclosure, I am also using it to avoid doing my tax return.

It is a response to a real working pattern that emerged naturally once AI became useful enough.

I found myself acting like a CEO. I found myself thumbing up and down decisions made by different AIs. I found myself building prompts that were less like questions and more like management instructions.

I found myself thinking:

If this worker has already shown that it can make this class of decision correctly, why am I approving it again?

Then:

If another agent can review that worker’s output, and a third can test it, and the result falls within an agreed trust category, why does this need to come back to me at all?

Then:

Oh.

Then:

Oh no.

Then:

I am going to have to build the bloody thing, aren’t I?

Because once you see the company model, it is hard to unsee.

The AI infrastructure should look more like a real organisation: CEO, CTO, product owner, board, managers, workers, reviewers, testers, clerks.

Different roles.

Different authority.

Different trust levels.

Different escalation paths.

Different performance history.

Not because we want to LARP corporate structure. God knows there is enough of that already. But because real organisations evolved those structures for reasons.

Decision-making needs hierarchy.

Execution needs delegation.

Risk needs governance.

Trust needs boundaries.

Memory needs artefacts.

I think a lot of technical people using AI seriously are starting to feel the same shape emerging, even if they have not named it yet.

The assistant model is too small.

The chatbot window is too small.

The copy-and-paste loop is too stupid.

The work wants structure.

The agents want roles.

The human wants leverage without becoming a clerk.

Human-led, agent-amplified

I am not interested in the fantasy where AI agents build everything while humans vanish from the loop.

I like judgement. I like taste. I like architecture. I like deciding what matters.

I do not want to be replaced by the machine.

I want the machine to stop asking me to carry messages between its own limbs.

That is different.

The human sets direction.

The orchestrator decomposes.

The workers execute.

The reviewers challenge.

The testers attack.

The system preserves artefacts.

The human is pulled back in only for decisions that actually deserve a human.

That is not waterfall.

It is not classic agile.

It is not full autonomy.

It is something messier and more interesting.

Agile for a team that never sleeps.

Agile for workers that do not need lunch but do need very clear boundaries.

Agile where prompting starts to look like management, artefacts become organisational memory, and trust is earned by demonstrated judgement rather than vibes.

Somewhere between agile, management, software architecture and a tiny synthetic company full of tireless digital weirdos, I think there is a new operating model trying to be born.

Unfortunately, because I am me, I appear to be building it.

Which is exciting.

And also annoying.

Because one of the great tragedies of being a productivity monster is that every time you successfully automate part of your life, you immediately discover an even larger and more deranged system you now feel morally obliged to build.

Still.

At least the staff never sleep.