Most companies are not training custom models. They are consuming frontier models and building systems around them. That may change as inference cost and optimization become more immediate constraints, but the dominant form of AI adoption today is not the model itself. It is the agent.
Every company may not train a model, but every company will build and deploy agents. That makes confidence in agent behavior one of the most broadly relevant problems in AI adoption: how do you know what an agent will do once it is given access to the systems where real work happens?
The value an agent brings to an organization grows with the breadth of its access because more digital work can be moved off a person. An agent that can only generate text has a limited scope of action. An agent that can read from internal systems, make API calls, write to a database, or trigger downstream actions can take on substantially more work.
The tension is that the same access creates exposure. Once an agent can read and write to those systems, incorrect behavior has consequences beyond a bad response. Agent development moves necessarily toward more access, more access produces more exposure, and the problem becomes how to establish confidence in behavior before that behavior reaches production.
Agents are non-deterministic by definition. If the behavior were deterministic, you would not be building an agent; you would be deploying regular software. That makes unit testing an imperfect analogy. In a unit test, a particular input can be mapped to a particular expected output. For an agent, there may be many acceptable outputs and many acceptable trajectories through a task.
You cannot encode an exact match for the final response, and often you cannot prescribe the exact sequence of tool calls that should be followed, especially as the responsibilities delegated to agents become longer and more complex. Evaluation instead has to define the boundaries of acceptable behavior: what must be true, what must not be true, and which more subjective dimensions of correctness need to be judged according to the business context and the objective of the task.
Before you can interpret agent behavior, you need a body of behavior to interpret. Producing that evidence requires somewhere for the agent to execute.
For many teams, that environment is production itself. The resulting evidence is tracing: a record of what the agent did after a customer or internal user had already experienced it. Tracing is necessary, but it answers a retrospective question. A system designed to establish confidence before deployment has to answer the prospective one.
That requires isolated environments symmetric to production: environments that model the surfaces an agent reads from and writes to closely enough that its behavior can be observed without creating production consequences.
Then you need a scenario suite.
The set of things an agent might encounter is effectively infinite, so the objective cannot be exhaustive coverage. The suite has to be representative and diverse. It should exercise common workflows, edge cases, high-consequence actions, known failure modes, and the kinds of ambiguous situations where behavior tends to become unstable. As failures emerge in development or production, those failures should become scenarios the system continues to screen for.
Producing evidence is only half of the problem. You also need a methodology for interpreting it consistently.
Some dimensions of correctness can be stated definitively. A write happened or it did not. A required tool was called. A prohibited action was not taken. A particular piece of state was preserved. Other dimensions are necessarily more subjective: whether the agent resolved the task appropriately, whether its reasoning was grounded in the available context, whether the outcome satisfied the intent behind the request.
Even explicit definitions of correctness are incomplete. You often do not discover a dimension of behavior worth measuring until something goes wrong.
This is where accumulated evidence becomes important. Agent evaluation is not only about deciding whether a single run was good or bad. A scenario should accumulate evidence across many versions and many executions of an agent. That history creates a behavioral baseline. It tells you whether something observed in a new version is a legitimate regression, ordinary variance in a non-deterministic system, or a behavior the agent has exhibited all along.
Production observability plays an important role here. It reveals dimensions of correctness nobody thought to encode beforehand. But the value of discovering a failure in production is only fully realized when that failure becomes something the evaluation suite screens for before the next deployment.
With those pieces in place, establishing confidence in agent behavior begins to resemble testing the rest of your software.
The agent executes against a production-symmetric environment rather than production itself. It runs across a suite designed to be representative rather than exhaustive. Its behavior is evaluated against explicit invariants and business-specific judges. The resulting evidence is compared against the history of prior versions to determine whether a change has introduced a regression.
None of these pieces are static. As an organization and its agents mature, the environment has to evolve with the systems the agent can access. The scenario suite has to evolve with the work being delegated. Evaluation criteria have to evolve as new dimensions of correctness become visible. And accumulated evidence should show where the suite itself is thin, whether that means edge cases it never reaches or business-specific behaviors it never screens for.
These are primitives that should be table stakes for every company shipping agents. The standard should be continuous evaluation before deployment rather than observation only after it.
Codifying confidence means turning acceptable agent behavior into something that can be exercised, observed, judged, compared, and enforced before an agent is live.
This is what we are building at Dystopic.