Why enterprise AI agents need evals, not more users

Lucas Smaira, co-founder of Vetto AI and a former Google DeepMind researcher, published an opinion piece in Brazil Journal, a Brazilian business news outlet, that should be pinned to the wall of every engineering team putting an AI agent into production. His thesis is simple and uncomfortable: the question "how many people use AI at the company" is already irrelevant. What matters is how much work the AI executes end to end, with measurable quality and clear economic return.

I agree with the diagnosis, but I want to pull the thread to where it's actually resolved: in the code, not in the boardroom. Because the gap between "having an agent running" and "having an agent that generates value" doesn't close with more prompt engineering. It closes with testing discipline, the same discipline any mature team already applies to software that doesn't have a single line of AI.

From chatbot to agent: the difference nobody is measuring

Smaira gives a good example: a chatbot tells a customer whether they can return a product; an agent locates the order, checks the policy, issues the label, tracks the return back to inventory, and triggers the refund. In the first case, the AI helps someone work. In the second, it executes part of the work on its own.

The difference seems subtle, but it changes everything about what needs to exist around the system. A chatbot that makes a mistake generates an annoying ticket. An agent that makes a mistake changes a real order, approves a real transaction, or touches a genuinely critical system. The risk stopped being conversational and became operational.

And here's the point I think is most important for people who build this: most Brazilian companies, according to the author himself based on conversations with large companies, no longer have a problem accessing good models. The bottleneck is managing them. Dozens of agents in production, and nobody knows for sure which ones generate value, how much they cost, or where they fail.

Evals are the CI/CD your AI pipeline is missing

Here, the Brazil Journal piece uses a term every engineer should already recognize, just applied to a new domain: evals. These are the evaluations that measure the quality, efficiency, and reliability of an agent's work, the same way a product team uses OKRs to measure people.

Translating for people who write code: an eval is an automated test for model behavior. It's not enough to say a customer service agent "is doing a good job." You need to know:

• What percentage of cases it resolves correctly, using a verifiable criterion rather than a subjective impression.
• In what situations it should escalate to a human and doesn't (or escalates too much).
• Which errors are tolerable and which are unacceptable, categorized by severity.
• How much each correct resolution costs, in money and time.

Without that layer, the agent is an experiment dressed up as a product. With it, it becomes an engineering discipline, with the same rigor you already apply to an integration test suite before a merge into main.

The metric that separates those who evolve from those who stagnate

The piece's most concrete example is also the most useful for engineering. Two companies with agents of similar quality: at the first, identifying a failure, fixing it, and validating a new version takes six weeks. At the second, production interactions feed the evals automatically, every new error becomes a test case, and regressions surface before reaching the customer. The cycle takes two days.

If I had to pick a single metric to evaluate a company's AI strategy, it would be this: how long it takes for a production error to become a test and for the fix to reach the customer.

Lucas Smaira, co-founder of Vetto AI and former Google DeepMind researcher

This metric is essentially fix lead time, the same concept that DevOps Research and Assessment (DORA) has used for years to measure software delivery maturity. The novelty isn't in the metric, it's in applying it to systems that make probabilistic decisions instead of executing deterministic logic. It's an observability and pipeline problem, not a model problem.

The counterargument the piece doesn't face head-on

Here I need to disagree with one point, or at least add to it. The piece cites programming and mathematics as the domains where models advance fastest, precisely because it's possible to verify whether the answer is correct. That's true, and it's exactly why building evals for those domains is relatively cheap: there's an objective verification function (the code compiles, the test passes, the proof closes).

The problem is that much of corporate work doesn't have that property. Assessing whether a customer service agent "handled" an ambiguous case well, whether a sales agent conducted a negotiation acceptably, or whether a legal agent interpreted a contract reasonably requires human judgment, which isn't always reducible to a binary metric. Building reliable evals for judgment-based tasks is an engineering project as large as the agent itself, sometimes larger.

This creates a risk the piece doesn't mention: companies will naturally automate what's easy to measure first, not what generates the most value. The result could be an ecosystem of agents that excel at trivial, verifiable tasks while remaining just as immature as today at the tasks that actually move revenue, because those are the hard ones to evaluate.

What changes for the people who build this

If you're the one writing the agent's code, not the one signing the quarterly results report, the practical message is direct: stop measuring success in number of agents published or tokens consumed, and start instrumenting each agent as if it were a production service with an SLO.

In practice, that means:

1. Defining, before publishing an agent, what the verifiable success criterion for its task is, not afterward.
2. Building an eval harness that runs on every change to the prompt, the model, or the tool, like a regression test.
3. Instrumenting production to capture real failure cases and automatically convert them into new test cases, closing the loop the piece calls a miniature recursive self-improvement.
4. Prioritizing, at least at the start, tasks with an objective success criterion, and treating judgment-based tasks as a separate project, with sampled human evaluation.

The Brazil Journal piece's final point is that access to the best model will stop being a competitive advantage, because everyone will have access to very good models. I agree, and I'll add: the advantage will belong to whoever already has mature testing infrastructure when that moment arrives. That isn't bought in a funding round or hired over a weekend. It's engineering work, built case by case, eval by eval, just like it's always been with software nobody wanted to see break in production.