TL;DR: In this episode of FDE Talks, the writer behind FDE Hub shares a pattern he saw repeatedly while working across more than 15 enterprise AI deployments: the stakeholder most eager to help can unintentionally give you an incomplete picture of the workflow. He calls it the champion trap. The fix is simple to describe and easy to skip: before you freeze the architecture, triangulate the workflow across the sponsor, the operators, and the system of record.
Listen to the full conversation →
Enterprise AI failures do not always begin with the model. Sometimes the model works perfectly against a workflow that does not actually exist.
That was the lesson from an accounts payable automation project for a global music label operating across the UK, US, and the Netherlands.
On paper, accounts payable looked like a straightforward automation problem. In reality, the company’s suppliers were music artists. Invoices arrived as PDFs, Word documents, Excel files, and occasionally handwritten notes. The company dealt with tens of thousands of suppliers, roughly 150 possible approval paths, and seven levels of approval hierarchy.
One invoice captured the problem particularly well. The system rejected it because the purchase order number was missing. An operator asked the supplier to correct it. The invoice came back with the literal words “purchase order” entered where the number was supposed to be.
That is the distribution your production system has to survive.
The workflow you were told is rarely the whole workflow
The project had what every FDE wants: a strong internal champion. She was senior, responsive, invested in the outcome, and willing to help the team navigate the organization. The project mattered to her personally.
So the team built closely with her. For two months.
Then they put the system in front of the people actually processing invoices, and discovered something important: operators were changing data directly inside the ERP. Nobody had mentioned it.
The architecture had assumed data only needed to flow into the ERP. In reality, the system needed to detect and reconcile changes coming back from it. A one-way integration had to become a two-way sync.
The team had misunderstood the business process rather than any technical requirement.
That is the champion trap.
The champion is essential and still insufficient
None of this argues against having an executive sponsor. A strong champion is often the reason an enterprise deployment survives at all. They create access, remove blockers, secure resources, and protect the project when priorities change.
But there is a fundamental difference between overseeing a process and operating that process all day.
The champion can explain how the process is intended to work. The operator knows what happens when the PO is missing, when the supplier sends an Excel sheet instead of a PDF, when someone edits the ERP directly, or when the ten-year-old approval spreadsheet contains an exception nobody remembers documenting.
Both perspectives are true. Neither is sufficient by itself.
A mistake here quickly becomes an architecture decision. The wrong understanding of the workflow changes your integration pattern, data model, exception handling, human review strategy, and eventually the level of autonomy you can safely support.
That is why discovery needs triangulation.
Triangulate before you freeze the architecture
For any workflow you plan to automate, check three versions of reality:
Sponsor: what should happen. This is the designed process: policies, documentation, kickoff decks, and management expectations.
Operators: what usually happens. This is the lived process: workarounds, exceptions, undocumented decisions, and institutional knowledge.
System of record: what actually happened. Logs, transactions, edits, timestamps, and historical records show the behavior that survived contact with reality.
You understand the workflow once all three versions have been compared and the discrepancies explained.
In the music label engagement, inspecting ERP history earlier could have exposed the direct edits before two months of architecture had accumulated around the wrong assumption.
That is a discovery practice worth making explicit: do not freeze the architecture until you have compared the process as designed, the process as lived, and the process as recorded.
Ask for the ugly data first
There was another useful discovery technique in the conversation. Ask operators: “Show me the weirdest examples you have.”
Skip the clean demo cases. Ask for the broken invoices. Missing values. Strange formatting. Old workarounds. Inputs that technically violate the schema but still arrive every week.
Those examples are the beginnings of your evaluation set.
The guest also uses what he calls the PhD intern framework: ask an operator to explain the workflow as though they were onboarding someone with multiple PhDs but zero knowledge of the business.
That framing forces experts to unpack statements such as: “Then it gets approved.”
Who approves it? How do they decide? What happens if the amount is above a threshold? What if the approver is unavailable? What if the supplier data changed? What information makes the operator stop and investigate?
Those hidden micro-decisions eventually become agent instructions, validation rules, escalation paths, and evaluations.
Do this with more than one operator. Otherwise you risk creating a smaller version of the champion trap around one person’s interpretation.
Autonomy is earned in stages
A second story from the conversation shows what happens when discovery gaps survive into production.
A capacity-planning agent had progressed from human-reviewed recommendations toward full autonomy. The remaining error rate was only a few percentage points. But the operators saw those errors immediately. The system was missing constraints they understood intuitively but had never documented. Trust fell.
Instead of continuing forward, the team moved the system back to a more supervised stage. That was the right move.
Autonomy should progress through observed reliability: advisory → human-reviewed execution → greater autonomy. And the direction does not always have to be forward. Moving backward after discovering a new failure mode can be how you earn the trust required to move forward again.
Another deployment from the same portfolio illustrates the difference between building software and deploying it. The sales-order automation took roughly three weeks to build. It took roughly three months before operators trusted it enough to rely on it.
That second number belongs in the implementation plan too.
Don’t automate the spreadsheet just because it exists
The music label project uncovered one more problem. The approval workflow contained roughly 150 possible paths accumulated over years. Initially, the team tried to reproduce them.
Eventually they asked a more important question: do all 150 paths need to exist?
That changed the engagement. Instead of treating the current process as a specification, the team treated it as something that could itself be redesigned. The approval flow was simplified, and that simplification remained valuable beyond the AI project.
This is an important distinction in forward deployed work. If you automate a complicated process without questioning it, you may simply make the old complexity run faster. Sometimes the highest-value technical decision is deciding not to encode part of the existing process at all.
What the FDE actually brings back
The interesting outcome of these engagements went beyond working customer-specific code. Patterns discovered in the field became reusable product primitives: human review, workflows for requesting missing information, configurable approval flows, and better exception handling.
That is one of the clearest expressions of the FDE model. The customer gives you the messy reality. The FDE discovers what is actually generalizable. The product absorbs the reusable pattern.
The reusable asset is the pattern you learned because production behaved differently from the specification.
Before your next enterprise AI build
Pick one workflow your team is automating. Ask the sponsor to describe how it should work. Sit with an operator and watch how it actually works. Then inspect the last few months of transactions, logs, and edits.
Look specifically for disagreement.
Because the most expensive discovery mistake may have nothing to do with the model. It may be confidently building the right system for the wrong workflow.
That is the champion trap. And the best time to find it is before the architecture makes it expensive.
FDE Talks is The AI Runtime’s conversation series about the FDE role and the craft of deploying AI inside real organizations: the architecture decisions, customer dynamics, failures, and lessons that rarely appear in product demos.
