Who Should Inform the AI Build — the Engineer or the Person Doing the Work

An AI build needs both engineering skill and the knowledge of the person doing the work, but they serve different purposes. The operator defines what a right answer is. The engineer turns that knowledge into a working system. When the build reverses those roles, it can solve the wrong problem cleanly, producing answers that look convincing until someone has to act on them.

Why AI systems built without operational context fail in ways that are hard to detect

An AI billing agent can compile cleanly, pass every test the engineer wrote, and still apply the wrong logic to refunds, partial payments, or month-end cutoffs. Nothing has to crash for the build to fail. The system can produce tidy outputs while mishandling distinctions that the engineer never knew existed. To someone unfamiliar with the work, those outputs may look entirely reasonable. The accountant responsible for reconciliation knows why they are not.

That is a harder failure to detect than broken software. The engineer’s tests are bounded by what the engineer imagined, while the operator’s edge cases come from what has actually happened. If the build leaves out those experiences, passing quality assurance says little about whether the agent can handle them. A green test result is not an accounting qualification.

Better prompting alone cannot close this gap. A skill file cannot supply tacit knowledge gained over hundreds of transactions or compliance disputes unless someone first spells out what they know. The missing ingredient is the operational context needed to distinguish an acceptable answer from an expensive mistake.

What the engineer brings to the build, and what they structurally cannot

Engineers know how to build systems that process language, recognize patterns, and generate outputs at scale. That contribution is real and irreplaceable. Translating a business rule into production software requires more than understanding the rule in conversation. It requires the technical skill to make that rule work within a system and to test whether the system follows it.

Operational knowledge answers a different set of questions. Which exceptions need separate treatment, which errors cost money, and who will act on an output under which conditions? An engineer cannot infer those answers from technical competence alone. Nor can someone quickly learn the history behind them just by reading a requirements document. The person doing the work often knows distinctions that have never needed to be written down because, until now, a person was making the judgment.

When the operator is two meetings and a requirements document away from the build, engineering has the means to ship but only a filtered account of what to ship. Slow iteration and misaligned logic are predictable consequences of that separation. The engineer is not the villain in this story. The structure that keeps relevant knowledge out of reach is.

As building systems becomes less of the binding constraint, knowing whether they produce right answers becomes more important. That shift changes who needs to participate in technical decisions. It makes operators’ and engineers’ work interdependent at points where a conventional handoff treats it as separate.

What domain expertise actually looks like when it enters the build

An accountant’s request to “automate reconciliation” leaves almost all the difficult questions unanswered. The useful input is more specific. Refunds, partial payments, currency conversions, and month-end cutoffs require separate treatment, and the accountant knows where those distinctions change the result. Naming them gives engineering something more precise than a broad task description.

That knowledge enters the build as rules, guardrails, and edge cases. The operator explains what the process permits and which apparently reasonable outcomes would be wrong. Engineering uses that account to work out invocation, context passing, and test coverage. Neither side can substitute for the other.

The tests are where the distinction becomes especially clear. A test drawn from a real exception can challenge an assumption that an ordinary example would leave untouched. The operator is not merely checking whether the output reads well or resembles familiar work. They are judging whether the system respects the distinctions on which the work depends. That is a much higher bar than plausibility.

This is why attendance at a kickoff meeting does not amount to domain expertise informing a build. Knowledge has to alter what gets built and what counts as passing. An operator without engineering support may have a sound specification but no working system. An engineer who has no input from the person doing the work may have excellent infrastructure built to solve the wrong problem.

How the industry has begun to solve this structurally with embedded engineers

The forward-deployed AI engineer is an organizational response to this separation of knowledge. A forward-deployed engineer, or FDE, embeds inside a customer’s operation to build, integrate, and ship production systems using the customer’s own data and workflows. The role places someone with engineering skills close enough to the work to encounter what a remote team might miss.

Palantir pioneered the role, which became a defining AI job category in 2025–2026. FDE job postings grew dramatically over the twelve-month period through April 2026. The significance is not simply a new title. The role keeps engineers close to the customer’s work as part of how they build, rather than through occasional visits to learn about it.

OpenAI formalized its FDE approach on May 11, 2026, by announcing the formation of “The Deployment Company,” a joint venture majority-owned by OpenAI and backed by substantial investor funding. Anthropic placed applied AI teams and forward-deployed engineers with Fidelity National Information Services to work together in May 2026. Those teams worked with FIS to design financial crimes AI together for use in anti-money laundering investigations.

OpenAI’s work with John Deere shows what that proximity can produce. Its FDE teams worked with Deere’s domain experts, reviewing real-world examples, building custom evaluation systems, and iterating on model performance. They put AI-powered planting recommendations into use that helped farmers cut their chemical use by a meaningful amount. Knowledge of farming helped set what the system should optimize for and how to judge how well it worked. For organizations unable to support a dedicated FDE team, that relationship offers a model to follow.

Why SMBs feel this gap most acutely, and why the stakes of getting it right are highest for them

Small and medium businesses are least likely to have a dedicated FDE on staff, yet a misaligned automation can reach across their operation. There may be little redundancy to absorb it. A system that appears to function while applying the wrong logic can therefore create work for the same people it was meant to help. The damage can consume both the build budget and the operating time needed to recognize and correct the mistake.

The asymmetry is sharpest in a small team. A five-person operation has much to gain from a system that takes repetitive work off its hands, but little spare capacity to accommodate one that needs constant correction. Those are not separate considerations. No other department has spare time to take on that work.

The distinction between stronger and weaker implementations is therefore not just the technology. To build a deep knowledge base, set clear baseline metrics, and keep the scope narrow at first, someone must know the work well enough to describe it accurately. A high-volume, repetitive task is not automatically a well-defined task. Someone still has to explain where repetition ends and judgment begins. Without that boundary, a broad promise to save time can conceal a poorly specified process.

The objection that operators have no time to participate reverses the risk. Their absence can produce a system they do not trust, do not use correctly, or use in ways that introduce new errors. Participation has a cost, but so does discovering the requirements after deployment. For a small business, involving the operator is part of protecting scarce capacity.

What the build process looks like when the domain expert is genuinely centered, not just consulted

Before anything is built, the person doing the work describes the actual process, including what happens when an exception arrives or the system is under pressure. The polished version is not enough. A process described only through its routine cases gives engineering a clean picture by leaving out the difficult parts. Diagnosis brings those parts into the build before technical choices become fixed around a description that leaves things out.

That description should produce one high-impact, well-understood workflow with clear before-and-after criteria. The operator defines the scope for the engineer. This is a reason to start narrow. One workflow, one operator, and a focused trial period allow detailed knowledge to shape the build without asking a small business to redesign everything at once. Depth of input on one pipeline can compound faster than shallow input on five.

The operator is accountable for identifying the cases the system must handle correctly. The engineer builds test coverage from those cases and makes the system meet it. Technical tests still have a place alongside the judgment of the person doing the work.

That split in the work must last beyond the initial release. When the operator notices an output that is wrong in a way the engineer would not catch, the feedback needs to reach the build within days. The operator needs to explain the failed distinction clearly enough for engineering to correct it. Keeping that exchange close to the work keeps domain input from being left in a document that is out of date.

A build organized this way has a route to improvement because the people using it know which errors deserve attention and how to explain them to the engineer. As their knowledge enters the system, it becomes better fitted to the work they actually perform. That continuing exchange is the compounding advantage of centering the operator.

The question that should open every AI build conversation

Before asking “What can be automated?”, ask “Who in this organization knows, in granular detail, what this process actually requires? What is technically possible comes after that, because designing a useful system requires someone to first spell out what it needs to do.

An engineer who keeps asking that question through scoping, testing, and iteration is doing the job correctly. An engineer given a kickoff document and expected to proceed independently is structurally exposed to solving the wrong problem. If approval is requested without any discussion of what happens when an exception fires, the proposed build is not yet grounded in the knowledge needed to judge it.

The reward for closing that gap goes beyond a correct first deployment. A system that reflects the work can earn the trust of the people using it, and that trust makes their feedback more useful to its development. Their judgment becomes an input to improvement rather than a private correction made outside the system. Engineering puts that knowledge into a form the business can use again and again. The best operator in the room has less work, and the business can do a wider range of work well.