AI consulting vs implementation

Consulting produces a decision. Implementation produces a working system. Both are legitimate, they are priced differently, and the dangerous part is neither of them: it is the gap in the middle that neither contract mentions.

What each one is

Consulting is diagnosis and sequencing. How does your operation run, where does it leak, which leak is worth fixing first, build or buy, what should it cost. The output is a document and a decision. Nothing runs at the end of it.

Implementation is construction. Something exists and works that did not before. It requires a specification, and if you do not have one, the builder will use whatever you told them, which may or may not be the right thing.

The gap, and why projects die in it

Between "here is what to build" and "here it is, built" sits a set of tasks nobody wants to own.

Reconciling data that lives in two systems with different customer identifiers. Deciding what happens on every exception the roadmap did not enumerate. Working out who gets escalated to, how fast, and what happens if they do not respond. Getting credentials from a platform where only an external administrator can grant access. Establishing what "working" actually means so somebody can sign it off.

A strategy firm considers this implementation detail. A build shop considers it discovery that should have been done already. So it lands on you, usually in week three, usually as a delay and a change order.

Ask one question before signing anything: who owns data cleanup, exception design, and access? Get the answer in the document. That single clarification prevents most of the trouble in this category.

Which to buy first

If you cannot name your top three automations in order with rough values, buy the diagnosis. It is the cheaper purchase and it stops you building the wrong thing well.

If you can, skip it and buy the build. Paying for a diagnosis when you already have one produces your own list in better formatting. The test.

Buying both from one firm

Usually the practical choice, and it comes with an obvious conflict: a firm that builds has an incentive to recommend building, and to recommend building the things it is good at.

Ours included. The mitigations that actually work:

Pay for them separately, with a real stopping point between. You learn a great deal about a supplier during a diagnostic engagement, and you should be able to act on that.

Require the roadmap to be executable by anyone. If it only makes sense when they build it, the advice and the pitch were one document.

Ask what they would recommend if they built nothing. An answer that includes buying something off the shelf, or fixing a process without technology, tells you the diagnosis was real.

Strategy-only firms

The honest strength: no incentive to recommend a build, so the advice is structurally cleaner.

The honest weakness: nothing ships. A roadmap in a shared drive changes nothing, and a firm that has never built anything tends to underestimate the gap above, because that gap is invisible until you are standing in it. Recommendations from people who have not implemented are frequently too clean.

Build-only firms

Strength: they ship, and they know what breaks.

Weakness: they will build what you ask for. If your specification is wrong, you get a well-made thing that solves a problem you had not ranked, and the internal conclusion becomes that AI does not work here. Which class of problem you have.

It is also worth knowing what construction hands over, because the inventory is longer than most proposals suggest: what a build should deliver, and the five patterns that account for most real work.

What good looks like across both

Diagnosis first, with values attached and an explicit list of what not to do.

A specification detailed enough that a third party could build from it, including the exceptions and the escalation rules.

Then a small first build, tested against your real awkward cases before it touches a customer.

Then a named owner, a metric, and documentation aimed at somebody who never met the builder.

How we split it

Fixed fee for the roadmap, delivered so anyone can execute it, and the build is an option rather than an obligation. We say that in those words on the consulting page because it is the term that makes the diagnosis worth trusting.

On the gap: we treat data reconciliation and escalation design as part of the build rather than as your problem, and the roadmap flags where we expect data work to be needed so it is not a surprise later. The cost categories that usually get missed.