AI Strategy6 min read

Before you buy the AI, map the migraines.

The most common AI implementation mistake we see: companies look externally for a magic AI solution before understanding their own processes. Here’s the fix-first-then-buy playbook — including why “agentic” isn’t the same thing as “AI”, and how to find the migraines worth paying to fix.

The pattern we see most often, in every industry we work in: an executive reads an article about AI, calls a vendor, sits through a demo, and buys the tool. Three to six months later, integration stalls, adoption fails, and the blame lands on “AI”. It wasn’t AI’s fault. Nobody had documented the process the AI was supposed to help.

This is the single most expensive mistake in enterprise AI adoption right now. Fixing it doesn’t need a bigger budget or a better model. It needs a different order of operations.

Look inside before you shop outside

The instinct when a competitor announces an AI initiative is to go find one of your own. So teams start with the *solution* — a vendor, a demo, a proof-of-concept — and try to work backwards to a use case. It rarely works. The tool is bought before the problem is understood; the problem is defined to fit the tool that was already bought; and the outcome is measured against whatever the tool happened to do well.

The correct order is the reverse. Identify and document the bottleneck first — end-to-end, with numbers — and only then engage the AI expertise. When the process is clear, matching the right technology is straightforward. When the process is fuzzy, no technology can save you.

“You wouldn’t hire a builder before drawing a plan. Don’t buy an AI before mapping the workflow.”

“Agentic” isn’t the same as “AI”

The vocabulary in this space has collapsed. Vendors call everything “AI” because that’s what sells; buyers call everything “AI” because that’s what they read. Three distinct capability categories are being flattened into one word, and that’s making it harder to pick the right tool for the job.

  • AI (in the ML/LLM sense) is inference on data — classifying a document, extracting a field, predicting a value, generating a response. It’s good at pattern-heavy work where the input is unstructured.
  • Agentic systems orchestrate multiple steps — often involving one or more LLM calls — to complete a longer task, usually with tool use, external systems and decision points. It’s good at coordination-heavy, judgment-heavy work that crosses systems.
  • Automation is the older, boring, deterministic sibling — scripts, workflow engines, rules-based pipelines. It’s good at high-frequency, well-defined tasks where the rules never change.

A lot of what gets pitched as “AI” could and should be automation. A lot of what gets sold as “agentic” is really a single LLM call in a workflow that could have been a form. Getting the taxonomy right is the difference between shipping something and shipping something that keeps working.

Migraines worth paying for

Not every inefficiency deserves an AI investment. The filter we use in every diagnostic: is this pain acute enough that the business would pay to fix it *even if there were no AI available*? If yes, it’s a migraine. If no, it’s a marginal efficiency gain — nice to have, not commercially compelling, and almost never worth the integration cost.

Two examples from recent conversations. A retailer wanting to auto-triage 40,000 monthly customer support emails, half of which are simple order-status queries: migraine. The business would pay to fix that today, at scale, without AI in the sentence. AI is just the fastest way to fix it. That’s a real target.

A different retailer wanting to save marketing analysts three hours a week on weekly report formatting: not a migraine. Real problem, real annoyance, but the business wouldn’t pay engineering time to fix it without the AI hook. The AI is doing the persuading, not the value.

The migraine test is unforgiving on purpose. It kills the pilots that were only ever going to run once. It concentrates the investment on the workflows that will actually get integrated, scaled and defended in a budget review.

Where agents actually fit

Most workflows in a business are not agent-shaped. They’re rule-shaped, or form-shaped, or query-shaped. Agents fit best in a specific sliver: coordination-heavy, judgment-heavy, cross-system tasks where a human today spends real time stitching together outputs from multiple places, applying context, and producing something bespoke each time.

Concrete examples where agents genuinely earn their keep: a merchandising assistant that reads sales data, weather forecasts, and last year’s promotional performance to recommend next week’s markdowns. A customer-service agent that reads the ticket, checks the order status, verifies the delivery address, drafts the response and files the callback. A finance agent that reconciles supplier invoices against POs and receipts, flags exceptions, and prepares the accruals journal.

Concrete examples where agents are the wrong tool: high-frequency lookups (that’s a cache), simple approvals (that’s a workflow), deterministic pricing rules (that’s SQL), scheduled reports (that’s cron). Any of these can technically be “built with an agent”. None of them should be.

Mapping which of your workflows fall into the agent-shaped bucket — and which are being wrongly force-fitted into it — is the work most businesses genuinely struggle with. It’s the highest-leverage thing an outside consultant can do before any code gets written.

The playbook

The order we run in every engagement. Not because we love a framework — because we’ve watched too many organisations skip it.

  • Document three to five painful workflows end-to-end. Actual steps, actual systems, actual time-per-step, actual failure modes. If nobody in the room can draw it on a whiteboard, you don’t understand it well enough to automate it.
  • Score each on frequency × cost-per-run × pain. The migraine score. Anything under a threshold is out — no pilot, no proof-of-concept, no meeting.
  • For each remaining candidate, name the actual bottleneck. Is it data (the numbers are wrong or missing)? Decision (a human is applying judgment at every step)? Coordination (the work spans systems that don’t talk to each other)? Different bottlenecks want different tools.
  • Match the tool to the bottleneck. Data bottleneck → probably data engineering, sometimes AI extraction. Decision bottleneck → probably ML/LLM. Coordination bottleneck → probably an agent, possibly automation. Don’t let the vendor pick.
  • Pilot the workflow with the best ROI, not the one with the shiniest tech. The ROI winner is almost never the AI-flashiest option. It’s the one that removes the most human hours per week from the highest-frequency migraine.

This is the Discovery Call and Diagnostic work we run before any Implementation phase begins. It’s the reason we don’t start engagements by talking about which LLM or which framework. It’s also the reason the Implementation phases we do run — actually ship, and stay shipped.

If you’re staring at an AI initiative and something feels off — no clear owner, no documented process, no defensible ROI, an executive convinced the answer is agentic before anyone’s named the question — that feeling is correct. Fix the order of operations first. The tool comes at the end, not the start.

VS

Vikram Saxena

Founder & Principal Architect, Blue Thread

Fix the data warehouse. Then build AI on top.

Twenty minutes to talk through your Snowflake environment or your AI plans — whichever is holding you up. No pitch, no pressure.