Field Note · Applied AI and system ownership
The Expert Has to Be Inside the Workflow While It Changes
The hardest part of an AI implementation is usually not teaching a system to generate an answer. It is getting the business to describe what a good answer actually is.
By Andrew Moss · August 2026
Picture a mid-market manufacturer with thirty years of repair notes, customer emails, exception spreadsheets, and two people who know which "rules" are actually rules.
The company does not need a chatbot. It needs a way to carry those two people’s judgment into the next decision without flattening it.
A generic model can summarize the manuals. It may even draft a plausible recommendation. But the value in the business sits in the exceptions: the vibration that means something different on one line than another, the customer history that changes the response, the workaround that looks inefficient until you understand why it exists.
If the people who know those things hand a requirements document to a technical team and walk away, the project can be perfectly engineered and still be wrong.
What people ask me
The technology question usually arrives before the operating question.
- Which model should we use?
- Should we build an agent or a workflow?
- Do we need a consultant or an engineer?
- How quickly can we automate this?
What a lot of people seem to think
Pick the best tool, describe the current process, and ask the technical team to automate it.
How I see it
Start with the last step. Name the outcome, the decision, the owner, and the test for good. Then keep the expert inside the workflow while it changes.
Start with the last step
You cannot delegate what you cannot describe.
If you cannot tell an autonomous car where you are going, it cannot choose a useful route. People often open an AI tool at the beginning of a problem and start typing. The system rambles, the answer disappoints them, and they decide the technology is not ready.
The better move is to begin at the end. What should exist when the work is done? A scored shortlist? A recommendation with named evidence? A proposal ready for review? A signed contract that can be routed? What makes it good? What makes it unsafe? Who can approve it?
Those are not technology questions. They are the expert’s job.
My working rule is simple: if I cannot describe what good looks like well enough for someone else to check the work, I am not delegating. I am hoping.
That is true whether the delegate is a person or a machine. AI simply makes the gaps in the instruction more immediate and less polite.
Why the usual handoff fails
Most implementation plans are designed like a relay race.
The operator explains the problem to a consultant. The consultant turns it into a deck. A product manager converts the deck into requirements. An engineer converts the requirements into a system. A trainer later explains the system back to the operator.
Every handoff is reasonable. Every handoff also loses context.
By the time the first user tests the result, the frustration, workaround, relationship history, and unstated standard that made the original problem important have been translated several times. The last person in the relay is holding the baton, but not always the reason for the race.
The forward-deployed model shortens that chain. It puts the person responsible for understanding the real workflow close enough to the build that the team can test assumptions while they are still cheap to change.
The Forward-Deployed Expert
The title matters less than the accountability.
I use Forward-Deployed Expert, or FDX, for a domain-experienced operator who works inside the client’s real workflow and is accountable for business fit, expert quality, adoption, and outcome.
That does not make the role anti-engineering or "no code." A hard deployment may need a Forward-Deployed Engineer, or FDE, beside the FDX. The FDE protects architecture, integration, security, reliability, and production performance. The FDX protects whether the right thing is being built and whether it works for the people whose judgment gives the workflow value.
Where the roles sitDeeper in the client workflow ↑More production engineering required →ConsultantFDXBusiness fit + expert qualityFDEProduction engineeringCore engineer
ConsultantModerate workflow depthLower engineering depthFDXHigh workflow depthModerate engineering depthFDEHigh workflow depthHigh engineering depthCore engineerLower workflow depthHigh engineering depth FDX: accountable for business fit, expert quality, adoption, and outcome.
FDE: accountable for architecture, integration, reliability, and production performance.
The best version is often a pair: one person keeps the system honest about the business; the other keeps it honest about production.
Why the decision matters
The wrong team can make ambiguity more expensive.
A consultant without delivery ownership
may explain the opportunity clearly while leaving the hardest translation for someone else.
An engineer without domain depth
may build exactly what was specified when the specification never captured the real standard.
An expert without technical fluency
may protect the craft but never convert it into a system other people can use.
From automation to additive intelligence
The goal is not only to do the old work faster.
I find it useful to separate AI opportunities into two buckets.
- 1
Automate what you already do
Real value, measurable savings, and usually a ceiling. Once everyone can do it, the savings become part of the market.
- 2
Enable what you could not do before
Research the expert would not have completed, monitor more signals than a person could hold, surface angles the team would have missed, and create useful work at a new frequency or scale.
Forward-deployed work is especially valuable in the second bucket because the technology needs a live connection to expert judgment. Otherwise the system scales output without reliably scaling the insight behind it.
The second-brain test
A useful memory does more than store documents.
When the expert leaves the room, what survives?
A folder of prompts is not an operating memory. Neither is a transcript archive. The system has to preserve why a rule changed, which source controlled, who corrected the answer, what required approval, and whether the action produced the intended result.
That is how the work can compound. The tenth use should be informed by the authorized lessons from the first nine. If every interaction starts from zero, the workflow may be automated, but the intelligence is not compounding.
This is the infrastructure question Uru is designed to address: trusted sources, verified operating memory, reusable artifacts, governed workflows, human approvals, and outcome learning.
What good should leave behind
The client should become more capable, not more dependent.
01A clearer standard
The team can describe good work, the exceptions that matter, and the boundary of human judgment.
02A working system
Sources, memory, artifacts, tools, approvals, and handoffs function together in the real environment.
03Named ownership
Everyone knows who operates, reviews, approves, acts, and escalates.
04An evaluation set
Representative cases expose whether the system is improving or only becoming more fluent.
05Measured learning
The team can see what changed, what failed, and which lesson belongs in the next version.
What I would not do
Five ways to make an AI implementation sound better than it works.
- Do not start with the tool. Start with the endpoint and the workflow that produces value.
- Do not automate an ambiguity. Speed does not repair a standard the business has never made explicit.
- Do not confuse fluency with quality. Test representative cases, edge conditions, and known failure modes.
- Do not separate adoption from design. Users need to shape the system while their feedback can still change it.
- Do not create permanent dependence. If the client cannot operate and improve the system, the engagement did not finish.
Where this lands
Define the role. Diagnose the constraint. Build the operating layer.
The neutral definition belongs on ExpertLedBusiness. The implementation conversation belongs with Ignition Forward. The operating infrastructure belongs with Uru.
My role here is to make the decision easier to see: whose judgment has to be present, what each person is accountable for, and what the organization should be able to do when the outside team is gone.
The goal is not to remove the expert from the work. It is to put expert judgment at the right moment, then leave the organization better able to operate without them.