Most of our automations do not use a language model

We publish a registry of every system we run. Twelve entries, ten deployed, one in cutover, one prototype. Eight of the twelve contain no language model anywhere in them.

That is not a position we took for its own sake. It is what the work turned out to need, counted honestly after the fact. We publish the count because it is the kind of claim that is easy to make and rarely checkable, and because the number moves in whichever direction the next twelve systems take it.

What a model is actually for

A language model interprets or generates language where ambiguity matters. That is the whole job. It is not agency, and it is not authority — a model on its own decides nothing and is permitted nothing.

So the question for any given system is narrow: is there genuine ambiguity here that rules cannot express? Sometimes there is. One of our capabilities reads expense documents and returns structured fields. Expense documents are written by humans in whatever format their employer tolerated, and no rule set survives contact with them. That is real ambiguity, and a model earns its place.

Most operational problems are not like that. A booking system needs stale hold records expired on a schedule. There is no ambiguity in a timestamp. Putting a model near that decision adds cost, latency, a failure mode that cannot be reproduced, and nothing at all in return.

The expensive version of the same mistake

The failure we see most often is not a model doing something wrong. It is a model placed where a rule belonged, and then the whole system inheriting the model's properties: non-deterministic, hard to test, impossible to explain to a client when it misfires at eleven on a Friday.

An agent that issues fiscal donation receipts for a non-profit runs with no model at all. It decides, per request, whether it is permitted to act, and refuses when the grant is absent. That is a real decision made from context — it meets every definition of an agent we use — and it is deterministic end to end. Rules, arithmetic, explicit boundaries.

The same is true of an agent that turns retail orders into accounting invoices: for each order it decides whether to issue, skip, or hand the thing to a human, and it holds a lock so a duplicate webhook cannot invoice the same order twice. Deciding is the point. A model is not required to decide.

Why the distinction is worth keeping

The word agent has been stretched until it means roughly nothing. If everything is an agent, the label carries no information, and a client cannot tell the difference between something that files a report and something permitted to move money.

We keep five terms apart — automation, agent, LLM, harness, system — and label every registry entry accordingly, including the ones that are not agents. Three of the twelve are plain automations. We say so on their pages. Calling them agents would be flattering and useless.

The distinction is not a hierarchy. An automation is frequently the better engineering result. It is a way of picking the right mechanism instead of the most impressive-sounding one.

What this means if you are buying

Ask where the model is, and what would break without it. A vendor who cannot answer either does not know their own system well enough to be running it against your orders.

Ask what happens when the model is unavailable. If the answer is that the whole thing stops, the model is holding structural weight it was never designed to hold.

And ask for the count. Any studio can say it uses AI judiciously. The number of systems that contain no model is checkable, and it is the one figure nobody inflates.