Tenhaw vs Hiring in-house

Both, in sequence. Hire permanently: that is the right end state and cheaper over any multi-year horizon. Use an interim Embedded Agentic Lead if the board's timeline is shorter than a six-to-nine month search, or if you cannot yet write the job specification accurately. The interim's job includes writing that specification and recruiting against it.

Six to nine months from opening the role to the person starting, then a further three to six months before they can move anything meaningful, because credibility inside a large organisation has to be earned before authority is real. Planning on under twelve months to impact is optimistic.

Currently £180,000–£350,000 base plus equity for a credible candidate, with recruitment fees typically 25–30% of first-year salary on top. Tenhaw supplies the seat inside an Agentic Design Team at £35,000–£55,000 a month or an Agentic Build Team at £70,000–£85,000 a month, which is more expensive monthly and is intended to run for months rather than indefinitely.

Yes. It is a stated deliverable of the Embedded Agentic Lead and full programme engagements. Recruitment happens while the work is live so that incoming permanent staff join a functioning capability and are onboarded by the person who built it.

It is the common failure, and it usually traces back to the role being given accountability without matching decision rights. The operating model work maps accountability explicitly before the hire is made, which is the single highest-leverage thing you can do to make the role survivable.

Six get discussed and most first workflows need two. An AI engineer builds the system around the model: retrieval, tool calling, the evaluation harness, guardrails, cost and latency. An ML engineer trains, fine-tunes and serves models, which is a different discipline and frequently not what an agentic workflow requires. An MLOps and platform engineer owns deployment, versioning, monitoring and the model upgrade treadmill, and is both the role left out most often and the reason systems stall before production most often. A data scientist frames the problem and builds the ground-truth set that decides what good means, which is the artefact almost nobody has and the only one that cannot be bought. A prompt engineer is the role being absorbed fastest into the AI engineer's job, so hiring it as a standing post is usually a mistake even though the work is real. And an AI product manager owns which decisions move to agents, where a human stays in the loop, and what the workflow is actually for. If you are hiring one person first, hire the product manager or the AI engineer depending on whether your open question is what to build or how. Hire the platform engineer before you have three agents rather than after.

They sit at different points of the same pipeline and merging them into one advert is the commonest reason an agentic hire fails in month four. An ML engineer builds and serves models: training, fine-tuning, feature pipelines, inference performance. An AI engineer builds systems that use models somebody else trained: retrieval, tool calling, orchestration, evaluation, guardrails, cost and latency budgets. A data scientist decides what the problem is and what a correct answer looks like, and owns the ground-truth set that everything else is measured against. Most enterprise agentic work in 2026 is AI engineering with a data scientist beside it, not machine learning, because the models are bought rather than trained. If your job specification asks for all three, you will interview candidates who each meet a third of it, and the one you hire will spend a year discovering which third the role actually needed.

Almost certainly not as a standing role, and the work itself is real. Writing, versioning and evaluating prompts is a discipline with a real effect on output, and it is being absorbed into the AI engineer's job rather than surviving as a separate post, in the same way that nobody hires a dedicated SQL writer. Where it does need naming is in change control, not on an org chart: a prompt is a versioned artefact that changes system behaviour, so a prompt change should trigger the same regression run and the same review as a model upgrade. Treat it as an engineering practice with an owner, not as a headcount line.