Is a consultancy not just more expensive per day?

Per day, almost always. Per outcome, it depends on how long the work lasts. A twelve-week programme costs less than a year of salary and stops when it is finished. A continuing stream of AI work costs more through a consultancy every year it continues, which is why the honest recommendation for a company with proven ongoing demand is to hire.

Can we do the assessment ourselves?

Yes, and some teams should. It means someone senior spending a fortnight sitting with the people doing the work, timing tasks, and pricing the friction, then writing down what not to build as carefully as what to build. The reason it usually does not happen is not capability. It is that the person who could do it is the person shipping the roadmap.

What should we ask a consultancy before signing?

Ask how the assessment is paid for. If it is free or heavily discounted against a build that follows, the recommendation is not independent and the second list will be short. Ask what happens if the answer is that nothing is worth building. Ask to see the shape of a previous deliverable. And ask who writes the handover documentation, because that is the difference between owning the result and renting it.

We tried an AI agency and got a prototype that went nowhere. Why would this be different?

Frequently it is not, and that is a fair thing to be suspicious about. The specific difference worth testing for is whether the engagement names a number before any code is written and measures the same number afterwards. A prototype that dies is usually a prototype nobody agreed a success measure for, so there was never a point at which anyone had to say it had not worked.

Compare

Should we hire an AI engineer or bring in a consultancy?

The short answer

Hire when you already know what the person will build for the next year, because a permanent engineer is cheaper than any consultancy over that horizon and the knowledge stays in the building. Bring in a consultancy when you do not yet know what is worth building, when you need it decided in weeks rather than in a hiring process, or when the work is one programme rather than a continuing stream. The common expensive mistake is hiring first: a company hires an AI engineer, discovers three months later that the real bottleneck is a data quality problem or a rules engine, and now carries a salary against a job that turned out not to exist.

Why this comes up

The situation, before the answer

01
Someone on the board asked what the AI plan is, and the two answers on the table are a job advert and a statement of work.
02
Your engineers are capable of building it. What nobody has is the fortnight to work out which of the six ideas on the list is worth their quarter.
03
The AI hiring market is tight enough that a good candidate takes months to land, and the shortlist is full of people who have shipped demos rather than production systems.

Side by side

The comparison, on the dimensions that decide it

Shapes rather than figures. Salary bands, day rates and vendor prices move by an order of magnitude between markets, and a number here that you held us to would be worse than none.

Should we hire an AI engineer or bring in a consultancy?
Dimension	Hire a full-time AI engineerA permanent engineer who owns the AI work and stays with it.	Bring in a consultancyAn outside team that finds the work, builds it, and hands it over.	Train the engineers you haveThe team that already knows your systems learns the AI part.
Time to first useful output	Months. A search, a notice period, and a ramp-up on your systems before anything ships.	Weeks. The assessment is the first deliverable and it lands before a hire would have started.	Weeks for the first change, longer for anything with evaluation and monitoring around it.
What it costs, in shape	A salary plus employment costs, recurring whether or not there is AI work that month.	A fixed fee for the assessment, then a scoped project. It stops when the work stops.	A training cost once, then the ordinary cost of your team spending time on it instead of the roadmap.
Who holds the knowledge afterwards	One person, and it leaves with them. This is the risk nobody prices.	Depends entirely on the handover. Insist on the runbook and the evaluation set, or you are renting.	The team, spread across several people. The best answer on this row and the slowest to get to.
If you are wrong about the opportunity	You carry a salary against work that turned out not to exist, and the conversation is a redundancy.	The assessment ends and you stop. That is the outcome a fixed fee exists to make survivable.	Your engineers know more than they did. Nothing is stranded.
Judgement about what not to build	A new hire is under pressure to justify the role, which is the worst possible position to say "nothing here is worth it" from.	Only if they are paid for the assessment rather than out of the build that follows. Check which.	Your team already knows where the friction is. They usually lack the time rather than the judgement.
Fit with the systems you already run	Strong after ramp-up. They will learn your stack properly.	Good if they work inside your repository and your review process. Poor if they deliver a separate thing.	Best. They already know where the exceptions are handled and why that table is like that.
Realistic risk	You hire for a job you have not yet defined, and the definition arrives after the offer.	You buy a build because the supplier sells builds. The second list is the test of whether that happened.	Training happens, the roadmap does not move, and six months later nothing has changed.

Deciding

Which one, and when

01
Hire a full-time AI engineer
- You have shipped AI in production already and there is a continuing queue of it.
- The AI capability is the product rather than a feature of it.
- You can describe the first year of that person’s work in specifics today.
02
Bring in a consultancy
- The list of candidate projects has never been priced, and nobody has sat with the operations team.
- You need a decision this quarter, not after a search.
- The work is one programme with an end, rather than a stream.
- You need someone whose incentive allows them to say there is nothing worth building.
03
Train the engineers you have
- Your engineers are strong and the gap is confidence rather than capability.
- The systems are unusual enough that outside context would take months to acquire.
- The work is a steady trickle of small things rather than one large build.

The limit

What this comparison gets wrong

This comparison treats the three as alternatives, and in practice most companies that get this right do two of them in sequence. An assessment, then a hire against a job that is now defined. Or a build with an outside team, with two of your engineers on it deliberately so the knowledge stays. The version of this comparison that would be genuinely useful and that we cannot write is the one with your salary market and your hiring timeline in it, because both vary enough to change the answer.