Skip to main content

From the shop floor

a working note

How to Choose an AI Consultant in Chicago

Choose an AI consultant on evidence: shipped work you can inspect, named builders, written support terms, and pricing stated on the first call.

Filed July 7, 2026AI Strategy

Choose the AI consultant who can show you finished work, will name the person doing yours, and puts terms in writing before you commit. That covers most of the decision. The rest is knowing which questions surface those three things quickly, and what evasion sounds like. What follows is the bar we expect to be held to ourselves. Run it on every candidate, including us.

What should a consultant be able to show you?

Shipped work, in a form you can inspect. The cleanest version is a recorded demo of a system the consultant built and delivered. A live demo in a sandbox mostly proves the sandbox works, and a promised live version is a warning light no matter who offers it. Recorded is the right format because the work existed before you asked to see it. We build our own demos as recordings of delivered work, then cut them into slides.

Public teaching is the second exhibit. A proposal can claim anything. Standing in front of a room and taking questions from strangers is harder to fake, and easier for you to verify. Prefer candidates who teach somewhere you could go watch. Our founder, Dexter Brocks, spent a self-taught decade in tech that ran from the support desk to cloud engineering, and he teaches in public, including at the University of Chicago Polsky Center. We mention that for one reason: you can check it without our help.

The third exhibit is whether they use what they sell. A practice that sells AI search visibility, AEO in the trade, should have a site already built for AI answers. Ours carries FAQ schema and an llms.txt file, and every service page is written as a spec sheet, because that is the discipline we charge for. Whatever a candidate sells, ask where they use it on themselves before you weigh anything else.

What should you ask on the first call?

First calls are short, so the questions have to earn their place. These seven do:

  • Who, by name, will do the work, and how much of that person do we get?
  • Whose accounts will the build live in when the engagement ends?
  • What have you shipped that we can watch? A recording is fine.
  • What support follows delivery, and is it inside the price or next to it?
  • How is this priced, and will you say a number today?
  • How will we know it worked, and against what baseline?
  • What would you refuse to build for us?

The last one is the fastest filter. A consultant with no refusals in them has either no judgment or no scars, and you would be paying to supply both.

Support is where scopes go quiet, so push on it. Our own terms, for reference: bootcamps include 30 days of support, automation and AEO builds include support, and workshops offer the 30-day window as a paid add-on. None of that is exotic. The point is that it lives in the document, not the sales call.

How the work gets priced should be clear on the first call, before any number is named. Training and talks run fixed scope. Automation and agent builds are priced per project, and fractional Chief AI Officer work runs on a monthly retainer. Those are our models, and a serious candidate will have equivalents with reasons attached. We give numbers on that first call, and you should expect the same anywhere.

What are the red flags?

The loudest one is an ROI story that opens with headcount. A system built to remove the people who are expected to adopt it does not get adopted. It gets routed around, quietly, and the consultant is usually long gone by the time that shows up in a number anyone reads. The durable ROI story is capacity: what the same team can handle after the build that it could not handle before, and what stops leaking along the way. Our own count of people replaced by this work is zero.

Price fog is the second. A candidate who cannot say how they price early is planning to say it after you are invested. You are allowed to ask in the first meeting. Anyone offended by the question has answered it.

Then there are builds that live in the consultant’s environment. A workflow that runs in their tenant, under their logins, leaves you owning an invoice at handoff. Ask where everything lives when the engagement ends, and listen for your own account names in the answer. In our bootcamps, each team builds one system end to end in their own AI accounts, with no demo environment to graduate out of. We set it up that way because of this exact flag.

Last, the single-product answer. When every problem you describe lands on the same platform, ask who pays the candidate. Sometimes the answer includes the platform. A consultant should show up with a toolbox, and the tool should get picked after the problem is understood.

What does a good proposal look like?

Specific about what will exist. A good one names the system you will have afterward and the person on your side who will own it. Phases are not deliverables. A proposal that is mostly discovery and enablement phases is a calendar, and a calendar should not cost what this one will.

The pricing model should match the work. Fixed scope fits work that is known in advance, which is why training runs that way. Builds carry real discovery, so per-project pricing is fair there. A retainer is for work that is genuinely ongoing, and fractional advisory is the only part of ours that qualifies. When every line is a retainer, the proposal is built around the seller’s revenue, and you are the annuity.

Find the support terms in the scope table, with a duration attached. Support that lives in the deck but not the scope table has not been priced, and that becomes your problem later.

Then the measurement plan. You want the baseline named before the work starts, plus the date when you read the number together. When the only measurement is a closing slide about partnership, judging was never the plan.

Comparison gets easier when scopes are public. We keep our services documented page by page for that reason, each one stating what is included and what support follows, so you can line us up against anyone without booking a meeting.

Does the consultant need to be in Chicago?

It helps a lot for the hands-on work and barely registers for the rest.

Hands-on training is the strong case for local. A bootcamp is a room activity, screens open and reps happening in the team’s own accounts, and a trainer who can come back for the follow-up session without an itinerary is worth something. Keynotes are similar for the obvious reason: the event wants the speaker in the building.

Builds and advisory barely notice geography. An automation build does not know what city it was written in. Agent work runs inside your systems, and fractional advisory runs on calls. Judge those on evidence and scope, not on location.

What a Chicago consultant does give you is checkability. The scene here is tight enough that reputations sit within asking distance, so ask around before you shortlist, and go watch any candidate who teaches in public. For the record, ours: based in Chicago, traveling wherever your team is. The address is for the room work and the reputation, and the rest travels over a video call like everything else.

However you build the shortlist, put the same questions to everyone and keep the written answers next to the proposals when they arrive. The comparison mostly makes itself. Our first call is 30 minutes and free, and everything above is fair game from the first minute.

The byline

Written by
Dexter Brocks, Founder & CEO
Also answers to
Chicago AI Guy
Home base
Chicago, IL, traveling wherever your team is

More about Dex

FAQ

asked at the counter

Asked often. Answered straight.

What makes one AI project cost more than another?

Scope, mostly. A single automation that touches one system quotes lower than an agent wired into several. Training tracks how many people attend and in what format, so one role-based workshop costs less than bootcamps run across several teams. Readiness moves the number too: accounts and data already in order shrink the discovery a build has to price. We give real numbers on the first call, once we know which of these apply.

What should a support clause actually spell out?

A good one pins down four things: how long support runs, how fast you can expect a reply, which channels reach the team, and where the line sits between fixing what was built and paying for new work. Get all four into the document before signing. Support that lives only in the sales conversation tends to vanish once delivery is done.

What should change hands when an AI build is delivered?

Enough should change hands that your team can run the system without the consultant. That means admin on every account and the matching credentials, documentation good enough to operate it solo, and billing in your name. If any piece stays on the vendor's side, you have a rental, so walk the handoff item by item before final payment.

What if a consultant will only show a live demo?

Ask for a recording of a delivered build instead, and ask who owns the system in it. If neither exists, treat the live demo as a prototype and price the risk accordingly. You can also ask to speak with the client it was built for. A consultant with delivered work can usually produce one of these on request.

Can a consultant based outside Chicago still run our in-person bootcamp?

Yes, as long as travel is real and written into the plan. Hands-on sessions need a trainer in the room, so confirm the travel and any follow-up visit are in scope rather than billed later as surprises. What to question is remote-only delivery of a format that depends on being present. A consultant who commits to the travel can run the room on your site.

Your team is smarter than the software. We just prove it.

Put the reading to work.

A 30-minute call turns any of this into a plan for your team. Real questions, real answers, zero pressure.