When an AI project stalls inside a company, the reflex is almost always the same: go find a better model. Scan the leaderboards, compare versions, wait for the next release hoping that this one will finally do the job.
Jonathan Frankle, Chief AI Scientist at Databricks, dismisses that assumption in one line: "model intelligence is typically not the bottleneck, the models are really smart." He's in a good position to say it - he co-founded MosaicML, acquired by Databricks for $1.3 billion according to VentureBeat, and spends his days deploying AI across thousands of companies.
The real blocker is somewhere else. And it's far less glamorous: you can't tell whether what the AI produces is good.
The problem isn't the engine, it's the missing quality control
Imagine hiring a brilliant new colleague, top-tier degrees, able to write fifty memos a day. Great. Except nobody in your company can read those memos and say "this one is right, that one goes in the bin". Three weeks later, you no longer know whether that hire is making or losing you money. You'll end up handing them only work that doesn't matter.
That's exactly what happens to AI projects. In a VentureBeat investigation into agents that never reach production, Hanlin Tang, Databricks' CTO of Neural Networks, sums it up: teams were "flying blind, they had no way to evaluate these agents". The pilot works in a demo, impresses the steering committee, and dies at the moment of scaling - because nobody can sign off that the output is reliable.
Frankle calls this enterprise AI's missing infrastructure. In his masterclass at Radical Ventures, he makes the diagnosis: adoption is limited less by talent than by "trust, measurement and proof".
Why more horsepower solves nothing
The reason is simple: what matters to your company is always specific. Not "write a good email", but "write the customer follow-up that complies with our commercial policy". Not "analyse some numbers", but, in Frankle's words, "the number the CFO has to report at month-end".
A model can top every leaderboard and still be worth little on that terrain. "What's missing is specificity, and no amount of extra horsepower changes much." In December 2024 Databricks published its own business benchmark suite (DIBS), covering six enterprise cases - finance, software, manufacturing - to show that academic leaderboards don't predict real performance on those tasks.
It's the same intuition we've been arguing for a long time: the model is a commodity, the moat is elsewhere. Everyone will have the same engine next year. What nobody can buy on your behalf is your definition of good work.
Evaluation, to be precise
Behind the word "evaluation" (or eval) sits a very concrete mechanism. An eval is a set of cases representative of your business - a real customer request, a real contract, a real accounting entry - each paired with the criterion that says whether the answer is acceptable. You run the AI on it, count how many cases pass, and get a reproducible score.
When the criterion is too subtle for a simple rule, you use a judge: a second model taught your standards, which grades the first one's outputs. The judge isn't smarter than you - it applies your judgment at scale.
Good news: this doesn't require a data warehouse. Databricks' work, as reported by VentureBeat, suggests a robust judge can be built from 20 to 30 well-chosen examples. The condition: target the edge cases your experts disagree about, not the obvious ones where everyone agrees.
The real work is human
And that's where the difficulty moves. Frankle is blunt: "all problems become human problems. The hardest part is getting an idea out of one person's brain and making it explicit. And harder still is that companies aren't one brain, but many."
Building an eval forces an organisation to write down, in black and white, what it calls a good piece of work - and to settle things when legal, sales and finance disagree. It's uncomfortable. It's also, incidentally, the beginning of a company brain: your criteria, your edge cases, your trade-offs, finally out of people's heads and made usable.
Frankle also recommends moving up in steps: start with a simple prompt on an off-the-shelf model to see whether the task is feasible, then add retrieval and evals, and only consider a fine-tuned model if the return on investment justifies it. You move up a level only once the previous level has proven its value.
What we do
At Elephant, we never start an AI project with the choice of model. We start with the awkward question: how will you know it's good?
In practice: we sit down with your domain experts, collect about twenty real cases - deliberately hunting for the ones they disagree on - and turn their trade-offs into explicit criteria. From that we build an executable eval that produces a score before every release and catches regressions when you switch models.
The payoff is twofold. You get an AI whose quality is measurable, and therefore deployable beyond the pilot. And you can switch models overnight without rebuilding anything: your eval still holds, only the engine gets swapped. Humans stay in control - they define the criterion, settle the ambiguous cases, keep their hands on what matters.
A smarter model improves the answer. Knowing how to judge the answer is what lets you use it.
