When a board decides the company needs to 'do something about AI,' two very different phone calls get made. One goes to a consulting firm, which sends senior partners, runs a discovery, aligns stakeholders and delivers a strategy — then, if you let it, a long implementation engagement staffed rather differently from the pitch meeting. The other goes to an augmentation provider, which embeds senior engineers into your team to build the thing. These aren't competing vendors for one job; they're different products that happen to invoice the same budget line. The failure mode isn't choosing either one — it's buying strategy when you needed shipping, or shipping when your real blocker was that nobody with authority agreed on what to build.
What consulting firms genuinely do well
It's fashionable in engineering circles to dismiss consultancies wholesale, and it's wrong. Three things they do better than almost any embedded engineer: framing — turning 'we should do AI' into a structured set of options with tradeoffs a board can act on; stakeholder alignment — getting a CFO, a nervous legal team and three VPs with competing agendas to agree on a direction, which is a skill, practiced at scale; and legitimacy — an external brand-name recommendation gives executives cover to make risky calls, and gives the eventual project political protection when it hits friction. If your AI initiative is blocked above the codebase — no agreed direction, no executive sponsor, competing fiefdoms — no number of brilliant engineers fixes that. That's consulting-shaped work.
The delivery economics: the leverage model, explained without cynicism
Consulting firms run on leverage: a small number of expensive partners sell and supervise, and a much larger base of junior staff delivers, billed out at multiples of their cost. This is not a scam — it's the industry's openly documented operating model, and for analysis-heavy work it can serve clients fine, because structured analysis is teachable and supervisable. It becomes a problem specifically for hands-on AI engineering, where the gap between a senior engineer who has shipped production LLM systems and a smart generalist two years out of school is enormous and not bridgeable by supervision. The pitch team and the delivery team are rarely the same people; the partner who impressed your board will be in your steering meetings, not your codebase. When evaluating a consultancy for build work, ask one question: name the individuals who will write the code, and show me what they've shipped.
What embedded engineers do well — and where they stop
Staff augmentation inverts the leverage model: you pay for the actual senior person, and the actual senior person does the work, inside your team. The strengths follow directly. They ship — working systems in your repos, not recommendations about systems. They transfer capability — your engineers absorb patterns, eval discipline and hard-won judgment by working alongside them daily, so the value compounds after they leave. And they course-correct cheaply, because embedded work bills for time and direction can change weekly without a change order. The limits are just as structural: an embedded engineer has no mandate and no leverage to resolve executive disagreement, win budget fights, or force a reluctant department to share data. Drop excellent engineers into an organization that hasn't decided what it wants, and they'll build something technically sound that the organization then fails to adopt — the engineering equivalent of the unread strategy deck.
- Strong at: shipping production systems, pragmatic architecture, skill transfer to your team, adapting scope weekly.
- Weak at: stakeholder alignment, political air cover, org-design questions, making executives agree.
- The tell you needed a consultancy instead: the engineers are productive but blocked monthly on decisions nobody will make.
- The tell you needed engineers instead: you have a deck everyone praised and nothing in production two quarters later.
The cost comparison, honestly framed
Headline rates mislead in both directions, so compare what a unit of money actually buys. The table below uses deliberately round, illustrative figures — real rates vary widely by market, firm tier and seniority — but the structural relationships hold.
| Factor | Consulting firm engagement | Staff augmentation |
|---|---|---|
| Billing unit | Engagement or team-week, often 5-10x a senior engineer's day rate per delivered senior-equivalent | Per named person, per day or month |
| Who does the work | Mixed team; junior-heavy delivery under partner supervision | The named senior engineer you interviewed |
| Deliverable | Analysis, recommendations, sometimes a pilot build | Working software in your repos, plus upskilled staff |
| Value after exit | The document, and decisions it enabled | The system, and the capability your team absorbed |
| Cost of changing direction mid-way | Change orders, re-scoping, often contentious | Near zero — redirect at the next standup |
| Hidden cost to watch | Implementation phases priced like strategy phases | Your own management time directing the work |
The sequential pattern beats the monolith
The expensive failure is the monolith: one firm, one contract, strategy through delivery, eighteen months. It fails predictably — the strategy phase runs long because it's billed generously; the delivery phase inherits the leverage model; and by month twelve you're paying consultancy rates for mid-level implementation work while your own team has learned nothing. The pattern that works is sequential and deliberately split. First, a short, tightly scoped strategy engagement — weeks, not quarters — with a fixed set of decisions as the deliverable: what to build first, what data unlocks it, who owns it internally, what 'working' means. Then embedded senior engineers build it inside your team, with your people alongside them. The handoff between the two is a document your engineers can execute against, not a dependency on the strategy firm's continued presence. If a consultancy's proposal makes leaving after the strategy phase feel impossible, that's not a service design — that's the business model.
- Scope the strategy engagement to decisions, not research: weeks long, with named outputs an engineer can build from.
- Contract the build separately, on augmentation terms, with named senior individuals — even if the consultancy offers to 'stay on.'
- Put one internal owner across both phases so context survives the handoff.
- Reverse the order if alignment already exists: build a scoped pilot first, and let the strategy conversation react to something real.
