You want to add AI to your business. You start searching, and the same two job titles keep showing up - AI consultant, AI engineer. The pages selling each one sound almost the same ("we help you adopt AI", "we build AI solutions") and you can't tell what you're buying.
Short version: an AI consultant tells you what to build, in what order, with what tradeoffs. An AI engineer writes the code that does the thing. Some people do both, but the daily work is pretty different, and so is what you should pay for.
This article walks through what each role does day to day, when to hire which, and the common ways founders waste money picking the wrong one.
What an AI consultant actually does
A consultant's output is a decision. You show up confused about whether to use ChatGPT, a custom build, Zapier, or some SaaS tool you saw on LinkedIn. They leave you with a plan: here's the problem worth solving first, here's the cheapest path to a working version, here's what it will cost in time, and here are the risks.
A consulting engagement usually includes:
- A working map of where AI fits in your business (and where it doesn't yet).
- A ranked list of use cases with effort and expected payoff for each.
- A build vs buy vs toolsmaxxing recommendation. Toolsmaxxing means using features inside tools you already pay for - Notion's built-in AI, Monday's automations, QuickBooks' AI assistant - before you bring in anything new.
- A short list of vendors or freelancers if you do need to hire for a specific build.
A good consultant kills bad ideas before you spend money on them. Ove Andre Remme at Terapivakten had already hired a freelancer with 20+ five-star reviews who spent two weeks building him a custom GPT. It didn't work - the GPT generated 40% less content than needed and went off the rails when pushed harder. A "you can't do this in a chat agent, you need a real app" call would have saved him those two weeks. He came back and we shipped a working product. His take on what changed: "You were directly pointing to the issue that I experienced."
That call is the consultant's job. The build that came after is the engineer's.
What an AI engineer actually does
An engineer's output is software that runs. They take the plan and turn it into code, prompts, API integrations, evaluation tests, and the infrastructure that keeps the whole thing alive at 2am when something breaks.
Day to day, that looks like:
- Picking the right model for each step (frontier model where quality matters, small fast model where speed matters more).
- Writing the prompts and the code around them - tool calls, retries, fallback logic.
- Integrating with your CRM, your database, your email, your phone system.
- Building guardrails so the AI doesn't do something dumb: LLM-as-a-judge checks, schema validation, hard rules in code where the prompt isn't enough.
- Setting up automated tests that run on every code change with real AI calls, so a bad prompt edit doesn't ship undetected.
- Watching the system in production and fixing the edge cases nobody predicted.
I spent 2 years as an AI engineer at Sellify AI building exactly this kind of system for the US pest control industry. Ivan Nikolaichuk, the technical co-founder there, wrote the LinkedIn recommendation about that work. The end-to-end AI sales system we shipped helped HomeTeam Pest Defense generate over $1M in new mosquito revenue in a single campaign month with zero new hires. That's an engineering outcome - the consulting decision (sell mosquito to existing customers, automated, no human in the loop) was made before any code got written.
The work is different, and so is the skill stack
A consultant needs to know enough engineering to call BS on a vendor pitch. An engineer needs to know enough about your business to not build the wrong thing. The middle of the Venn diagram is real and a few people live there, but the daily job is pretty different.
A consultant spends most of their time in conversations - with you, with your team, with vendors - and writing documents. An engineer spends most of their time in code, prompts, and logs.
If you hire a consultant and expect production code, you'll be disappointed. If you hire an engineer with no business context and ask them what to build, you'll get a technically beautiful answer to the wrong question. I saw this at a recruitment AI client: their internal team (zero AI experience) had connected an analytics agent to a LangChain SQL library that talked to the production database directly, with no row-level access controls. What we ended up doing was replacing that whole thing with 5-6 hardcoded parametrized queries with tool calls. Less AI in the loop meant fewer things to debug and far more reliable answers. That call needs both hats.
When you need a consultant first
Hire a consultant before you write a line of code if any of these are true:
- You have a budget set aside for "AI" but you don't have a specific problem yet.
- You've used ChatGPT a lot and you're convinced AI can help, but you can't name the workflow you'd start with.
- You're about to hire a freelancer or agency and you can't tell from their proposals whether they understand your business or are selling a generic template.
- You've already failed once - a chatbot nobody uses, an automation that broke, a custom GPT that hallucinates - and you want a second opinion before spending more.
- You have 3-4 ideas competing for the same budget and you need someone to rank them.
One real-estate founder I talked to put it like this: they're using AI all the time (Copilot, ChatGPT, Notion AI) but none of it is connected and there's no overall strategy. Each tool helps a little, none of them talk to each other, and there's no clear picture of what's working. That's a consultant problem. You don't need more tools, you need someone to look at the whole flow and tell you where the leaks are.
A good consulting engagement should be short. A few weeks at most, with a concrete artifact at the end. If a consultant wants to put you on a 12-month retainer with no defined deliverable, walk away.
When you need an engineer
Skip straight to an engineer if:
- You know exactly what you want to build (e.g. "take incoming maintenance requests from tenants, ask follow-up questions, gather photos, create a project ticket").
- You already have a working prototype from ChatGPT or a no-code tool, and it's hit a wall - too slow, too unreliable, can't integrate with your CRM, won't scale past a handful of users.
- A vendor sold you something that almost works and you need someone to extend or fix it.
- You're building a product (not just an internal tool) and your customers depend on it not breaking.
The "prototype hit a wall" pattern is the most common one. A founder gets a long way with ChatGPT and zaps. Then volume goes up, or quality drops, or one specific edge case keeps embarrassing them in front of customers. That's the moment an engineer is worth bringing in. The consulting decision was already made by the prototype.
When you need both (and what that looks like)
Most real engagements need both, just at different times, and often from the same person.
The shape I see most often with founder-led firms:
- A short consulting phase to scope the problem and rank options.
- A build phase to ship the first version of the highest-ranked use case.
- A pause to look at what real users do with it.
- Another build phase informed by what you learned.
That second build phase is where the consulting/engineering distinction gets blurry. A pure consultant will hand off and lose the thread. A pure engineer will keep building features without questioning whether they're still the right ones. The work needs someone who can switch hats.
For small founder-led firms, hiring two separate people for this is usually overkill. You end up paying for context to be transferred twice, and the engineer often ignores the consultant's plan anyway because it doesn't survive contact with the real system.
What about an AI agency or a fractional CAO?
Two adjacent options worth naming.
AI agencies
AI agencies bundle consulting, engineering, and ongoing support into one contract. Good fit if you want a single throat to choke and you're comfortable paying for the overhead. Watch out for the agency that uses the same playbook on every client - the giveaway is a proposal that doesn't mention your specific tools or workflows.
Fractional Chief AI Officers
A fractional CAO is a senior person who shows up part-time, sits in your leadership meetings, and owns AI strategy across the company. Makes sense once you're past the first build, have multiple AI projects running, and need someone to coordinate them. For a firm that hasn't shipped one project yet, this is too early.
For a 5-50 person firm with no AI shipped yet, the cleanest path is usually one person who can consult and build, scoped to a specific outcome, with a clear way to extend the relationship if it works.
How to evaluate the person in front of you
A few questions that cut through the marketing fast.
Ask them to describe the most complex thing they built and what tradeoff hurt the most. A real engineer will name the tradeoff specifically - latency vs quality, cost vs accuracy, flexibility vs reliability. A real consultant will name a decision they killed and what it would have cost if it had shipped.
Ask what they'd say no to. A consultant who says yes to every idea you pitch is selling time, not judgment. One of the first things a useful consultant should do is shrink your project list.
Ask for a named client and a link to that client's public testimonial. Anyone can claim experience. Few link out to a public LinkedIn recommendation, a YouTube interview with the client, or a published case study. The link is the proof - if you can't find one on their site or LinkedIn, the work probably isn't there.
The failure-rate context
Gartner expects organizations to abandon 60% of AI projects through 2026 because the underlying data isn't ready for them. A separate Gartner forecast says over 40% of agentic AI projects will be canceled by the end of 2027 due to escalating costs and unclear business value.
That headline number isn't really about the technology. It's about the gap between "we should do AI" and "we should automate this specific cross-sell campaign because our team is too busy onboarding new customers to run it". HomeTeam knew exactly what they wanted automated before Sellify built it. That clarity is what the consulting side of the work creates, and without it the engineering side has nothing solid to build on.
So when you're picking between a consultant and an engineer, the question is really - which gap is bigger right now? Knowing what to build, or building it? If you're not sure, that itself is the first answer a consultant should give you.
Grab a slot on my calendar. Bring your messiest current attempt and we'll figure out together which side of the line you're on.
FAQ
Is an AI consultant the same as an AI engineer?
No. A consultant produces decisions and plans. An engineer produces working code. Some people do both, but the daily work is pretty different - consultants spend their time in conversations and documents, engineers spend theirs in code and logs.
What does an AI consultant actually do day to day?
They map where AI fits in your business, rank use cases by effort and payoff, recommend build vs buy vs using features in tools you already pay for, and tell you which ideas to kill. The deliverable is a written plan you can hand to an engineer or use to evaluate a vendor.
Can one person be both?
Yes, and for small founder-led firms that's usually the cleanest setup. Two separate hires means paying for context to be transferred twice and a higher chance the engineer ignores the consultant's plan once the build starts.
Do I need a fractional Chief AI Officer?
Not yet, if you haven't shipped a first AI project. Fractional CAOs make sense once you have several AI initiatives running and need someone senior to coordinate them. Before that, you need one shipped outcome more than you need part-time leadership.
How much should an AI engineer or consultant cost?
It depends entirely on scope, stakes, and how much production responsibility they're taking on. The price comes out of the conversation about the specific problem - anyone quoting a number before that conversation is selling a template.
Why do so many AI projects fail?
Gartner points to data readiness, unclear business value, and skill gaps. In practice the most common pattern I see is starting with "we should use AI" instead of "we should automate this specific workflow that's costing us X hours a week". Without that second framing, no amount of engineering saves the project.
