How to Hire a Machine Learning Engineering Agency in 2026

The gap between the marketing claim custom ML and what most agencies actually deliver has widened in 2026. Ninety percent of the pitches you receive as an operator will be from teams that wire a Claude or GPT API call through an n8n workflow and call it AI. That is legitimate work, but it is not custom machine learning.

This guide is the honest version of how to evaluate a machine learning engineering agency in 2026 - what to ask on the first call, which claims to trust, which to discount, and how to structure the engagement so the risk sits on the agency, not on you.

Custom machine learning, in the sense that will move your unit economics, has one of three shapes. Custom-trained models on your data (churn prediction, risk scoring, demand forecasting, recommendation systems). Fine-tuned foundation models where the fine-tuning delivers a measurable improvement over prompt engineering. Or specialised architectures for problems where general-purpose models fall short (time series with complex seasonality, multi-modal domain-specific tasks).

Everything else - prompting a foundation model to write in your voice, chaining LLM calls into a workflow, wiring RAG over your docs - is valuable engineering, but it is not custom ML. It should not be priced or sold as such. When an agency positions those workflows as machine learning, that is your first signal about what they will deliver.

These are the questions that separate agencies who ship production ML from agencies that sell it as branding.

Not the demos. The production instances. Ask for slugs of shipped systems where the agency owns training. If the answer is a foundation model API integration wrapped in a fancy dashboard, they do not train custom models. That is fine for many use cases. Just do not pay them custom ML rates for it.

Any agency that quotes model work without seeing the data first is either flying blind or has decided the specific data does not matter. Both are red flags. The real answer is that the agency runs a phase one which maps your schema, checks feature availability, verifies target variable definitions, checks class imbalance, and validates time-window correctness against future-data leakage. If they do not describe this phase, they will discover the data problems in production instead of in phase one, on your time.

How does the agency prove the model works before it touches production. The right answer includes time-aware cross-validation, held-out windows, calibration checks, and a real evaluation dataset that reflects production distribution. The wrong answer is a train-test split without time awareness, or a claim that they will validate in production. Time-aware cross-validation matters specifically because random splits leak future information and produce models that look brilliant offline and degrade in production.

This is the diagnostic question. An agency that always sells custom ML no matter what will fail this question by insisting your problem needs custom work. An agency that treats custom ML as one tool among many will name specific cases where they would redirect you - off-the-shelf APIs cover your needs, your data volume is too low, RAG solves the actual problem cheaper. If they cannot name cases where they would say no, they will say yes to work that fails.

The classic mistake is signing a single fixed-price engagement for the whole ML build. This transfers all the risk to you. If the data turns out unusable in week three, you have already paid for a five-week build. The agency has an incentive to push through rather than stop.

The right structure is two phases with an explicit off-ramp between them. Phase one is data audit, feature availability check, and adapter build if needed. It runs two to four weeks with a fixed price. At the end of phase one, one of three things happens. The data is ready and the model is worth building - proceed to phase two. The data has gaps that need fixing before modelling - go fix the data with clear deliverables. The problem does not warrant custom ML - stop and pay only for phase one.

This structure works because it aligns incentives. The agency has to prove in phase one that phase two is worth funding. You have visibility on the data reality before committing to the model work. Any agency that refuses this structure and insists on a single lump price is either not confident their phase one findings will support the build, or wants to lock you in before you can back out.

Assuming phase one confirms the build makes sense, phase two typically covers model training, offline evaluation, calibration, deployment to a staging environment, and a shadow-mode run before production activation. Shadow mode is essential for scored-decision systems - the model runs on live data, produces scores, but no downstream action fires. This gives you two to four weeks of production evidence that the model's flagged records actually behave as flagged, before any campaign spend commits to those scores.

Handover is where most engagements fail. A model that only the agency can retrain is a lock-in. Insist on documentation that includes the feature engineering pipeline, the training data schema, the model artefact format, the calibration procedure, and the retraining runbook. If the agency treats handover as an afterthought, treat that as a signal they intend to be your ongoing dependency.

Custom ML pricing in 2026 sits in a wide range. A narrow scoring model on clean data can run in the low five figures. A retention or forecasting system with real data engineering effort runs in the mid five figures. Multi-model systems with fine-tuning, custom architectures, and production infrastructure run higher.

What matters is that the price is scoped per project and tied to specific deliverables, not tied to model quality metrics. An agency that promises 90% accuracy for a fixed price either does not understand what accuracy means in your context, or plans to hit that number by trivial means (predicting the majority class always, cherry-picking the evaluation set). Neither outcome serves you.

Retainer or ongoing model support after handover is legitimate. Retraining cadence, drift monitoring, and feature engineering as the business changes are real ongoing work. The retainer should be scoped separately from the initial build - if it is bundled, the agency has less incentive to deliver a system you can operate independently.

A real custom ML engagement involves at least one ML engineer, one backend or infrastructure engineer, and one domain-savvy product person who translates between your team and the ML work. Smaller agencies often combine these roles across two people. Larger agencies spread across more. The critical thing is that the ML engineer is not just a prompt engineer with a different title. Ask about their gradient boosting production experience, their PyTorch or TensorFlow background, their offline evaluation methodology.

The single biggest way to save money on ML work is not doing it when you do not need to. Off-the-shelf APIs from Anthropic, OpenAI, and open-weight providers cover a large percentage of what teams reach for custom ML to solve. RAG over your docs beats fine-tuning for most domain-knowledge injection tasks. Rules-based systems beat ML for many decisions where the rules are stable and the audit trail is a compliance requirement.

An agency that can identify when your problem is not a custom ML problem, and refers you appropriately, is more valuable long-term than an agency that always sells custom ML. This is what real agencies do on discovery calls. The referral back to an API integration when that is the right answer is a signal of trust, not lost revenue.