Software all the way down

The phrase is borrowed from an old joke about cosmology, and it means something specific here: at no layer of delivery is there a person quietly doing the work while the system takes credit.

That sounds like a low bar. It is not, and most of the category does not clear it — usually not by intent, but by accumulation.

The four layers

Understanding. The picture of the situation is assembled by reading systems, not by someone maintaining a spreadsheet on a Monday. A dashboard fed by a weekly manual export has a person at this layer.

Deciding. Options are generated and compared by a model against state, with the assumptions explicit. A "recommendation engine" whose recommendations are written by an analyst is a person at this layer.

Delivering. Work is executed through governed calls into real systems. Agents work inside real products through governed tool calls — the CRM, the campaigns, the site — rather than producing text for someone to paste. Text output with a human paste step has a person at this layer, and this is by far the most common place to find one.

Verifying. Work is checked by an independent agent against criteria. A vendor whose quality control is a review team has a person here.

Delivery is the layer where the claim is most often quietly false, because a paste step is invisible from the outside and feels like nothing while you are doing it.

Where a person belongs

Two places, and being clear about them is what makes the rest of the claim credible rather than absolutist.

Deciding what should happen. Objectives, priorities, trade-offs between things that cannot both be true, and everything on the never-autonomous list. Nothing in this argument suggests software should set your strategy.

Approving consequential actions. Depending on the autonomy level in force, a person approves before actions with real consequences. That is a designed step, visible in the record, not a hidden one.

The distinction is between a human in the decision path, which is the point, and a human in the delivery path, which is the thing being claimed does not exist. A product that blurs those two is usually blurring them deliberately.

What makes it checkable

A claim like this is worthless unless something makes it verifiable, so here is the mechanism rather than the assertion.

Every agent gets only the context and tools its mission allows. That scoping produces a record: for any deliverable you can see which agent produced it, what it was permitted to read, which tool calls it made, and against which criteria it was checked. If a person had done the work, there would be no such record — there would be a gap where the tool calls should be.

The record is the check. Ask for it on a specific deliverable and see whether the chain is continuous. A continuous chain of tool calls from state to artefact is software all the way down, demonstrated. A gap in the middle is where a person was.

The protocol layer that enforces the scoping is on MCP.

Where the paste step hides

Worth dwelling on the delivery layer, because it is where the claim fails most often and where it is hardest to see.

The pattern looks like this. The product generates an excellent draft. Someone reviews it, makes two small changes, and pastes it into the system where it belongs. Everyone involved experiences this as the product working. It is a person in the delivery path, and it has three consequences that only appear at volume.

Throughput is bounded by attention. The number of artefacts per day is the number a person can paste, no matter how many the model can produce.

The record breaks. The trace ends at the draft. What was actually sent, by whom, at what time, differs from what the system knows, and the difference grows.

Improvements do not compound. The two small changes the reviewer makes every time are knowledge that never returns to the system. It is corrected downstream, forever, invisibly.

The fix is not to remove the human review. It is to move the review to before the action rather than between the draft and the action — approve, and the system executes, with the approval recorded as part of the chain.

Why it is worth holding

Three consequences follow from the property, and they are the reasons to care.

Cost behaves like software. Marginal delivery cost is compute, not labour, so scaling does not require hiring and your pricing does not have to absorb someone's salary.

Errors are fixed once. A systematic failure is corrected in a prompt, a play, or a criterion, and the correction reaches every future instance. Errors held in people's heads are fixed unevenly and return with turnover.

The record exists by default. Because the work is software, the trace is a by-product rather than a reporting exercise. This is what makes governance, verification, and evidence packs possible at all.

The honest edges

Two things this does not claim.

It does not claim the software is right. Independent verification exists precisely because it often is not, and the record's purpose is to make the failures findable rather than to imply there are none.

And it does not claim you should retire everything you run. Adoption is coexist, then orchestrate, then consolidate, and most companies should expect to spend a long time in the middle phase — the three phases are a sequence, not a countdown.

What it does claim is narrow and checkable: no employee of ours executes customer work, at any layer, and the tool-call record is how you would catch us if that changed. The full positioning argument is on why Brainis.