Fix the lowest broken layer first
Pilot purgatory has a specific shape. The demo worked. The champion is enthusiastic. Leadership approved a budget. Six months later, the workflow still runs the old way for eighty percent of cases, the AI output gets checked manually anyway, and nobody can explain why scaling stalled. The team blames the model. Something underneath broke first, and nobody fixed it before stacking more AI on top.
#The Readiness Stack in order
The Readiness Stack has five layers — Data, Process, People, then Tools and Decision. Each depends on the ones below it. If you need the full framework and why readiness is operational work, start with AI readiness is an operations question. This article is about using the stack to escape pilot purgatory.
Walk any workflow up from the bottom. The lowest layer where the answer is "no" is where your work belongs — not the layer that is easiest to buy software for.
Data that lives only in someone's head makes every layer above it irrelevant. A process with eighteen undocumented variations makes every prompt a guess. A workflow with no owner makes every rollout die silently three months in. Tools that require copy-paste make the AI another tab in the copy-paste chain. Output that nobody acts on is theater regardless of accuracy.
#Why Data, Process, and People come before Tools and Decision
The stack splits into two tiers. The first three layers are foundation. The last two are activation.
Foundation work is operational discipline. It does not require a vendor contract or a model API key. It requires someone to look honestly at how work actually runs and close the gaps that humans have been absorbing for years.
Data failures show up everywhere and get misdiagnosed as tool problems. "We have the data — it is all in our system" is a culture claim, not a readiness claim. The test: can you produce a structured export of the relevant fields for any record in under five minutes without asking a person? If the accurate version of the truth lives in Sarah's memory, in PDFs nested in email threads, or on a spreadsheet built for one project that everyone now relies on — Layer 1 is broken. No agent framework fixes that.
Process failures are habits disguised as workflows. A human handed an ambiguous process asks someone, pattern-matches on last year's case, makes a judgment call, and remembers they made it. The work gets done. An AI handed the same process produces an answer based on what is written down. If what is written down does not cover the real case, the AI guesses confidently. Confidently is the dangerous word. The firm that says "our process works fine" and finds AI "unreliable" is discovering that the process was leaning on humans to absorb inconsistency. AI does not absorb. It exposes.
People failures are the most skipped layer because "people are involved" is not the same as "someone owns it." Ownership means one person can decide the workflow will change and that change will stick. When you ask "who owns this process?" and the answer is a department, Layer 3 is broken. Diffuse workflows reject automation silently — the tool gets installed, training happens, the rollout calls itself successful, and three months later no one uses it. There was no one whose job was to make sure they did.
Tools and Decision matter. They matter after the foundation holds. Layer 4 — programmatic data exchange between systems — is where copy-paste tax gets eliminated. Layer 5 — a named decision that changes because of AI output — is where leverage lives. But starting at Layer 4 or 5 while Layer 1 is broken is how pilot purgatory starts.
#What pilot purgatory looks like layer by layer
Each broken layer produces a recognizable stall pattern.
Data broken: The pilot runs on hand-picked examples. Production inputs are messier than demo inputs. The model hallucinates client names, misreads amounts, or pulls context from the wrong record. The team responds with prompt engineering instead of fixing data reachability. Accuracy improves on test cases and fails on real ones.
Process broken: The pilot handles the standard case. Production surfaces the fourteen exceptions nobody documented. Each exception becomes a custom rule in a Slack thread. The engineer who built the pilot becomes the exception router. Scaling means hiring more engineers, not training operations.
People broken: The pilot has a champion. The champion is not the workflow owner. When the champion moves to another project, adoption flatlines. Exceptions go unanswered. Leadership asks why the investment did not stick. Nobody can point to the person accountable for making it stick.
Tools broken: The AI produces good output. A human copies it into the next system anyway. The workflow is faster at generation and the same speed at execution. Total time saved: negligible. Leadership wonders why the ROI math does not work.
Decision broken: The AI generates reports, summaries, or drafts that look impressive. Nobody's behavior changes. The approval still happens in the same meeting. The flag still gets ignored. The output gets pasted into slides and forgotten. The pilot proved AI can do X. It never proved anyone would act differently because it did.
If you recognize your company in one of those patterns, you have found your layer. Stop there. Do not add another tool on top.
| Broken layer | Stall pattern | First fix |
|---|---|---|
| Data | Good on demos, fails on real inputs | Make fields programmatically reachable |
| Process | Standard case works, exceptions swamp engineering | Write actual rules, document branches |
| People | Champion leaves, adoption dies | Name one owner with authority |
| Tools | Fast generation, same manual execution | Replace copy-paste with connections |
| Decision | Impressive output, unchanged meetings | Tie output to a decision someone makes |
#The invoice approval walkthrough
Invoice approval at a fifty-person services firm is the workflow we use to make the stack concrete — because it is boring enough to be universal and complex enough to touch every layer.
Data: Invoices arrive as PDFs in email. Matching data lives in the accounting system, but client tier and approval routing live in the CRM. Neither system can read the other without a person. Layer 1 breaks at "reachable."
Process: The written rule says invoices over five thousand dollars need leadership sign-off. The actual rule has four branches: leadership by default, controller sign-off for tier B clients, Marcus for long-standing vendors, and a different threshold at end-of-quarter. Layer 2 breaks at "describable."
People: Finance and Operations both touch the workflow. When you ask who owns it, you get a meeting. Layer 3 breaks at "one named owner."
Tools: The approver opens the PDF, checks the CRM in another tab, copies the PO number into the accounting system, and clicks approve. Layer 4 breaks at "exchange without copy-paste."
Decision: The AI could flag mismatches. But the approval meeting still happens every Thursday regardless of what was flagged. Layer 5 breaks at "changes behavior."
The lowest broken layer here is Data — because the invoice is not digitally readable and client context is not queryable together. Fixing Layer 5 first (building a mismatch flag) produces output nobody acts on. Fixing Layer 1 first (making invoice data and client tier reachable by a system) unlocks everything above it.
Walk your own painful workflow the same way. Be honest about which layer breaks first, not which layer is easiest to fix.
#What fixing each layer actually involves
Foundation fixes are unglamorous and high-leverage.
Data: Pick one workflow. List every piece of information the AI would need. For each piece, write where it lives today and whether a system can retrieve it programmatically. Consolidate, export, or connect until the answer is yes for the fields that matter. This is a project, not a meeting.
Process: Write the rules on one page — the actual rules, not the executive summary. Separate deliberate variation (tier A vs. tier B follow different paths) from accidental variation (different people do it differently). Document the exceptions. Add them to the rules. If the person who runs the workflow left tomorrow, the documentation should produce correct results within a week.
People: Name one owner. Give them authority, not just responsibility. Tell the people who execute the workflow who the owner is. When AI arrives, the owner decides whether it stays after ninety days.
Activation fixes come after.
Tools: Map every copy-paste step between systems. Replace each one with a connection — API, webhook, export pipeline. The copy-paste tax you have been paying in salary and errors is the cost of Layer 4 gaps.
Decision: Name the specific decision the AI should change. Name the person who makes it today. Describe how that decision would be made differently with the AI's output. If the AI vanished, someone should notice because a real decision got harder. If nobody would notice, you do not have a use case.
For the full layer-by-layer reference — including scorecard exercises and the smell of each broken layer — see the Ready Enough field guide. For why readiness is operational work rather than a technology bet, start with AI readiness is an operations question.
#Ninety minutes to find the floor
Block time with the person who runs the stuck workflow — not the person who approved the pilot budget. Walk one real case from trigger to finish and mark the first layer that fails: unreachable data, undocumented variation, no named owner, copy-paste between systems, or output nobody acts on.
Write that layer on a whiteboard. That is the project. The new tool, the model upgrade, and the agent framework wait.
If Data, Process, or People all score weak, do not fund AI on that workflow yet. Fix the operational foundation. The work pays for itself without AI — and when the layer holds, the automation you build on top is the one that scales instead of joining the graveyard of successful demos.