When AI deployment consulting first gained real traction, the value was mostly in strategy — helping leadership understand what was realistic, where to start, what failure looked like. That made sense. The space was new. Patterns weren’t established, and someone had to hold the map.
A lot has changed. The patterns exist now. The tooling is mature and mostly free. And yet the consulting spend keeps climbing. So it is worth asking, more carefully than most organizations do before signing: what exactly are we paying for?
The five problems, and the ratio that matters
When you look honestly at what goes wrong in enterprise AI deployments, five hard problems keep surfacing: context compression, codebase instrumentation, linting as architectural enforcement, multi-agent coordination, and the specification problem.
A quick gloss on each. Context compression is about keeping an AI model’s working memory coherent across a long session — preventing it from “forgetting” what it decided two hours ago. Codebase instrumentation means making your software give an AI agent fast, reliable feedback without requiring someone to explain how the repo works. Linting as architecture is the practice of encoding your design rules as automated style checks — so an agent can self-correct the same way a developer corrects against compiler errors. Multi-agent coordination is splitting work across a lead agent and a set of specialized sub-agents, each getting a fresh context window per task.
All four of these are difficult. They also have published solutions. Benchmark-tested approaches to context compression. Documented frameworks for assessing codebase readiness, with gaps that typically close in days rather than months. Research on linting as an executable specification. Production-tested orchestrator patterns.
The fifth problem — specification — is something genuinely different, and it deserves separate treatment.
The ratio embedded in that list is what every engineering leader should internalize before a procurement conversation: four problems you can address with public tooling and focused engineering effort, one that may require outside expertise. That ratio should shape the size and shape of the check you write.
The one that’s actually hard
The specification problem shows up most sharply in regulated industries: financial services, healthcare, insurance, legal. When you deploy an AI agent in those environments, you have to define what acceptable behavior looks like for a system that produces probabilistic outputs — outputs that aren’t identical each time. You have to maintain that definition as regulations change, as jurisdiction-specific rules diverge, as edge cases accumulate.
The rules governing that behavior live outside your codebase. They’re not always written down in a form a machine can check directly. And they change in response to regulatory shifts that no software library tracks.
This is the part worth paying for when you genuinely need it. The domain expertise — knowing what a compliance rule means at the boundary of a difficult edge case, understanding what a regulator actually cares about in practice — takes years to develop and isn’t on GitHub.
What turns up in a lot of consulting proposals, though, is the other four problems bundled in alongside the fifth one, billed at the same rates, wrapped in proprietary methodology that turns out to be a thin layer over the same open-source tooling your team could learn in a sprint.
What the ROI numbers are saying
The deployment failure rates turning up across engagements are striking. Roughly two-thirds of enterprises haven’t scaled AI past isolated pilots. Around a quarter of AI initiatives deliver their expected return on investment. More than half of chief executives in large surveys report no financial benefit from their AI spending.
That does not read as a consulting failure, exactly. And it’s not really a tooling failure — the tools are genuinely there. It’s mostly a sequencing problem. Organizations reach for platforms, frameworks, and external expertise before they’ve done the prerequisite work of making their codebase ready for an agent to actually operate in.
If an outside contractor couldn’t get oriented in your codebase and ship a bug fix on day one, an AI agent is going to struggle for the same reasons. The codebase doesn’t give useful feedback. The naming is inconsistent. Tests are slow or absent. There’s too much tribal knowledge baked into implicit conventions that nothing enforces. Fixing that is engineering work, and it belongs to your team — not because it’s beneath a consultant, but because it requires intimate knowledge of your system.
The organizations that make genuine progress tend to go in order: make the codebase legible and fast to iterate in, instrument it for agents, work out coordination patterns, then bring in domain expertise specifically for the specification layer if you’re operating in a regulated space.
Before you sign anything
The most useful exercise before any AI deployment proposal is to read it and ask: which of the five hard problems is this actually addressing? If the bulk of the work is context compression, codebase instrumentation, linting, or multi-agent coordination — your team can learn and execute those with public resources. If the work is genuinely about navigating domain-specific compliance complexity, the price tag is probably justified.
The gap between “things worth buying” and “things that are free if you know where to look” will keep shifting as the field matures. Right now, that gap is wider than most procurement conversations acknowledge. Narrowing it — in your own team’s understanding, before you’re sitting across from a vendor — is probably the highest-leverage thing you can do to make sure the spend that remains actually delivers.
Text summarized and optimized using Anthropic’s models and reviewed by a human.