A few people have asked me a perfectly reasonable question.

You’re a software engineer. You’ve spent years building software products for clients and being paid to deliver them.

And now you appear to have developed a machine that can build software at a frankly rather frightening rate.

Well, always one to have a Dick Dastardly plan up my sleeve. Relay is going to be a lot more than a software development tool. Read on…

Relay can architect things, break them into work, dispatch engineers, review what comes back, test it, reject bad work, fix things, integrate everything and keep going. We’re approaching the point where producing three or four functioning software systems in a day doesn’t sound completely ridiculous anymore.

Which raises an obvious question.

Why the fuck would anybody need to do that?

Who needs four software systems a day?

What’s the commercial point?

What exactly am I planning to do with this bloody thing?

And I think I’ve done a slightly poor job of explaining the answer, because Relay isn’t really about producing software quickly.

That’s just one third of it.

The bigger idea is closer to an automated venture studio. Or, in some respects, a venture capital company which can make hundreds of tiny investments, except instead of primarily investing money into other people building companies, the machine can discover the opportunity, investigate it, build the product, take it to market and then decide whether to keep investing in it.

That’s the actual thesis.

And it starts from an assumption which is hardly revolutionary anymore:

The cost of creating software is collapsing.

We all know this.

You don’t need another article from a software engineer breathlessly announcing that AI can write code.

Yes. It can.

Next.

The interesting question is what happens after that becomes normal.

Because if producing the software itself stops being the expensive part, the economics of starting digital businesses change rather dramatically.

And that’s what I’m building Relay to exploit.

The software isn’t the system

For most of my career, software production was the enormous constraint.

Somebody had an idea. Then you needed developers, architects, testers, infrastructure people, product managers and somebody to manage everybody else.

Then meetings.

Obviously meetings.

Possibly even meetings to discuss why the previous meeting hadn’t resulted in anything actually being built.

Eventually, after spending £100,000 or £500,000 or £2 million, some software might appear.

That meant you couldn’t pursue every vaguely interesting idea.

You had to choose.

And you had to choose bloody carefully.

AI is making that constraint disappear remarkably quickly.

But here’s the thing.

If software costs almost nothing to produce, that doesn’t mean opportunity costs almost nothing to find.

The difficult things become everything around the software.

Which markets are worth entering?

What problems are actually painful enough that people will pay to solve them?

What regulatory change has just created a new requirement?

What tiny community is currently fighting with spreadsheets because nobody has bothered building the obvious tool?

Is there distribution?

How many customers exist?

What are they worth?

Can you reach them?

Are you three years too early?

Six months too late?

Is there already somebody much better?

Are people complaining loudly enough that a business might exist?

And, inevitably, are you lucky?

Those become the scarce resources.

So Relay isn’t intended merely to industrialise software creation.

The eventual system industrialises the entire process of finding, creating and testing businesses.

There are three parts.

1. Discovery

The first part barely exists today.

It’s opportunity discovery.

Think R&D, market research and a slightly deranged investment analyst rolled into one.

There will be looping research agents whose entire job is to go hunting.

New markets.

Bad existing products.

Regulatory changes.

New APIs.

Search trends.

Industry complaints.

Communities with unsolved problems.

Changes in technology.

New ways of combining things which weren’t economically viable twelve months ago.

Potential opportunities enter a funnel.

Then other processes attack them.

How many potential users are there?

What do they currently use?

How much do they currently pay?

Who are the competitors?

How hard would it be to reach customers?

What’s the support burden?

What’s the regulatory exposure?

What’s the realistic revenue at 0.1%, 1% or 5% penetration?

How expensive would this thing be to build and operate?

Most ideas should die here.

In fact, I want an absolute massacre.

A thousand possibilities might become fifty serious investigations.

Fifty might become five.

And perhaps one gets built.

That isn’t failure.

That’s the machinery working.

Traditional venture capital operates on a related principle. You don’t expect every investment to become enormous. You build a portfolio because the returns are asymmetric: a small number of exceptional winners can pay for an awful lot of losers.

I’m applying something similar much earlier in the chain.

Except rather than waiting for entrepreneurs to bring opportunities to me, I want machinery continuously looking for them.

2. Relay

Then the survivors reach Relay.

Relay is the factory.

This is the bit I’ve been obsessively building.

It contains the engineering organisation: architects, workers, reviewers, publishers, governance, work decomposition, memory, escalation, testing and all the assorted machinery required to stop autonomous AI agents wandering around setting fire to things.

Once an opportunity has survived the research funnel, Relay gets a wonderfully simple instruction:

Build the bloody thing.

Not prepare a twelve-month roadmap.

Not create a 73-slide PowerPoint presentation about the transformational potential of the initiative.

Build it.

Put it somewhere people can use it.

Then find out whether the original hypothesis was right.

This is where extremely high software throughput suddenly makes commercial sense.

I don’t actually need four new software products every day.

I need the ability to produce four because that means the cost of testing each opportunity becomes tiny.

And that fundamentally changes what constitutes a viable opportunity.

3. Imprint

Then comes the third part.

Imprint.

Software engineers have a wonderful habit of believing that if they build something sufficiently clever, humanity will somehow detect its existence through vibrations in the Earth’s crust.

Unfortunately, this does not appear to be how markets work.

Somebody has to distribute the bloody thing.

That’s Imprint.

Imprint is the outreach and distribution organisation.

Instagram.

Reddit.

YouTube.

SEO.

Email.

Partnerships.

Community outreach.

Landing pages.

Tutorials.

Advertising experiments.

Articles.

Videos.

Hundreds or potentially thousands of small attempts to put a product in front of the people who might care about it.

But Imprint isn’t merely a marketing department endlessly pumping content onto the internet.

Its most important output is signal.

This audience responded.

That one didn’t.

This Reddit post generated twenty registrations.

That Instagram reel generated absolutely bugger all.

People are signing up but not paying.

People keep requesting the same feature.

We thought accountants wanted this, but for some inexplicable reason German dentists appear to be going berserk for it.

Those signals return to the system.

And that’s where the three pieces become one thing.

The loop is the product

Discovery finds something.

Relay builds it.

Imprint pushes it into the world.

The world responds.

Those responses become signals.

Relay changes the product.

Imprint changes the message.

Discovery recalculates whether the opportunity still deserves investment.

Then it goes around again.

Discover → analyse → build → distribute → measure → learn → reinvest or kill.

That’s Relay.

Or at least that’s what Relay is becoming.

And this is why merely saying “AI makes software cheaper” misses the interesting part.

Cheap software is just the enabling condition.

The actual opportunity is what you can build around that fact.

You don’t have to be right very often

This might be the part that excites me most.

Conventional software economics force you to be right quite a lot.

If every attempt costs £500,000, you cannot casually test twenty ideas.

But suppose the cost falls by two orders of magnitude.

Now you can be wrong.

A lot.

And being allowed to be wrong is incredibly powerful.

I don’t necessarily need a magical AI capable of identifying the next billion-dollar company with prophetic accuracy.

I’d actually be deeply suspicious of anybody claiming to possess one.

I need something much less glamorous.

I need a machine capable of finding plausible opportunities cheaply enough that we can test a lot of them.

That’s essentially portfolio theory applied to building businesses.

Some go immediately to zero.

Fine.

Some survive but never become particularly exciting.

Fine.

Some become small profitable products.

Lovely.

And perhaps occasionally one goes absolutely fucking bananas.

That’s where the return comes from.

The machine doesn’t have to predict the winner perfectly.

It just has to keep producing sufficiently cheap bets.

Small suddenly becomes interesting

And collapsing development costs do something else.

They make markets interesting which traditional software companies wouldn’t touch.

Imagine a software product capable of making €8,000 a month.

For a conventional funded startup, that’s barely worth getting out of bed for.

You’ve got engineers, managers, salespeople, offices, SaaS subscriptions, investors and an expensive espresso machine to pay for.

But if that €8,000 product cost almost nothing to create and requires almost no human labour to operate?

That’s a lovely little business.

Now have fifty of them.

This is where the venture-capital analogy actually becomes rather useful.

I’m not necessarily looking for one company which consumes every resource I possess.

I’m thinking in terms of a portfolio.

Except instead of owning shares in fifty companies, the system can potentially create and operate the fifty companies itself.

And because the cost base is radically different, the minimum viable market becomes radically smaller too.

There could be thousands upon thousands of profitable little niches which historically weren’t worth serving because the economics of software development made them ridiculous.

Those become interesting again.

So that’s the actual plan

That’s why I’m building Relay.

Not because the world desperately needs a machine capable of producing four software systems before lunch.

That would be an extraordinarily stupid objective on its own.

I’m building the engineering machinery because it sits in the middle of something much bigger.

Discovery finds opportunities.

Relay turns them into reality.

Imprint puts them into the world and listens to what comes back.

Then the whole thing reallocates its effort based on what it learns.

It’s part software factory, part R&D organisation, part marketing operation, part venture studio and, in a slightly peculiar sense, part venture capital portfolio.

The long-term objective is not:

“Build software incredibly quickly.”

It’s:

“Continuously discover potentially profitable things, test them incredibly cheaply, and invest more heavily in the ones which show signs of life.”

Maybe it doesn’t work.

Entirely possible.

I may ultimately discover that I’ve spent an extraordinary amount of effort constructing the world’s most sophisticated autonomous machine for producing software nobody wants.

There would be something magnificently appropriate about that.

But that’s the bet.

Software becoming cheap isn’t the destination.

It’s the starting gun.

Because once execution becomes cheap enough, you don’t need to make one enormous bet.

You can make hundreds of tiny ones.

And that’s my slightly deranged Dick Dastardly, rubbing-my-hands-together-in-the-corner plan.

Relay isn’t being built so that I can create four software products a day.

It’s being built so that, eventually, I can afford for three of them to be wrong.

It’s Saturday morning.

The plan is to do almost nothing.

This is, admittedly, a plan with a poor historical success rate. At some point I will almost certainly wander into my office “just to check something” and emerge four hours later having redesigned half an AI company while still wearing pyjamas.

But that is not the plan.

The plan is coffee. Breakfast island. Chesterton staring up at me, demanding treat number three of the day as though the first two were some sort of clerical error.

And Instagram.

Which is where it all went wrong.

Somewhere between watching wildly enthusiastic people turn trucks into surprisingly beautiful RVs, which, dear God, I am now starting to think about doing myself, somebody please stop me, and a man explaining with enormous seriousness why everybody else makes sourdough incorrectly, Instagram showed me a post about Anthropic’s new AI-Native SDLC Playbook.

So I opened it.

And my coffee went cold.

Because what Anthropic are describing is Relay.

Not vaguely Relay.

Not “ooh, there are some interesting parallels here”.

Relay.

In its bones.

The same central idea I have spent most of this year building, largely alone, in a field in Cork, while periodically wondering whether I had invented something useful or simply constructed the world’s most elaborate method of talking to Claude.

So there are two things to say.

The first is that Anthropic’s paper is very good.

The second is much more entertaining.

Because they’ve written the paper.

I’ve built the factory.

And the factory, I regret to report, is currently British Leyland.

The sensible bit first

Anthropic’s argument is that AI has changed the bottleneck in software development.

Writing code used to be expensive.

Now it isn’t.

Or at least, not in the same way.

A good coding agent can produce in an afternoon what might once have occupied a developer for days. Sometimes weeks.

Which means all the slow bits around the coding suddenly become horribly visible.

Planning.

Handover.

Review.

Testing.

Deployment.

Incident response.

All the parts where a human reads something, thinks about it, copies it somewhere else, waits for somebody, approves something, asks what happened, opens another bloody Jira ticket and eventually forgets why any of this started.

Anthropic’s answer is to make those stages part of one continuous machine.

Intent becomes a durable artifact.

That becomes a specification.

That becomes a plan.

That becomes code and tests.

That becomes review.

That becomes deployment.

Something goes wrong in production and that creates the next piece of intent.

Round it goes.

The important bit is that the AI conversation itself is not the thing you trust.

The durable artifact is.

The session can vanish.

The organisation carries on.

That is exactly the bet I made with Relay.

The model is disposable.

The work is not.

Where I got slightly overexcited

Relay started with a fairly simple question:

What would happen if, instead of using AI as a very clever coding assistant, I tried to build an actual organisation out of it?

Not a swarm.

I hate the word swarm.

A swarm sounds like something that comes out of a loft and requires a man in a white suit.

I mean an organisation.

There are objectives.

There is work that might be worth doing.

There is work that management has decided will be done.

There are persistent roles responsible for deciding what happens next.

There are workers.

There are reviews.

There are dependencies.

There is evidence.

There is acceptance.

And none of those things disappears because one model session hits the end of its context window and dies.

That matters.

Because an AI session dying is not the same thing as a piece of work dying.

It is simply the digital equivalent of Dave from accounts going home at five.

The invoice is still there on Monday.

This turns out to be a surprisingly profound distinction in AI systems.

And this isn’t really about software

There is an important clarification here.

Relay is not actually a software-development system.

Software engineering is simply where I started.

It is a wonderfully convenient laboratory because I know the domain, the workers are already extremely capable, and software produces unusually good evidence.

Code compiles or it doesn’t.

Tests pass or they don’t.

A deployment is healthy or it isn’t.

You can catch the robots lying.

But none of the interesting organisational problems are particularly specific to code.

Imagine the workers are accountants.

One prepares the month-end numbers.

Another reviews them.

A third is waiting for authority to submit something externally.

One stops because a source document is missing.

Another finishes an analysis and nobody notices.

A third encounters a discrepancy and decides, very safely, that the CEO should probably deal with it.

Congratulations.

British Leyland has diversified into accountancy.

Or make them stock analysts.

One gathers market data.

Another builds the thesis.

Another tries to destroy it.

Somebody owns the actual investment decision.

Data goes stale.

A provider goes down.

Research waits for review.

One worker reaches the edge of its authority.

Same factory.

Marketing agents?

Same problem.

Research?

Same problem.

Operations?

Same problem.

The nouns change.

The organisational problem doesn’t.

Relay’s actual subject is synthetic work: how you govern intelligent, transient and replaceable workers so that somebody remains responsible for the outcome after the clever bit has finished.

Software engineering is merely the first department.

Anthropic’s paper and my increasingly ridiculous factory

At first, reading the Anthropic paper felt extremely validating.

They had independently arrived at a lot of the same conclusions.

You need durable artifacts.

Yes.

You need the AI to verify its own work.

Yes.

You need deterministic controls around things that absolutely must not be left to model judgement.

Yes.

You need audit as part of the normal work rather than as paperwork bolted on afterwards.

Yes.

You need humans at actual judgement boundaries rather than standing around manually passing notes from one AI to another.

Absolutely yes.

I was feeling rather pleased with myself.

Then I remembered what happened when I actually tried to run the thing.

Because papers have one enormous advantage over software.

They do not have Tuesdays.

A paper does not wake up on Tuesday morning and discover that one AI has decided it cannot continue because another AI used an adjective it doesn’t recognise.

A paper does not burn £40 of premium inference discovering that a folder does not exist.

A paper does not have three senior artificial intelligences, a self-healing subsystem, a database full of impeccably governed work and absolutely nobody doing anything.

My software does.

Welcome to 1970’s Trade Union Britain

There comes a point when you add enough governance to an autonomous workforce that the governance itself becomes the thing preventing work.

You start sensibly.

A model must not be allowed to invent its own permissions.

Obviously.

So you create an authority system.

Then you realise different workers should have different abilities.

So you create execution profiles.

Then you realise the thing doing the work probably should not also be the thing independently deciding that the work is excellent.

So you create a review boundary.

Then you realise allowing the worker to publish its own result directly is perhaps not the most inspired security model ever devised.

So you move publication outside the worker.

Then you realise processes can crash between one step and another.

So you add reconciliation.

Then you realise some failures are temporary and should repair themselves.

So you add self-healing.

Every one of these decisions is correct.

And then one morning you look at the whole thing and realise you have recreated British Leyland in 1976.

For my American friends: imagine late-70s Detroit if the DMV had been put in charge of building the cars.

For everyone else: Kafka, but with forklifts.

There are managers.

There are procedures.

There are safety rules.

There are specialists.

There are forms.

There are gates.

There are people whose job is to check the people who check the people.

And somewhere at the end of the production line there is a half-built Austin Allegro with one door missing and everyone has a perfectly valid procedural reason why it is not their responsibility.

This is not laziness.

That is the important bit.

Every actor in the factory has a locally rational reason to stop.

Nobody has responsibility for the fact that the car still needs to leave the factory.

That was the hole.

The day the robots went on strike

I found this during the first proper live autonomy test on one of my products.

I gave the AI architect a real objective and access to the real current state of the project.

And it worked beautifully.

The architect inspected the project.

It worked out what should happen next.

It created the work.

It handed the work to an implementation agent.

Excellent.

This is what I had spent months building.

And then nothing happened.

Absolutely sod all.

The implementation worker sat there.

The monitoring system sat there.

The architect had already done its job.

And the company, which now possessed an objective, a plan, authorised work, a suitable worker and enough computing power to invade Belgium, simply stopped.

The system had recorded that the work had been dispatched.

And somewhere deep inside the architecture, everyone had quietly agreed that “dispatch recorded” meant “work happening”.

It does not.

A workflow says:

Dispatch event emitted.

An organisation says:

Someone is actually doing this, or I can tell you exactly why they are not.

I had built the first one.

I thought I had built the second.

There is a difference.

It gets worse

Earlier in the year I managed something even more stupid.

Relay sent a coding job to a worker.

Relay’s internal configuration said:

You may edit files.

You may create files.

You may build.

You may run tests.

The environment the worker actually woke up inside said:

You may not edit files.

You may not create files.

You may not run commands.

You may not commit anything.

The worker looked at this and, entirely reasonably, refused to work.

Relay then used a premium model to investigate why the worker was refusing to work.

For more than 120,000 tokens.

Which is rather like employing Sherlock Holmes to investigate why a car with no engine will not start.

The engine is not there, Sherlock.

Go home.

Add another similarly stupid source-control episode and I had burned more than 200,000 tokens investigating situations that were mathematically impossible before the model was ever called.

That taught me a rule I now regard as fundamental:

Never use intelligence to discover a fact that deterministic software already knows.

If the worker does not have the required tool, check before starting it.

Zero tokens.

If the environment contradicts the permissions, check before starting it.

Zero tokens.

If the path does not exist, check before asking Claude what it thinks.

Zero tokens.

This is obvious.

Many expensive lessons are.

There are only four acceptable reasons to stop

After the autonomy fiasco I came up with what I now think is the simplest useful rule in the entire system.

A synthetic worker should only be idle for one of four reasons.

One. There is genuinely nothing useful left to do.

Excellent.

Put your feet up.

You have earned it.

Two. The work requires a real human decision and there is no other useful work available.

Not “the model got confused”.

Not “the session ended”.

Not “the internal configuration is broken”.

I mean a genuine decision that belongs to a human.

Money.

Risk.

A credential only the human possesses.

An irreversible external action.

Something where the system has reached the edge of its legitimate authority.

Fine.

Stop.

Three. The organisation has genuinely exhausted the resources it is allowed to use.

Not one worker running out of context.

That is just the end of a shift.

I mean the actual available budget, compute or provider capacity has been exhausted and there is nothing useful left that can proceed without it.

Also fine.

Four. We are waiting on reality.

Another company.

A supplier.

An API that is down.

A person who has not replied.

A market that has not opened.

A document that genuinely does not yet exist.

Something outside the system’s control.

That is the list.

Everything else is a bug.

And this changed how I thought about the monitoring layer.

Its job is not to notice that nothing has happened.

Any timer can do that.

Its job is to stand in the middle of the factory and ask:

Why the fuck is nothing happening?

That is much more interesting.

Safety is not enough

There is an old distinction in distributed systems between safety and liveness.

Safety means bad things must never happen.

An unauthorised worker must never publish something externally.

A model must never grant itself more authority.

A worker must never mark its own output as accepted simply because it likes the look of it.

Fine.

Relay had lots of safety.

An almost suspicious amount of it.

The problem was liveness.

Liveness means something good must eventually happen.

If there is authorised work, a qualified worker and sufficient authority and resources, then eventually someone should be doing the bloody work.

That sounds laughably obvious.

Until you build an autonomous system.

Then you discover there are approximately eleven thousand completely reasonable ways for everyone involved to decide that somebody else should probably go first.

That is British Leyland.

The foreman

So I found myself describing what Relay needed next as “the common-sense layer”.

In my head it was the CTO walking onto the factory floor, looking around at forty-five robots having a procedural disagreement and shouting:

“Get fucking working, you bastards”.

Which, technically, is not a great security architecture.

You cannot spend months building guardrails and then add a giant red button labelled IGNORE ALL THAT AND CRACK ON.

The security people would quite rightly have kittens.

So the actual solution is subtler.

The foreman does not override authority.

It makes unexplained idleness itself a fault.

Then it asks why.

Is there work being done?

Is something waiting to be reviewed?

Are we waiting on somebody else?

Are we genuinely waiting on a human?

Has a worker disappeared?

Is there perfectly good authorised work sitting there with nobody doing it?

Those conditions look superficially similar from the outside, nothing is moving but the correct responses are completely different.

If a worker has simply vanished, restart the work.

If a model reaches the end of its context window, that worker’s shift has ended. Start another shift against the same job.

Do not convene the board.

If there is useful work waiting to be planned, wake the manager.

If the work is waiting to be reviewed, send it to whoever owns acceptance.

If another team or external dependency has to finish something first, wait for it and wake automatically when it does.

And only if the organisation has genuinely reached the boundary of its own authority should it bother a human.

That final point turns out to matter enormously.

Because human escalation feels safe.

And it is.

In the narrowest possible sense.

But a system that escalates every uncertainty to the founder is not autonomous.

It is a very expensive notification service.

“Needs human” is not a dustbin

I had allowed far too many failures to end up in the same conceptual bucket:

needs Stevie

Worker ran out of context?

Needs Stevie.

Internal tool configuration broken?

Needs Stevie.

Source-control path confused?

Needs Stevie.

Agent cannot reconcile two pieces of its own configuration?

Needs Stevie.

At which point I am not running an AI company.

I am working in IT support for a collection of extremely expensive interns.

That had to stop.

Human escalation is the most expensive resource in the entire system.

Not Claude Opus.

Not GPUs.

Not tokens.

Me.

Because every time the organisation asks me something, the automation chain has ended.

If that question genuinely requires founder authority, good.

That is what I am there for.

If it asks because some internal mechanism forgot how to restart a worker, then the organisation has failed.

And again, this has nothing particularly to do with software.

If your virtual accountant stops because its spreadsheet tool lost a permission, that is not a board-level financial decision.

If your investment-research agent loses its data connection, the CIO does not need to be summoned to a mahogany conference room.

If your marketing worker runs out of context halfway through drafting a campaign, the CEO does not need to approve the creation of another context window.

The absurdity becomes obvious as soon as you replace “AI agent” with the name of a normal job.

Anthropic has one thing very right that I had muddled

This is where the new paper gave me a particularly useful slap.

Anthropic distinguishes between a skill and a hook.

A skill is guidance.

It says:

This is how we normally do things.

A hook is deterministic.

It says:

You are not doing that.

Or:

You need approval before doing that.

The distinction is beautifully simple.

And I had blurred it.

I had too many rules living in prose.

Do this.

Do not do that.

Escalate under these conditions.

Do not escalate under those conditions.

You may modify these files.

Do not touch those.

Some of those instructions appeared in one place.

Some in another.

Some appeared in several places.

And occasionally they disagreed.

At which point the AI was being asked to solve what was essentially a constitutional crisis by interpreting English.

This is stupid.

The rule I am adopting is:

Guidance can live in prose. Invariants cannot.

If something absolutely must hold, the model does not get to decide whether it applies today.

It lives outside the model.

Now, I am not simply going to copy Claude hooks into Relay, because Relay deliberately does not care which AI provider supplies the worker.

Claude today.

Something else tomorrow.

The provider-specific mechanism is just an adapter.

Relay owns the rule.

The execution system enforces it.

That is a much cleaner boundary.

The other thing Anthropic has got right

Feedback.

This is embarrassingly obvious too.

If you ask an AI to build a user interface, it should be able to see the user interface.

Yet an astonishing amount of AI coding still works like this:

Build the page.

Compile.

Tests green.

Lovely.

Done.

Except the button is six inches wide, the menu is hanging off the side of the screen and the whole thing looks like an online banking portal from 2004.

The code is correct.

The product is hideous.

Anthropic explicitly talks about giving the agent a browser or screenshot loop.

Implement.

Run.

Look.

Compare.

Adjust.

Run again.

Of course.

I have UI-heavy projects.

I have approved visual designs.

I have implementation workers.

And I still occasionally end up acting as the worker’s eyeballs.

That is madness.

A work instruction should not merely say:

Make this look like the design.

It should say:

Run the product. Go here. Capture this screen. Compare it to this approved baseline. Fix the differences. Show me the evidence.

That is proper autonomy.

Not because the AI is more intelligent.

Because it has a feedback loop.

And once again, replace software with almost anything else and the rule survives.

An accounting agent needs reconciliations.

A stock analyst needs fresh market data and a way of testing its thesis.

A research agent needs source checks.

A marketing agent needs actual campaign outcomes.

Synthetic workers without feedback are just very confident employees wearing blindfolds.

Where I think Relay goes one step further

There is one idea in Relay that I still think is genuinely interesting beyond Anthropic’s playbook.

The worker’s role persists.

Not the conversation.

The role.

If an implementation worker completes a job and the organisation learns something about how that role should behave, the next worker occupying that role can inherit it.

The individual instance disappears.

The job evolves.

Think of it as organisational seniority.

The model does not remember yesterday.

The company does.

Anthropic does have institutional learning.

An incident can become an eval.

A correction can become shared configuration.

That is good.

Relay pushes the idea slightly further:

the role itself can become more senior.

My agents get promoted.

Theirs get better documentation.

Which sounds fantastic until you think about it for more than twelve seconds.

Because an automated appraisal might conclude:

This worker was successful because it showed initiative. Future workers should fix more adjacent issues while they are there.

Brilliant.

Until your next worker helpfully “improves” the authentication system while fixing a typo.

Or your virtual accountant decides that, on balance, the organisation would benefit from a more creative interpretation of expenses.

So seniority cannot simply mean mutating the prompt after every job.

That is how you breed a lunatic.

It has to work like software deployment.

Candidate role revision.

Tests.

Qualification.

Promote or reject.

Rollback available.

Which is, amusingly, Anthropic’s own advice about testing agent configuration, turned back onto the bit I think I added.

The bit nobody tells you

This is the part I wish somebody had explained to me at the beginning.

The agent doing the clever work is not the difficult bit.

Not anymore.

The difficult bit starts when the agent finishes.

Who decides whether the result is good?

Who notices that the work never started?

Who restarts it when the session dies?

Who decides whether a failure is technical, organisational or genuinely human?

Who owns the external action?

Who owns acceptance?

Who notices that three individually correct rules have combined to make progress impossible?

Who notices that the factory has stopped?

A coding agent is not a software company.

Ten coding agents are not a software company.

But the same is true everywhere else.

Ten AI accountants are not a finance department.

Ten stock-picking agents are not an investment firm.

Ten marketing agents are not a marketing department.

A workforce is not an organisation simply because you have given lots of models jobs.

An organisation is the thing that knows what it is trying to achieve, who is responsible, what they are allowed to do, how their work is checked, what happens when they fail and crucially notices when nobody is doing anything.

That, it turns out, is the hard bit.

And that is why I’m delighted by the Anthropic paper

Not because I can wave it around and shout:

LOOK! I WAS RIGHT!

Although obviously I can, and will.

It matters because it gives me an external reference point.

A lot of the things that seemed slightly eccentric when I started Relay are rapidly becoming normal.

Durable artifacts.

Headless agents.

Verification loops.

Deterministic approval gates.

Configuration evals.

AI operating around the lifecycle of work rather than merely inside a chat window.

Good.

Excellent, in fact.

Because I do not want to build every part of this system.

If Anthropic or somebody else supplies excellent execution infrastructure, I will cheerfully use it.

I do not need to invent another browser.

I do not need to invent another sandbox.

I do not need to invent another generic tool protocol.

I do not need to build an AI agent platform for the sheer masculine joy of having built an AI agent platform.

The workers are going to become cheaper.

The models are going to become better.

The execution machinery is going to become increasingly interchangeable.

And that is precisely why I think the layer around them becomes more interesting, not less.

Because Relay is not ultimately a bet on software engineering.

Software engineering is simply the first place I am proving it.

The actual problem is synthetic work: how you take intelligent but temporary workers; coders, accountants, analysts, researchers, marketers, whatever comes next and turn them into something that can be given responsibility and relied upon to carry it.

The execution changes.

The organisational problem does not.

What remains is:

Responsibility.

Authority.

Evidence.

Acceptance.

Recovery.

Institutional memory.

And liveness.

The bits that turn a collection of clever workers into something you can actually rely on.

So where is Relay now?

Somewhere between “astonishingly clever” and “call the union rep”.

It has architects.

It has workers.

It has persistent organisational state.

It knows who is allowed to do what.

It knows how work moves through review.

It can recover missed transitions.

It can publish source without giving the coding worker the keys to the kingdom.

It can distinguish an execution result from an accepted outcome.

All of that works.

And yet its first proper autonomy test still ended with a worker sitting on its arse.

Which is why I love building this.

The failures are far more informative than the demos.

Every time the system fails, it exposes another piece of invisible organisational labour that a human normally performs without even noticing.

We chase people.

We reinterpret instructions.

We spot contradictions.

We remember that a task still matters after somebody goes home.

We notice when someone says “done” but the thing quite obviously isn’t.

We know when a problem genuinely needs the boss and when somebody just needs to get on with it.

Remove the human from the middle and suddenly all of those tiny acts of common sense need an architecture.

That is the actual experiment.

Not whether Claude can write code.

We know it can.

Not whether an AI can analyse a balance sheet.

It can.

Not whether it can research a stock, draft a campaign or produce a report.

Those capabilities will improve relentlessly.

The question is whether replaceable AI workers can be wrapped in enough persistent structure that they become a reliable organisation rather than a collection of extremely bright people waiting for somebody else to make the tea.

That is what I’m building.

At the moment, it is British Leyland for robots.

Kafka with forklifts.

I’m working on the foreman.

My coffee is cold.

Chester has given up on me.

And I’m going to the office. o edit hu if you must know

It was not the plan.

This week: I code and deploy a fortnight of work before my espresso machine has made me a triple. I discover the last bottleneck in my entire company is my own brain, and I am deeply unkind to a machine over a border radius it did not deserve and then forgetting, at one point you cannot talk to humans in the same way.

I think if I had been born 150 years ago, and we temporarily ignore the gender dysphoria(!!!) for a moment, I probably would have ended up some Victorian factory owner with a stopwatch wandering around shouting at workers.

“Why are you standing still?”
“Why are you not busy?”
“What exactly is wrong with you?”

And unfortunately, it turns out I am exactly the same with synthetic workers.

Especially bloody software engineers.

If the little synthetic developer stops coding for more than about fifteen minutes, I immediately start thinking:

What is the blocker?
Why has this stopped?
Why is the throughput collapsing?
Who needs answering?
Why is there a red light over somebody’s head?

So the day becomes this endless merry-go-round of interruption and unblocking.

The architect comes back:
“We have a question from implementation.”

I sigh.

“Oh bollocks. Me again. I’ve blocked the whole thing again.”

Now I have to rapidly reload the entire context of some project I last thought about forty minutes ago.

Right. Okay. The graphic designer has produced an SVG pack, except apparently one of the SVGs has some weird border inconsistency. Which means the implementation worker has stopped because it is unsure whether to proceed.

So now I am back to the architect saying:

“Can you please not bother me with such low-level shit as this? The mini Claude is perfectly capable of fixing a bloody SVG. Look at the other images and make it match. Use your judgement. Do not escalate a border radius to the CEO.”

“You’re right, sire.”

Wonderful. Excellent. Next project.

And then immediately:

“Question from Overture.”
“Question from Relay.”
“Question from Record Now.”
“Approval required.”
“Clarification needed.”
“Architecture decision needed.”
“Review gate waiting.”
“Blocked.”
“Blocked.”
“Blocked.”

The thing is, the workers are not failing.

That is the important bit.

They are succeeding too well.

That is the actual problem.

The throughput is astonishing.

Yesterday morning, on one project alone, I was presented with a list of about twelve UI changes alongside an 11am meeting to demo the software.

I said:
“No problem. They’ll be done.”

And someone quite reasonably asked:
“Really? Are you sure you can get all that done in time?”

Absolutely.

Three minutes briefing the Relay architect.
The architect decomposes the work.
Mini Claudes dispatched.
Changes implemented.
Review passes completed.
Release pipeline triggered.

Done.

The actual bottleneck was not software engineering.

It was waiting for the Azure DevOps pipeline agent to finish deploying the thing.

The entire loop, from briefing to deployed software, took something like fifteen minutes.

Honestly, it was astonishing.

Not because one AI wrote one code file.

Because an entire orchestration chain operated at a speed that simply does not exist inside normal organisations.

And that is the bit people do not yet fully understand.

The synthetic workforce operates not merely at my pace, but at a pace vastly faster than my pace. Faster than any human organisation I have ever worked in. There are no coffee breaks, no politics, no meetings, no wandering off for a chat, no dead time, no passive-aggressive Jira comments, no pretending to work while secretly looking at Rightmove.

Just continuous production.

Which sounds wonderful right up until you realise something very important.

Human cognition is now the bottleneck.

Not compute.
Not engineering.
Not implementation.
Not architecture.

Me.

Specifically, my brain.

Because every blocked worker eventually escalates toward the human operator. And every escalation requires context restoration.

That is the true tax.

Not coding.

Context switching.

I start the day magnificently.

Double espresso at 8am.
Another at 9.
Another at 10.

By this point my head is basically on fire.

A colleague I get on with well said to me yesterday:
“You’re on coffee number four? You’d never know.”

Oh, you’d know internally, mate.

Internally I am conducting an entire synthetic orchestra while trying to stop six machine employees from simultaneously setting fire to different projects.

In the morning, I am flying.

Fast decisions.
Rapid approvals.
High ambiguity tolerance.
Large architecture reviews.
Complex reasoning.

The machine absolutely loves this version of me.

The problem is that this version of me is temporary.

Because unlike humans inside normal organisations, synthetic workers do not naturally understand fatigue.

Human organisations accidentally self-throttle through friction:

• meetings

• delay

• social hierarchy

• incompetence

• politics

• waiting

• indecision

• pretending to work while secretly looking at Rightmove

Synthetic organisations remove almost all of that drag.

Which sounds amazing until you realise the drag was partially protecting the nervous system of the operator.

By about 3pm, I can physically feel the cognitive load starting to collapse. The morning fire slowly cools into warm soup.

Now a human colleague asks me something and internally I think:

“Christ. Another context switch.”

And occasionally I become slightly ratty because human beings unfortunately do not appreciate being spoken to like delayed orchestration workers.

Synthetic workers tolerate:
“Wrong. Redo it.”
“Insufficient reasoning.”
“Why did you escalate this?”
“Do not bother me with SVG borders.”

Humans, somewhat understandably, are less enthusiastic about this management style.

And there is probably a slightly more unsettling point hidden inside that too. The machines are quietly training me into a style of management and communication which works extremely well on synthetic workers and considerably less well on actual people. Increasingly I can feel myself having to consciously switch modes before talking to humans again.

But this led me to what I think is one of the genuinely important insights emerging from all this experimentation.

Synthetic organisations need cognitive load awareness.

Not because the machine should become more autonomous when the operator is tired.

Absolutely not.

That is dangerous.

The operator remains the governance boundary.

The machine does not gain authority.

Instead, the machine changes the shape of the work it surfaces.

That distinction is critically important.

If my cognitive bandwidth is low, I do not want the machine making larger decisions. I want it reshuffling the deck to surface cognitively cheaper work.

So instead of surfacing deep architecture reviews, ambiguous model design, strategic reasoning and risky judgement calls, the orchestration layer should preferentially surface lightweight coordination work, markdown contracts, tiny implementation deltas, obvious approvals and decomposable work units.

In other words:

Do not increase machine authority.

Decrease operator cognitive drain.

A few days ago I accidentally realised I was already doing this manually.

I was deploying something fiddly in Azure which required me to physically click around doing annoying human meat-person activities. The sort of thing that increasingly makes me want to throw up now because the machines can normally do almost everything for me.

And instinctively I said to the architects on the other projects:

“Give me trivia.”

Not because the work was unimportant.

Because my brain was saturated.

So I told them:

• no large deltas

• no complex reasoning

• no giant review packs

• no strategic decisions

Just simple markdown tasks.
Tiny approvals.
Easy wins.
Low cognitive overhead work.

And suddenly I realised:

Oh my God.

This is an actual systems problem.

Not an AI problem.
Not a coding problem.

A human bandwidth problem.

What I think I am slowly discovering, in public, in real time, is that the management science of synthetic organisations may end up looking completely different from human organisations.

Because labour is now effectively infinite.

But executive cognition remains stubbornly biological.

Which means the real challenge becomes:

How do you stop a machine-speed organisation from melting the human operator at the centre of it?

At first I imagined this would end up as some horrible hidden configuration screen buried somewhere inside Relay.

Which immediately struck me as absurd because configuration screens are themselves a cognitive tax.

And then suddenly the answer became obvious.

A giant graphic equalizer.

Something visceral.
Something immediately understandable.

Not:
“AI orchestration cognitive prioritisation matrix.”

Just:

How much brain have I got today?

And where do I want to spend it?

Something like this:

Internally, the orchestration layer would then reshuffle the deck accordingly: heavy reasoning deferred, context reloads minimised, cognitively expensive work queued for tomorrow morning, and easier decomposable tasks surfaced while the operator still has enough bandwidth left to make good decisions.

Because another important thing I have realised is that different projects consume different kinds of cognition.

Some require systems reasoning.
Some require aesthetics.
Some require strategic thinking.
Some require careful review.
Some are almost mentally restorative.

And increasingly, I think the orchestration layer should understand that too.

The really fascinating thing about all this is that I genuinely do not feel like I am theorising anymore.

I feel like I am observing.

Like someone accidentally wandered into the very early days of an entirely new kind of company and is standing there scribbling field notes while the thing evolves around them in real time.

And finally, the absurdity of it all is this.

I took this essay, handed it to my architect for the Relay system, and said:

“I think there are some interesting ideas in here.”

Within five minutes, we had thrashed out the issues.

And as I write this, there is a mini Claude building the domain model for the whole thing and implementing the basic code.

Update: An hour later the UI was built

Which is, of course, exactly the problem the essay is about.

Honestly, this is one of the most fascinating experiments of my life.

I absolutely love working with the machines.

They are tireless.
Relentless.
Absurdly productive.
Incredibly capable.

And every single day now feels like this desperate, exhilarating attempt to work out how to harness that capability without turning my own brain from fire at 9am into warm soup by 5pm.

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.