Here's an unfashionable opinion for anyone currently being pitched an "agentic AI" solution: most of the time, you don't need one. What you need is thirty minutes with a whiteboard and someone willing to admit the process was never as complicated as everyone assumed.
We saw this play out recently with a DDQ response process. The firm wanted an AI agent that could read incoming due diligence questionnaires, match them against a knowledge base, and flag any gaps. Reasonable enough on paper. But once we actually mapped the workflow, it turned out the vast majority of questions fell into a handful of predictable categories, each with a clear rule for how to answer them. A five-tab spreadsheet with a proper checklist and a bit of structure handled almost all of it, reliably, every time. The agent only earned its keep on a small residual slice: genuinely ambiguous questions that needed judgement. Buying the flashy tool first would have meant paying for an agent to do a spreadsheet's job.
The numbers back this up
MIT's NANDA initiative studied generative AI pilots across companies in 2025 and found that 95% of them failed to deliver any measurable financial return. Coverage of the study pointed to a consistent pattern behind the failures: companies were skipping the unglamorous work of actually defining the workflow before deploying the tool, essentially trying to avoid the friction of proper process design.
RAND's research tells a similar story from a different angle. Their 2024 study found that roughly 80% of AI projects fail, twice the failure rate of ordinary IT projects, and traced much of that back to the same root cause: teams moving straight to the tool without doing the groundwork first.
Two different studies, two different methodologies, landing on the same conclusion. The tool was rarely the problem. The thinking that was supposed to happen before the tool got bought was the problem.
The order of operations that actually works
None of this means avoid AI. It means do the boring bit first. In practice, that looks like four steps, in this order and not skipped.
Start by mapping the workflow properly. Every decision point, every exception, every handoff between people or systems. This sounds obvious and gets skipped constantly, because it's slower and less exciting than picking a tool.
Next, classify each step. Is it deterministic, meaning a clear rule can handle it every time? Or is it judgement based, meaning it genuinely needs reasoning over something ambiguous or unstructured? Most workflows, once you look closely, turn out to be mostly the former with a small amount of the latter.
Then pick the simplest tool that handles the deterministic parts. That's very often a well-built spreadsheet, a rules engine, or a straightforward automation, not an AI agent. Nobody gets excited pitching a spreadsheet, but excitement isn't the point. Reliability is.
Only then reach for an agent, and only for the part that's left over: the genuinely ambiguous slice that can't be reduced to rules, where reasoning over messy input is actually the job, not a workaround for a process nobody bothered to design properly.
A quick way to check yourself
If you're weighing up whether something needs an agent or just needs a properly designed process, two questions do most of the work.
What's the cost of a wrong answer here, and can it be checked before it causes harm? If a mistake is cheap and easy to catch, you have more room to experiment. If it isn't, you want something predictable and auditable doing the heavy lifting.
Does this step genuinely change based on unstructured input a person would otherwise have to read and interpret? If the input is always structured, or always falls into the same handful of shapes, that's not a reasoning problem. That's a rules problem wearing an AI costume.
If the honest answer to both is "not really," you don't have an agent problem. You have a process design problem, and no amount of extra AI sophistication fixes that.
Where an agent genuinely earns its place
To be fair to agents, because this isn't an anti-AI argument, there are cases where one is exactly the right call. Picture a portfolio monitoring agent watching for trigger events across a portfolio: covenant breaches, valuation moves, concentration limits being approached. The inputs here are genuinely unstructured and varied, arriving from different sources in different formats, and the reasoning required to spot what matters is the actual point of the exercise, not a symptom of skipped process work. That's a legitimate use of an agent, and it looks nothing like the DDQ example above.
The difference between the two isn't the technology. It's whether someone did the process mapping first and made an honest call about what kind of problem they were actually solving.
Do the mapping before you buy anything
The pattern behind that 95% failure rate isn't a mystery, and it isn't really about AI at all. It's what happens whenever anyone buys a solution before properly understanding the problem. An AI audit exists precisely to do that mapping work up front, so you find out whether the answer is a spreadsheet or an agent before you've spent the budget on the wrong one.
Sources: MIT NANDA, State of AI in Business 2025 (coverage), RAND Corporation, "Why AI Projects Fail and How They Can Succeed"