Leading the cost and accuracy curve for production investigation

Anyone can make an agent cheaper by making it worse. The aim is to make the trade unnecessary.

What does it mean to lead on the cost and accuracy curve?

Put cost on one axis and accuracy on the other, and every configuration you could ship sits somewhere on that plot. There is a frontier: the best accuracy available at each price, given how well you have built the system.

Two very different things get described as improvement. Moving along the curve means accepting less accuracy for less cost, or paying more for more, and it takes an afternoon. Moving the curve means the same accuracy now costs less, or the same cost now buys more accuracy, and it takes real work. Resolve AI's aim is the second one, stated as pushing the curve to the left.

Latency belongs on this picture as a third constraint rather than a footnote. Accuracy has to be high, cost has to be low, and response time has to be low, and all three pull against each other.

Why isn't the best available frontier model the answer?

Because a single model is one point, and the argument that matters is about the shape of the whole curve. Reaching for the most capable model available answers the accuracy question by giving up on the other two.

For this class of work, the strongest general-purpose models do not land in an acceptable place on all three constraints at once.

What makes production investigation a harder domain than it looks?

Two properties, and neither is about reasoning difficulty in the abstract.

The information is incomplete by default. The agent may not be connected to every system holding a relevant signal, so it has to operate and stay correct without assuming full visibility. Most benchmark work assumes the necessary information is somewhere in the context.

The tool call volume is high. Reaching an answer in a real environment can require a very large number of calls, which is where cost and latency compound. A model capable enough to make progress here tends to be a large one, and running a large model across many calls drives serving cost and response time up hard.

Why doesn't a general-purpose model sit in the right place on the curve?

Because it is built to be domain-agnostic, which is the correct goal for a frontier lab and the wrong fit for a narrow high-stakes domain. One model covering everything is by construction not specialized to yours.

That shows up in one of two ways. Either accuracy on your domain is lower than you need, or accuracy is acceptable and cost and latency become unmanageable. Both are the same problem, which is paying for generality you do not use.

What does a domain-specialist model do differently?

It is built around the properties of the domain rather than around breadth. That means modeling the incompleteness of available information rather than assuming it away, staying efficient because the tool call volume is high, and being deliberately latency-aware, since an investigation that arrives late has lost most of its value.

It also means knowing what to do with the domain knowledge a customer already has, which usually arrives as raw documentation. Processing it and presenting it to the model is a domain skill, and it determines whether that documentation helps or just consumes context.

Building this requires machine learning expertise and operations expertise at the same time. The combination is what is rare, not either one alone.

How do you know you moved the curve instead of sliding along it?

You measure, because from the inside the two are indistinguishable. A change that makes investigations cheaper feels like progress whether it improved the system or quietly traded away quality, and a change that improves accuracy feels like progress whether or not it made the cost unacceptable.

This is why evals are not a separate topic from cost. They are the instrument that separates a real improvement from a trade, and without them a team optimizing for cost will slide down the curve while believing it is advancing.

The pricing model enforces the same discipline commercially. Resolve AI charges for completed work rather than consumption, so sliding along the curve does not pay in either direction. Cheaper and worse shows up as quality complaints, and better and more expensive comes out of margin. The only move that pays is moving the curve.

Why is this measured on the system rather than the model?

Because a model is not what a customer can use, and a model benchmark is not what a customer pays for. What matters is the cost and the accuracy of a completed investigation, which includes retrieval, memory, orchestration, and every tool call along the way. The model is one component inside that.

The distinction changes what gets optimized. Publishing a model that scores well is a different objective from leading the cost and accuracy curve for a specific kind of work, and only the second one appears on a customer's bill. The goal is to ship a production system that customers can use and be proud of, returning value in money, in time, and in the quality of the answer.

What does this change for a customer?

Most alerts get processed without anyone being pulled in. For the harder ones, the agent reaches a root cause and proposes mitigations with minimal intervention from an engineer, rather than handing back a starting point for someone else to work from.