We Taught People to Be Computers

There is a level of accuracy your operation cannot reach, at any price, with any number of people.

That is not a management failure, and hiring will not fix it, because hiring is what causes it.

For decades this industry has been teaching people to behave like computers. Do not deviate. Do not improvise. Do not tire. Follow the procedure exactly and do not make mistakes. We were right that the work wanted a computer. We simply did not have one, so we trained people to approximate one, and then built the entire operating model around the two places where the approximation breaks.

The first break is that attention degrades. People get bored. They tire. They satisfice, particularly on the four hundredth item that looks like the three hundred and ninety-nine before it. You cannot buy continuous vigilance from people, so you stop trying to. You ration it instead, which means you batch the work, set a deadline, and concentrate the effort at the cutoff. That is where the close comes from.

What you get for it is a risk profile shaped like a deadline. Operations tend to produce their worst failures at their busiest moment, which is exactly what a model built on rationed attention predicts. Nobody designed that. It fell out of the workaround.

The second break is that attention is correlated. Put five people on the same number and you do not get five independent opinions. You get the same training, the same system, the same tolerances and the same blind spots, five times over. Redundancy assembled from people is correlated redundancy, and stacking it was the only redundancy money could buy. That is where the pyramid comes from.

What you get for it is a control model that catches the errors which announce themselves, a position that moves strangely, a number outside its usual range, and structurally misses the quiet ones: a security set up wrong at the start, drift too small to trip a threshold, two errors that cancel each other out. More reviewers does not help. Each one is looking the same way as the last.

Now the part that rarely gets said plainly. Every process carries two goals at once, accuracy and cost, and under those two breaks the goals are in direct opposition. Accuracy is bought with review. Review is bought with people. People are the cost line. So the operating model becomes a dial. Turn it toward accuracy and the margin goes. Turn it toward cost and you are betting that the errors you let through will be the cheap ones.

Errors are rarely cheap. The rework is the smallest part of it. Senior people stop what they are doing to reconstruct what happened. Someone explains it to the client, which spends a scarcer kind of capital than money. Occasionally the client decides the explanation was not sufficient, and you learn the real price, which arrives at the next renewal rather than in the incident report.

So firms set the dial somewhere uncomfortable and live there. That was not a failure of management. Given what people are, it was the correct decision.

But the dial does something worse than force a tradeoff. Stacking correlated reviewers has a ceiling. Each additional layer costs about what the last one cost and catches less, because it is looking the same way as the layer beneath it. There is a level of accuracy you cannot reach by adding people, at any price at all. Firms meet this when a client asks for something the existing model cannot support, and the honest answer is not that it would be expensive. It is that it cannot be done this way.

The close and the pyramid are not accounting principles. They are what you build when the only computer available is a person.

There is another kind now. Machine attention does not degrade, and it does not have to be correlated, which means the tradeoff was never a law. It was a consequence.

The first of those means assurance no longer has to be batched. It can run continuously underneath whatever cadence your product actually requires, so the official number becomes a snapshot of a book that was already right rather than something manufactured against a deadline.

The second is the larger one, and it is the one almost nobody is using. When checking is abundant, you stop buying more of the same look and start buying different looks. A mirror position that should move in step. The same figure derived three unrelated ways. An outside source with no reason to agree with you by accident. The value of a check was never that it happened. It was always its independence, and independence was precisely the thing you could not afford.

So the dial comes apart. You are not selecting a better point on the old curve. The curve was drawn by two limits that no longer bind, so you can reach accuracy that was previously unpurchasable and spend less getting there. To anyone who has run one of these operations that sentence should sound untrue. It was untrue, for a long time, and the reason it was untrue has stopped being the case.

Finding these in your own operation is not inspiration, and it is not a room full of sticky notes. It is specific, and it repeats. Take a practice your firm treats as settled. Name the human constraint that made it correct. Then test whether that constraint still binds.

If it binds, you have confirmed a real design and you should leave it alone. If it does not, the practice was never a law. It was a choice, made well, under conditions that have since changed, and it is yours to make again. The close survives that test as a reporting and commercial event. It does not survive as a reason to batch assurance. The pyramid does not survive it at all.

Run this across your operation and the list will be shorter than you fear and more uncomfortable than you expect, because the practices that fail the test tend to be the ones with the most senior defenders.

Once a constraint turns out to be dead, you have to decide what actually does the work instead. That decision is the first pillar of the Trust Architecture. Complementary intelligence is how the work gets divided: which parts of a process go to software, which go to a model, and which stay with a person.

Until recently that list had two entries. Software, where the work was deterministic and the volume justified the build. People, everywhere else. And everywhere else was enormous, because it included all the work software could have done in principle and never did in practice. Moving data between systems that were never designed to speak to each other. Reformatting a client file because the client's format is the client's. Chasing the one field that did not come through. Every operation in this industry has people staffed on glue, and the reason was never that the work required judgment. It was that building the connector cost more than staffing it.

That was an economic constraint, not a technical one, and it has moved for the same reason the other two have. Code that used to take a quarter to specify, build and test now takes days. A great deal of work that was always the wrong job for a person is now worth automating properly, and most firms have not revisited that list since the price changed.

Then there is the third executor, which did not exist at all. A model can do things that previously only a person could: read a document and understand what it says, classify something genuinely ambiguous, take meaning out of a message somebody typed in a hurry. It belongs wherever the answer is reachable from context you can give it and you have engineered a way to know whether it got there, which is the second pillar.

What is left is what people should have been doing all along.

One warning goes with that. The allocation is made per step, not per process. The common error is to decide that reconciliation is an AI project, or that the close is a software project. No process in your operation belongs to a single executor, and decomposing it until every piece has an obvious owner is the work itself. It is why this pillar comes before the other two, and before any tool is chosen.

The reason to do this before any tooling decision is that the alternative is well documented, and the cost framing is how firms walk into it. A business case built on hours removed can only justify putting machines where the people currently are. It has no way to ask whether the people should be there, because the shape of the process is the one thing it holds fixed. Buy on that basis and you will get exactly what you measured.

Decompose a process, hand the same shape to machines, and you have bought a faster version of the operation you already had. The close still concentrates the risk. The redundancy is still correlated, except that now some of it is synthetic, which is worse, because correlated machine checks agree with each other more reliably than people do. The tradeoff survives intact, and you have added a software line to the budget. That is what most AI programs in this industry are going to produce, and it will look like progress for about a year.

The work that matters is deciding what the operation actually is, given attention that does not tire and does not have to agree with itself. That is complementary intelligence, the first pillar, and the other two depend on it. Once checking is continuous and independent, something has to decide what reaches a person and who is accountable for the answer, which is the validator operating model. And once the maker layer is no longer where people learn the business, something has to replace the apprenticeship that layer was quietly running, which is where most of these programs will actually fail.

None of it starts with a tool. It starts with asking what your operation was built around, and whether that thing is still true.