Most AI projects stall not because the technology failed but because nobody scoped what the uncertainty actually was. You can’t fix that with a longer proposal or a better vendor demo, you fix it by treating the unclear parts as the first thing you work on, not the thing you paper over to get a contract signed.
The agencies that get hired repeatedly for AI work aren’t the ones with the longest capability lists. They’re the ones who make it safe to move before the answers are locked in. That’s a skill. It doesn’t get listed on proposal decks, but it’s what clients are actually buying.
The Uncertainty Isn’t Going Away, So Stop Waiting for It To
Sixty-three percent of SMBs that paused AI projects in 2024 cited “needing more clarity” as the reason. Most never restarted. Waiting for clarity on AI is structurally identical to waiting for certainty before launching a product, the certainty never arrives, and the market moves without you.
The issue isn’t that AI is unclear. It’s that most agencies position themselves as problem-solvers, which implies problems eventually get solved and then the engagement ends. Uncertainty doesn’t work that way. It’s not a phase to get through. It’s the permanent operating condition of AI in a live business context.
What “Moving Through Uncertainty” Actually Means
It means taking action before you have full information, and doing so without pretending the gaps don’t exist. It means acknowledging publicly to a client: “We don’t know exactly how this will perform at scale, so we’re going to build the instrumentation first.”
A concrete example: a 12-person accounting firm wanted to automate client document intake. The vendor they first approached quoted a full solution, 14 weeks, fixed scope. The problem was that no one knew how inconsistent the client’s incoming documents actually were. Designodin scoped a two-week diagnostic instead: process 200 real documents, measure the failure rate, classify the edge cases. The diagnostic revealed 34% of documents required a format not in the original spec. That finding reshaped the entire build. The firm spent £4,200 on the diagnostic. It would have cost £28,000 to discover the same problem six weeks into a full build.
That diagnostic phase, where you know less than you need to, act anyway, and treat the unknowns as information, is the service. It’s not the pre-service.
Why Clients Don’t Ask for This Directly
Clients don’t ask for “help navigating uncertainty.” They ask for chatbots, automations, integrations, dashboards. The request is always for the artifact. The need underneath it is almost always: “We don’t know what we’re doing here, help us not make an expensive mistake.”
If you respond to the artifact request and ignore the need underneath it, you’ll build the wrong thing. You might build it well. It still won’t work. The client will be disappointed and won’t know why. You’ll blame the client’s internal adoption. The client will blame your deliverable. Both of you will be wrong.
Surfacing the real need, the uncertainty, is a diagnostic act. It requires asking questions that feel uncomfortable because they imply the client doesn’t have a plan yet. They usually don’t. That’s fine. Name it.
The Wrong Way Agencies Handle It
The typical agency response to AI uncertainty is to add more discovery time to the front of a project, produce a 40-page strategy document, and then proceed with the same fixed-scope contract they would have used anyway. The document creates the appearance of having resolved the uncertainty. It hasn’t.
What that document usually contains: a market overview the client could have Googled, a list of “recommended tools” based on whoever the agency has a reseller relationship with, and a phased roadmap that assumes every phase will validate the previous one. It won’t. Real AI projects are iterative in ways that break linear roadmaps inside the first sprint.
The document isn’t dishonest exactly. It’s a confidence artefact. Its purpose is to make the client feel certain enough to sign, not to actually reduce uncertainty.
What the Right Model Looks Like
Good AI work in uncertain conditions has three characteristics.
First, it’s staged with real exit points. Not “Phase 1, Phase 2, Phase 3” where each phase assumes the last succeeded. Actual checkpoints where the client can stop without sunk-cost pressure, because the work done to that point produced standalone value, data, a working prototype, a documented decision framework.
Second, it treats failure as output. If a test shows that an AI approach won’t work for this client’s data quality or use case, that’s a result. It should be documented, billed for, and handed over. Clients who receive clear “this won’t work” outputs trust the agency more than clients who receive unclear “it almost works” outputs after six months.
Third, it separates the question from the build. Most AI projects try to answer the question and build the solution in the same sprint. That’s how you end up with a system built to answer the wrong question. Answer the question first, cheaply, with minimum viable tooling. Build the solution after you’ve confirmed the question was right.
If your current agency or vendor isn’t structuring AI work this way, ask them why. If they can’t answer clearly, that’s your answer.
What Clients Owe the Agency in This Model
This is a less comfortable thing to say, but it’s true: clients have to provide real access to real data during the uncertainty phase. Not sanitised sample data. Not a spreadsheet someone cleaned up before the meeting. Actual operational data, including the messy records, the exceptions, the cases that broke the last system.
Without it, no agency can accurately scope the real problem. Every estimate becomes optimistic by default because it’s based on the clean version of your business, not the actual one.
The clients who get the most out of AI work are the ones who say “here’s everything, including the parts we’re not proud of” in week one. That openness shortens timelines and improves outcomes. It’s not a soft thing. It’s a material factor in whether the project works.
When AI Uncertainty Is Actually Competitive Advantage
Here’s the counterintuitive part. The businesses that move while uncertain, with the right structure around them, end up ahead of the ones that waited for clarity.
A mid-size e-commerce retailer running a custom WooCommerce store moved on an AI-assisted returns classification system in Q3 2024 when the tooling was still rough. They spent four months iterating. The system now processes 83% of returns without human review. Their nearest competitor waited for “proven solutions” and started the same project in Q1 2025. They’re still in vendor evaluation.
Moving first in uncertainty isn’t reckless if the structure around it is right. Small bets, clear instrumentation, real exit points. That’s not chaos, that’s how product companies have shipped software for 30 years. AI projects aren’t different.
FAQ
Is AI really that different from other technology projects?
In scope and tooling it often isn’t. The difference is that AI outputs are probabilistic, the same input doesn’t always produce the same output. That means QA and testing work differently, and edge cases are harder to predict in advance. Those differences require a different project structure, not necessarily more time or money.
How do you charge for work when the scope is genuinely unclear?
Time-and-materials for exploratory phases, fixed-price for build phases once the scope is validated. Any agency quoting fixed-price on work that begins with “we don’t fully know what we’re building” is either guessing or padding the estimate. Ask them directly which one.
What should the first two weeks of an AI project look like?
Typically: a structured assessment of the problem, the existing data, and the failure modes, before any build starts. Outputs should include a documented scope, a list of what you still don’t know, and a recommendation on whether to proceed and in what form. If an agency skips this phase, be cautious.
How do we know if an agency can actually handle AI uncertainty?
Ask them about a project that didn’t work as scoped. What happened? What did they deliver? How did they communicate the problem? Agencies with real AI experience have failure stories, and the good ones treat those stories as evidence of competence, not embarrassment. Agencies with no failure stories either haven’t done much or aren’t being honest.
Should we wait for AI tools to mature before starting?
For most use cases, no. The tools mature faster than most planning cycles. If you start planning for a tool that exists today and wait 18 months to implement, you’ll be implementing against a tool that’s been superseded. The more useful frame is: what’s the smallest thing we can test in the next six weeks that would tell us something real? Start there.
What if our internal team isn’t technical enough to evaluate AI options?
That’s exactly when you need outside structure, not to be told what to buy, but to have someone facilitate the right questions before you commit budget. A one-day structured workshop with a senior technical advisor costs far less than a procurement process that buys the wrong tool. Evaluating AI options is a service in itself, separate from building anything.
If you want to talk through what this looks like for your operation, start a conversation. We’ll be direct about what’s worth scoping and what isn’t. See how we approach this kind of work at designodin.com/ai.