The body shop model and why it fails
The typical large-consultancy AI engagement puts a senior architect on the account for 2 days a week and fills the rest of the team with junior engineers who are learning on your project. The senior person does the design. The juniors do the implementation. You pay senior rates for junior delivery.
In consumer software that model can limp through — the environment is familiar, the tooling is well-documented and the failure modes are recoverable. In industrial environments — mining, machinery, defence, geospatial — the operating constraints are unfamiliar, the integration complexity is high and a failed deployment costs real money and real trust. Junior engineers learning those environments on a live project create delivery risk that compounds week by week. For AI transformation work, where the system has to survive contact with operations, the body shop fails quietly and expensively.
What a senior squad looks like
Our delivery model is 1 to 3 senior engineers embedded full-time for the duration of the engagement — the structure behind our Engineering as a Service offering. Senior means 10 or more years of production experience, not 10 years in AI specifically. An engineer who has shipped complex software in demanding environments and then gone deep on AI tooling for 2 years is worth more to your project than an AI researcher who has never run production software.
The squad is small enough to move fast and broad enough to cover the critical disciplines: data engineering, model development and AI integration. Where the work needs deep domain knowledge — mining operations, SCADA systems, geospatial data pipelines — we embed alongside your domain experts rather than hiring generalists onto our side. That is how a prototype becomes production AI without a 20-person programme: small senior teams, your operators in the loop, working software every week.
The knowledge transfer problem
The most common complaint about AI consultancy engagements is that the knowledge leaves with the consultants. The system is delivered, the team departs and nobody inside the client organisation can maintain or extend it. You bought a system and inherited a dependency.
We treat knowledge transfer as a delivery requirement, not an optional extra. The engineer embedded with your team writes the documentation as they build. They pair with your technical staff through the critical implementation phases. The handover is structured and evidenced: running the system together in production, not handing over a document and a zip file. At the end you own the code, the pipeline and the operating knowledge.
Sizing the engagement correctly
The right engagement size depends on scope, not ambition. A 2-engineer squad over 12 weeks can take a predictive maintenance system from prototype to production on a mid-sized fleet. Adding a third engineer does not make it 3 times faster — it adds coordination overhead and often slows delivery in the first half of the engagement.
We push back on scope inflation. When requirements arrive mid-engagement, we assess whether they fit the current squad and timeline before committing — the alternative is a project that expands until it cannot ship anything at all. And if the scope itself is still unclear — you know AI matters to the business but not where to start — that is a scoping problem, not a staffing problem. It is better solved by a short AI transformation consultancy engagement before a squad is booked.
What to ask an AI consultancy before you sign
Ask to speak with the engineers who will be on your project, not the partners who will sell you the engagement. Ask how many of those engineers have shipped AI in production in your sector. Ask what the handover process looks like and what documentation you will own at the end.
Then ask what happens when something breaks in production 6 months after the engagement ends. The right answer is specific: who picks up the phone, on what terms, at what cost. The test is whether the consultancy ships and then stands behind the system — transparent, written support terms with named engineers are a sign of confidence, not a sales hook. The warning sign is vagueness in either direction: a partner who disappears at handover, or one whose commercial model depends on you never becoming self-sufficient.