The project that never shipped
The most expensive AI project I have ever seen was one that never went live. A mid-size distribution company spent eleven months and a significant budget building what they called an intelligent operations platform. It was going to handle demand forecasting, carrier selection, invoice reconciliation, warehouse slot optimization and customer exception management all at once. It never shipped. The integrations kept growing, the model kept needing retraining, the stakeholders kept adding requirements, and eventually the budget ran out and the team moved on.
That story is not unusual. It is closer to the norm than most vendors will admit. The reason is almost never the technology. The reason is scope.
One workflow is not a compromise, it is a strategy
When I start a new engagement I ask one question before anything else: what is the single most painful manual decision your team makes on repeat, every day, where a wrong answer costs you real money or real time? Not a category of decisions. One specific decision.
In a manufacturing context that might be: should this production order be expedited or held based on current material availability and the customer's delivery window? In finance it might be: does this vendor invoice match the purchase order closely enough to approve for payment without human review? In field operations it might be: which technician should be dispatched to this job given skill, location, and parts on hand?
Each of those is one decision. Each one is bounded. Each one has inputs you can name and an output you can measure. That is the shape of a first version that ships.
Why teams resist cutting scope and why they are wrong
I understand the pressure. A technology leader has fought for budget and executive attention. They need to show ROI that justifies the investment. So the instinct is to pack in as much value as possible to make the business case look bigger. The problem is that a bigger scope does not produce a bigger business case. It produces a longer timeline, more integration risk, more data quality problems, and a higher chance of shipping nothing.
There is also a subtler trap. When you automate five workflows at once, you cannot tell which one is working and which one is causing problems. You cannot tune the model against a clear outcome. You cannot build the operator trust that comes from watching one thing work reliably for thirty days before you expand it.
I have shipped agents that went from scoping call to production in six weeks. Every single one of them started with one workflow, one decision, one outcome. The ones that took six months started with a slide deck full of use cases.
How to find the right first workflow
The right first workflow has four properties. It is high frequency, meaning it happens dozens or hundreds of times per week, not once a month. It is currently manual, meaning a person is doing it by reading something, making a judgment, and taking an action. It has a measurable outcome, meaning you can look at the result and say whether the decision was right or wrong. And it is self-contained, meaning the inputs and outputs do not require rebuilding your entire data architecture to access.
In a distribution operation I worked with, the team was manually triaging inbound customer exception emails, reading each one, deciding whether it was a shipment delay, a damage claim, a billing dispute or a general inquiry, and routing it to the right queue. About four hundred emails a day. The decision had four possible outputs. The inputs were the email text and a lookup against the order management system. That is a first workflow. We had it running in production in under five weeks.
Notice what we did not do. We did not also automate the response drafting, the SLA tracking, the escalation logic, or the reporting dashboard. We did one thing. The team could see it working. They trusted it. Three months later we extended it. That is how you build.
One decision means one clear success condition
A scoping mistake I see constantly is defining success as the system doing something rather than the system producing a measurable result. Saying the agent will classify invoices is not a success condition. Saying the agent will correctly approve or flag invoices for human review with ninety percent accuracy on a labeled test set, reducing average processing time from four hours to under thirty minutes, is a success condition.
When you have one decision, you can write that sentence. When you have ten decisions bundled together, you cannot. And if you cannot write the success condition before you build, you will not be able to evaluate the system after you build, and you will not be able to defend the investment when someone asks whether it worked.
I also want to be direct about something. No model is perfect. Every production AI system I have shipped makes mistakes. The question is whether the mistake rate is low enough and the errors are recoverable enough that the system produces net value. You can only answer that question if you are measuring one thing.
What to do with everything else on the list
When I tell a team we are cutting to one workflow, the immediate reaction is usually: but what about all the other things we need? My answer is always the same. Write them down. Put them in a backlog. Prioritize them. And then agree that none of them are in scope for version one.
This is not throwing away value. It is sequencing value. A finance team I worked with had a list of fourteen automation ideas when we started. We picked one: automated matching of goods receipts to purchase orders with a confidence score that determined whether the match went straight to payment or went to a reviewer. That shipped in seven weeks. The team saw it work. They saw the manual review queue shrink by sixty percent on matched invoices. That result funded the next three items on the list.
If you try to ship all fourteen at once you are not moving faster. You are moving slower and betting everything on a big launch that may never come.
The practical takeaway
Before your next AI scoping session, do this. Take your list of automation ideas and force rank them by these four criteria: frequency, current manual effort, measurability of outcome, and data accessibility. Take the top item. Write one sentence describing the decision the agent will make, one sentence describing the inputs it will use, and one sentence describing how you will know it worked. If you cannot write all three sentences in under ten minutes, the scope is still too wide.
Ship that. Measure it. Then come back to the list.
The teams I have seen move fastest are not the ones with the biggest budgets or the most sophisticated models. They are the ones who were willing to be ruthlessly small on version one. Small scope ships. Shipped systems build trust. Trust unlocks the next project. That is the whole game.