When the Domain Expert Becomes the Builder

Every automation project contains a translation step, and the translation is where the exceptions quietly die. When the person who knows the exceptions builds the thing herself, the thing that comes out is not a faster version of the old thing — it is shaped differently.

Picture a requirements workshop for something unglamorous: the approval path for vendor invoices at a company with a few thousand suppliers. On one side of the table is someone who has run that process for eleven years. On the other is a capable analyst with a template and a whiteboard. The expert describes the process in about twelve minutes, because the process, described, is genuinely simple — an invoice arrives, it is matched against a purchase order and a receipt, it is coded, it is routed by amount, it is paid. The analyst captures all of it accurately. Then, in the last five minutes, while the whiteboard is being photographed, the expert starts talking in asides: the four suppliers who invoice before delivery because of a contract amendment nobody remembers signing, the freight line that always arrives mis-coded and must never be auto-approved even though it is small, the plant that submits in the wrong currency during the last week of a quarter, the one category where a duplicate looks exactly like a legitimate second shipment and the difference is a field nobody thinks to look at.

Those asides are the job. They are also the part of the conversation with no home in the document, because a requirements document is built to record what usually happens and to relegate what rarely happens to a section called edge cases, appendix, or phase two. The analyst is not careless and the expert is not withholding. The format itself performs a lossy compression, and it is worth being precise about what it drops: it preserves frequency and discards consequence. The rare-and-harmless and the rare-and-catastrophic go into the same bucket, sorted by how often they occur rather than by what they cost when they occur, and the person who could have told you the difference has just been thanked for her time.

Expertise is a ranking of the ways it goes wrong

It is tempting to describe domain expertise as knowing how the work is done. That is not quite right, and the imprecision is what makes the translation step feel safe. Almost anyone competent can learn the standard path of a business process in a week or two; the path is usually documented somewhere, and where it isn't, watching three cycles will teach it. What takes eleven years to acquire is something else entirely — a ranked, weighted map of the ways the process deviates, and, crucially, a sense of which deviations are noise and which ones are the beginning of an expensive week. That ranking is not a list of exceptions. It is a judgment about which exceptions deserve to shape the design.

Nothing in the standard handoff is built to carry a ranking. A spec can carry a list, and lists arrive at the builder flattened, in no particular order, each item looking about as important as its neighbor. So the builder — reasonably, professionally — implements the main path first, because that is what the document foregrounds, and defers the list because the list is long and the deadline isn't. What ships is a system that is correct on the case that was never hard and silent on the cases that were. Then the exceptions arrive, as they always do, and each one is handled as a patch: a condition bolted onto a structure that had no place for it, until the system accumulates a layer of special cases with no organizing logic, understood by no one, and the process owner goes back to doing the tricky ones by hand because she no longer trusts what the system does with them.

There is a broader version of this failure showing up in enterprise AI programs generally, and the analyst community has started naming it. Gartner has predicted that more than forty percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs and unclear business value among the reasons. Unclear business value is a diagnosis worth reading carefully, because value in an operational process is rarely destroyed on the standard path. It leaks through the cases the builder was never told mattered, and a project that automates the easy eighty percent of a process while leaving the hard twenty percent on someone's desk has not removed the desk. It has added a system to maintain alongside it.

The order of encoding changes the artifact

Here is what actually differs when the expert builds it herself, and it is not primarily speed. It is the order in which things get encoded. Ask an expert to build the invoice approval flow and she will not start with the happy path, because the happy path is not where her attention lives — she stopped thinking consciously about it years ago. She starts where she hesitates. The first thing she encodes is the mis-coded freight line, because that is the thing that has burned her, and the second is the quarter-end currency problem, and only somewhere around the fifth or sixth move does she build the ordinary matching logic, almost absent-mindedly, as the thing that happens when none of the interesting conditions apply.

That inversion produces a structurally different artifact. A system built exception-first treats deviation as a first-class shape rather than an afterthought, which means that when the next unanticipated case appears — and it will — there is an obvious place to put it, because the system's spine is already an argument about which conditions matter. A system built happy-path-first has to be violated to accommodate its first surprise. The difference compounds over years, and it is largely invisible at launch, when both versions demo identically on the standard case. It becomes visible in month eight, when one of them has absorbed a dozen new realities gracefully and the other has become a thicket nobody wants to touch.

The second difference is in the feedback loop. When the builder and the person who can judge correctness are the same person, evaluation happens continuously and against reality rather than against the document. Conventional acceptance testing can only demonstrate conformance to the translation; if the translation lost the currency problem, no amount of testing against the spec will find it, because the spec is not wrong on its own terms. An expert running her own build notices in the first afternoon that the system approved something it should have held, and she notices it the way she notices a wrong number on a familiar report — not by inspection, but by recognition. That recognition is genuinely hard to transfer, which is precisely why it is worth keeping close to the build. Much of the current work on the autonomous enterprise turns on this point: platforms like StudioX are built so that a process can be described in the language its owner already uses, assembled into AI Missions run by Autonomous AI Workers, and revised by that owner directly rather than through a queue — not because engineering is unnecessary, but because the ranking of exceptions cannot survive the round trip.

Where the expert's build still needs a second pair of eyes

None of this argues that the domain expert should build unsupervised, and it would be dishonest to pretend the two kinds of expertise substitute for one another. The expert knows the failure modes of the work; an engineer knows the failure modes of systems, and those are different lists. A process owner is unlikely to think about what happens when a step retries after a timeout and issues a second payment, or about who inherits access when a person changes roles, or about which records are subject to retention rules, or about the behavior of the whole thing under a load ten times larger than the one she tested on. Those are not domain questions and they will not surface from domain knowledge, no matter how deep it runs.

So anywhere an expert-built system touches money, people, or records of consequence, review is not a formality and should not be framed as one. That review is best understood not as approval — the expert does not need permission to know her own process — but as a second axis of inspection by someone whose expertise is orthogonal, with human decision points deliberately left in the flow where a mistake would be expensive to unwind. The systems that hold up are the ones where the domain expert owned what the system should do and an engineer owned what happens when it does it wrong, and neither treated the other's contribution as overhead.

The mental model worth carrying away is about what a requirements document actually is. It is not a transfer of knowledge; it is a compression with a known and predictable loss profile, and what it loses is the ranking that took a decade to build. Once you see it that way, the useful question about any automated process changes. Stop asking whether it handles the standard case correctly, since it almost certainly does and that was never in doubt. Ask instead whose hesitation is encoded in it — how many of its branches exist because somebody remembered something, rather than because somebody specified something. Systems built from specifications tend to have very few, and you can usually find out how few on the first bad Tuesday.