👋 Hey, this is Artem and this is The Blueprint. At WIQ, we spend each day forward deployed at Fortune 500 companies working through the hairy journey of AI transformation.
This issue: why most AI programs discover the process backwards, and what changes when every exception makes the next run better.
We recently spoke with a global retailer that had mapped every customer-support process in Visio. It had Salesforce Service Cloud, Agentforce, Copilot, and roughly 1,400 support agents.
The automation was still stuck.
The problem was access to enterprise services. Every connection the agent needed required a ticket, and those tickets went to teams with huge backlogs. The company had the process maps and the AI tools. The agent still could not reach the systems it needed to do the job.
I've seen a few AI pilots built this way.
I keep seeing versions of this story. An enterprise buys an AI platform, chooses a use case in a workshop, turns an SOP into a prompt, and builds a demo. The demo works because everyone agrees on the example. Then it meets the real company: a custom Salesforce field, a spreadsheet that gets checked before SAP, an approval that changes by region, or a return code only one operator knows how to handle.
That is when the AI program starts learning how the process actually works. One exception at a time, after deployment.
Most AI programs discover the process backwards
The usual AI pilot starts with the intelligence and works backward toward the job.
The team gives the agent an SOP and connects the obvious systems. The first clean case runs. The second needs a permission nobody requested. The third follows a different approval path. The fourth has all the right data, but the operator still checks another system before making the decision.
Each surprise becomes a new ticket, prompt revision, or human workaround. By the end of the pilot, the agent may be better, but most of what the company learned is scattered across the people who rescued it. When the next tool or use case arrives, the process starts again.
This is why companies can run a lot of pilots without getting much better at deploying AI. They are accumulating demos. They are not accumulating an operating record the next agent can use.
The golden path is the easy part.
An SOP describes the clean version of the job
The gap usually appears around the exceptions.
An invoice arrives without the expected purchase order. A customer writes from a different email than the one attached to the subscription. A regional policy changes who can approve a request. Someone checks a spreadsheet before updating the system of record because the spreadsheet is more current.
None of these cases is especially exotic. Put enough of them together and you have the actual job.
The operators already know how to handle most of it. They learned by doing the work, seeing what breaks, and remembering what fixed it. The problem is that their corrections rarely make it into anything an agent can read. They stay in Slack, a ticket, an updated prompt, or someone's head.
So the next run reaches the same edge and acts surprised all over again.
Start with one full cycle of the work
The other approach starts before the agent.
Observe one recurring workflow from beginning to end. Capture the systems people touch, the fields that matter, where the work changes hands, which policies govern it, and where an operator stops to make a judgment. Then decide which steps an agent can run, which systems it can already access, and where a person should still approve.
If you read issue #1, this is the record we call a blueprint. It is built from the work people actually do, then used to brief the agent running that job. The important part is that it stays open after deployment. Every escalation can add another exception path instead of becoming a one-off fix.
We tested this on a customer-cancellation workflow recently. The agent loaded the blueprint, checked its tools, found the relevant emails, and asked the operator which cancellations to process. The first one ran cleanly.
The second customer had written from a different email than the one attached to the subscription. The agent stopped and asked for help. The operator told it to draft a request for the missing account information instead of confirming the cancellation.
The agent added that instruction to the blueprint and ran the case again. The next time the same mismatch appears, it already has the rule.
The fix is now part of the next run.
The difference is what happens after the first mistake
Both approaches meet exceptions. Enterprise operations is full of them.
In the first, the exception sends the team backward. Someone patches the prompt, opens another ticket, or puts the work back with the operator. The lesson fixes one run.
In the second, the correction goes back into the description of the job. The next run starts with more context than the last one, and the agent gradually takes on more of the process as the exception library grows.
The first cycle keeps testing whether AI is ready for the company. The second makes the company progressively more legible to AI.
We'll spend the hour on what happens after the pilot.
If you're leading AI inside a large company, join Praveen Akkiraju, Swamy Kocherlakota, and me for Learnings from $4B invested in Enterprise AI. We'll compare where programs stall after the pilot, how teams select high-value workflows, and how they measure success.
The Blueprint. Stories and lessons on AI transformations from founders and operators making it happen.