What you are actually buying, and why the label lies.
Before any of the diagnostic questions, get clear on what is at stake, because it is not the same across the firms you are talking to. When you commission AI work for a core workflow, you are buying one of two very different things wearing the same name. One is an asset: a system you own, that runs inside your own infrastructure, that keeps working and keeps compounding after the consultant leaves. The other is access: a subscription to logic somebody else owns and operates, priced monthly, revocable, and gone the day you stop paying. Both get sold as "AI consulting." The gap between them is the whole reason this decision is hard.
For a mid-market operator the difference lands on the balance sheet, not the pitch. A firm that owns its core workflow has turned a payroll leak into a fixed cost and kept the leverage; a firm renting the same workflow has added a recurring bill it does not control to the most important part of its operation. Neither vendor will frame it that way in the first meeting, so the burden is on you to figure out which one you are being offered. The good news is that a handful of plain questions, none of them about models or architecture, separate the two reliably. The rest of this memo is those questions, in the order worth asking them.
It helps to know the three archetypes you are likely meeting, because they present almost identically on a homepage. The first is a genuine build shop that commissions custom systems and hands over the source. The second is a SaaS reseller that has wrapped a platform license in a new consulting deck and earns on the recurring subscription. The third is a generalist marketing or IT agency that added AI to its service menu and will subcontract or improvise the actual engineering. All three will use the same vocabulary in the first meeting, and all three may be competent at what they actually do. The problem is that only one of them is selling you an owned asset, and the words on the site will not tell you which.
Keep one frame in mind throughout. You are not evaluating who understands AI best; most of these firms can talk fluently about the technology. You are evaluating who will scope honestly, build on reality, and hand you something you own. Those are business behaviors, not technical ones, and an owner-CEO is fully equipped to judge them without a computer-science background. The strongest signal you have is how a partner behaves before you have paid them anything, which is why the sequence of questions below is ordered to surface those behaviors early, while you still hold all the leverage.
The reseller tell: they scope up, a real consultant scopes down.
The clearest way to separate a real AI consultant from a reseller or a generalist agency is to watch which direction they scope. A reseller scopes up. They want to sell you a platform, a company-wide transformation, a seat count, because their economics come from the size of the license and the length of the contract. A real consultant scopes down. They want to find the one workflow that is actually costing you money and point a build at that, because their reputation comes from a result you can measure. Same first meeting, opposite instinct, and the instinct is easy to read once you know to look for it.
Listen for whether they can name your workflow or only their capabilities. A reseller talks in features and platforms and use cases in the abstract; a real consultant asks what specifically is slow, what specifically is expensive, what your team complains about, and which system of record it lives in. By the end of a good first conversation, a real partner can state your baseline back to you: this intake process burns roughly this many hours a week, here is where the errors come from, here is the number we would try to move. A firm that cannot do that has not understood your business yet, and quoting before understanding is the reseller move. The distinction between commissioning a build and buying a subscription is the same one we draw in build versus buy AI for a mid-market company, and it starts in that first meeting.
There is a related tell in how they treat the word "AI" itself. A generalist agency that bolted the term onto an existing service line will use it as a mood, a way to sound current. A real consultant treats AI as a means to run a specific process with less human handling, and is comfortable telling you where it does not apply. A partner who says a workflow is not worth automating, or that an off-the-shelf product would serve you better than a custom build for a given commodity process, is showing you the honesty you want on the workflows that do justify a build. Universal enthusiasm is a sales posture. Selective enthusiasm is judgment.
Scope to a named workflow before anyone quotes a number.
Insist that scoping comes before pricing, and treat a partner who refuses to quote until they have scoped as a good sign rather than an evasive one. A real engagement opens by naming one workflow, measuring what it costs you today, and only then putting a price against that baseline. That sequence protects you twice. It forces the consultant to understand the job before committing to it, and it gives you a yardstick to judge the result against later. A number quoted before any of that has happened is either padded to cover the unknowns or destined to grow through change orders once the real complexity surfaces.
The scoping phase is not overhead on the way to the real work; it is the most valuable thing the engagement produces early. A good diagnosis tells you which workflow is your actual bottleneck, what it costs in hard dollars, and whether software can move that number, and that finding is worth having even if you never build anything. This is exactly what a structured diagnosis process is for: to convert a vague sense that "we should be doing AI" into a specific, measured, buildable scope before a dollar of build budget is committed. A partner who wants to skip straight to building, or to quote the build before diagnosing, is asking you to fund a guess.
The quote itself carries red flags once you know to read it. Be wary of a single blended figure for a broad "AI transformation" with no line items, because a number with no workflow attached cannot be checked against a result. Be wary of a price that leans heavily on a monthly figure with a small build component, since that structure signals the value is meant to accrue to the vendor over time rather than to you at handoff. Be wary of any proposal that treats discovery as a throwaway giveaway, because scoping done for free is scoping done fast, and fast scoping is where the change orders are born. A proposal that names the workflow, states the baseline, and prices the build as the main event is one that took the diagnosis seriously.
You can do a surprising amount of this scoping yourself, which is the best possible preparation for evaluating any partner. Pick the one workflow that is both frequent and expensive, the one where hiring is currently your only lever. Write down what it costs: the staff hours it consumes, the errors and rework it generates, the delay it introduces that maps to lost revenue. If you can put a number on that, you walk into every vendor conversation able to tell whether they are engaging with your reality or selling you theirs. If you cannot put a number on it, that difficulty is itself useful information, and it is a far cheaper finding than a build that had no baseline to justify it. The way to size that number and its payback is laid out in how to measure ROI on a mid-market AI engagement.
Built on your systems, not on a demo that impresses.
The most seductive failure in this market is the demo that works beautifully and does not survive contact with your actual stack. A polished demo runs on clean, invented data in a controlled environment, and it is designed to make the sale, not to run your operation. The workflow that matters runs on your messy real data, inside your real systems of record, against the edge cases your team handles every day without thinking about them. A consultant who builds on the demo and a consultant who builds on your reality are doing fundamentally different jobs, and the second one is the only one that produces something that works on Monday.
Ask directly how they will build against your systems, and listen for whether the answer involves your real data early or keeps you in a sandbox until the invoice clears. A serious partner wants access to a representative slice of your actual workflow up front, because that is where the hard parts live: the exceptions, the inconsistent inputs, the integration quirks in the CRM or ERP or claims system you already run. A partner who defers all of that to "implementation" after you have signed is deferring the risk onto you. The exceptions are not a detail to handle later; on most mid-market workflows they are the majority of the work, and a build that only handles the happy path is a demo with an invoice attached.
Building on your real data raises a question you should ask before you hand over access, not after: where does that data live during the build and who can see it. A serious partner will work inside your own cloud tenant or a controlled environment you approve, will limit access to the slice of data the workflow actually needs, and will be able to explain how your information is handled in plain terms. Vagueness here is its own red flag. You are giving a vendor a window into a core process and often into customer or financial records, and a partner who cannot describe the data handling clearly is one you should not extend that window to. This is also the moment ownership starts to matter, because a build that runs in your tenant from the start is far easier to keep and secure than one assembled on the consultant's infrastructure and moved later.
This is also where industry familiarity earns its keep, though not in the way vendors usually claim it. You do not need a partner who has built your exact system before; you need one who understands the shape of your operation well enough to ask the right questions about where the workflow actually breaks. A consultant who has worked across mid-market operations and knows how intake really behaves in a law firm, how document work piles up in a CPA practice, or how quoting stalls inside a specialty manufacturer will find the real edge cases faster. That is different from selling you a template. The point of the domain knowledge is a better build on your systems, not a shortcut around them.
Ownership at handoff versus renting it back forever.
This is the clause that most changes what the engagement is worth, and it is the one buyers most often forget to nail down. Ask what you own when the work is finished, and get the answer in writing before you sign. Ownership means the code, the prompts, and the integrations run inside your own cloud tenant and you hold the source. You can maintain the system, modify it when your process changes, swap the underlying model when a better one ships, or hire a different firm to work on it, all without anyone's permission. That is an asset. Perpetual rental means the consultant keeps the logic on their infrastructure and you pay indefinitely to keep using the thing you funded. That is a subscription with a large setup fee.
The reason this matters so much for mid-market operators is leverage. A large enterprise rents because procurement and governance and scale make renting rational for them. A mid-market company is small enough to own its core workflow outright and rarely uses that advantage, which is one of the few places where being mid-market is a structural edge rather than a constraint. When you own the build, a price increase from a model provider is your decision to manage, not a vendor's decision to pass along. When you own the build, the day the relationship with the consultant ends is not the day your workflow stops. For anything central to how you make money, that difference compounds over years.
Ownership also disciplines the rest of the deal in a way that protects you. A partner willing to hand over the source at the end is a partner betting on the quality of the build to earn the next engagement, rather than on lock-in to guarantee the recurring revenue. That is the incentive you want on the other side of the table. When you compare the true cost of a rented workflow against an owned one over a five-year horizon, the arithmetic is rarely close, and the full breakdown is in what a mid-market AI engagement actually costs. Rent is a cost that recurs and rises; ownership is a fixed cost against a leak you have stopped for good.
Pricing that aligns incentives, references, and month four.
How a consultant prices the work tells you what they are optimized to do. Fixed-fee for a scoped build is the structure that aligns their incentive with yours, because it pays them to finish and move on rather than to linger. Hourly billing does the opposite: it pays a partner to take longer, and on a defined workflow that is precisely the wrong reward. An open-ended retainer with no deliverable can quietly become rent for access you already paid to build, especially when it is bundled with the ownership question left vague. A firm quote is also evidence that real scoping happened, because you cannot price fixed-fee against a workflow you have not measured. The one reasonable exception is a modest, optional maintenance arrangement after handoff, which is different from a retainer that is really disguised ownership of your system.
Then check references, but check them for the right thing. Most reference calls waste the opportunity by asking whether the client was happy at launch, which almost everyone is. The question that matters is what happened in month four, after the initial enthusiasm faded and the real test began. Ask the reference whether the system still runs, who maintains it, whether it drifted, and whether the consultant was around when something broke. Most mid-market AI work does not fail at launch; it stalls a quarter or two later when nobody owns the upkeep and the workflow slips out of alignment with the process, a pattern we trace in why most mid-market AI rollouts stall in month four. A partner who has an honest answer for month four is worth more than one with a better demo for week one.
Get the terms that protect all of this in writing while you still have leverage, which is before you sign, not at handoff. The contract should assign the intellectual property in the build to you, name the deliverables that constitute completion, and require documentation and a handover of the source and credentials so your team or a future firm can maintain the system without the original consultant. It should say plainly what any post-launch maintenance arrangement covers and what it costs, so that a reasonable support option never quietly hardens into dependence. None of this is adversarial; a partner betting on the quality of the build will sign these terms without friction, because they expect to earn the next engagement on results rather than on lock-in. The one to worry about is the one who resists putting ownership in the document.
Local presence is the last filter, and it belongs last for a reason. A partner who can sit in the room in Boston or Greater Massachusetts speeds the diagnosis, makes stakeholder interviews easier, and reads your operation faster, and there is a genuine case for keeping a mid-market engagement inside the region. But proximity decides how pleasant the work is to get through, not whether the work will be good. Use the three real questions to decide quality: do they scope before quoting, do they build on your systems, do you own the result. Then let location break the tie between two partners who both pass. If you are weighing a consultant against building the capability internally instead, the tradeoffs are in AI consultant versus an in-house hire. The best first move, though, is to name your own bottleneck before you talk to anyone, so that every conversation is measured against a number you already hold.