“Get Back to Fucking Work” - How I Built British Leyland for Robots

Anthropic publishes its AI-Native SDLC playbook, I realise Relay already looks like it, and discover I’ve built the most overengineered strike in history.

Yes!! I ended up back I my office!!

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.

Yes, I know. Every article must have at least one photograph of my dog in it.

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.

If you see me writing an article entitled I'm converting a truck into an RV, please intervene. I do not have time for such a project.

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.

This is the bit where the “AI company” stops being a metaphor. What is moving, what is stuck, and what actually needs attention today.

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 important distinction: outcomes first, tasks second. The organisation should know what it is trying to achieve before it starts manufacturing work.

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.

Not everything worth doing should immediately become executable work. This is the supply of possible work before management decides what actually enters

Planning.

Handover.

Review.

Testing.

Deployment.

Incident response.

Once work is selected, it becomes a delivery path: related pieces of work arranged around an outcome rather than a pile of disconnected prompts....

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.

The work survives the worker. Context windows end, sessions crash, models disappear. The job is still there on Monday.

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

At one point I ended up with so much governance and petty rules that nothing was getting done whatsoever. It was like a unionised 1970s British car plant.

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.

Caption: Twenty things are allowed to say “stop”. Nobody owns making the answer become “go”.

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.

So the AI architect produced a beautiful roadmap ready to implement, and the workers managed to find endless excuses not to actually start working on it.

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.

---

Caption: Objective: yes. Plan: yes. Work authorised: yes. Worker available: yes. Attempts actually made: zero.

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.

---

Caption: Before: 200,000+ tokens discovering a contradiction the computer already knew about. After: check the tools, permissions and paths before waking the expensive robot.

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.

The workforce, such as it is: persistent roles with jobs, authority and work attached. The model instance can disappear; the role remains.

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.

The expensive queue. Every item on this screen means Relay has stopped and decided that only a human can move it forward. Ideally, almost nothing should ever live here.

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.

Finished. Genuinely needs a human. Genuinely out of resources. Waiting on the real world. Everything else goes in the box marked 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.

Relay had become extremely safe. Unfortunately it had also become extremely stationary.

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.

“Compiled and the tests pass” is not the same thing as “the product is right”. Every synthetic worker needs a way to observe the result of its own work.

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 model does not remember yesterday. The company does. But untested “learning” is just prompt drift with a promotion badge.

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.

The workers will become cheap and interchangeable. The organisation around them is the interesting bit.

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.