You Didn't Deploy the Agent You Evaluated
AI teams are getting very good at evaluating agents.
We build datasets. We run experiments. We score outputs. We compare models, test prompts, inspect traces, add human review. We set thresholds and decide an agent is ready for production.
Then we deploy it.
And something subtle happens. The thing running in production may no longer be the thing we evaluated.
A prompt changed. A tool schema changed. A policy changed. The knowledge available to the agent changed. A fallback selected a different model. Memory changed what entered the context window. Retrieval returned different evidence. A credential exposed a capability the evaluator never exercised. An orchestration layer sent the request down a different path.
Every individual system may be working exactly as designed. Yet the organization can no longer answer a deceptively simple question:
Is this the agent we approved?
That question is about to become one of the defining infrastructure problems of agentic AI.
Evaluation is necessary. It is not authorization.
Most AI engineering has been built around a familiar loop: build, evaluate, improve, deploy, observe. It is enormously useful. But agents introduce something passive AI applications don't have: agency.
An agent can call a tool. It can retrieve sensitive information. It can talk to another agent, modify a system, spend money, or make a decision that triggers another decision.
Once models can act, knowing that an agent performed well in an experiment is no longer enough. A production system has to answer a different set of questions:
What exactly was evaluated? What exactly was approved? What is being authorized right now? What actually executed? What information did it see? What capabilities did it hold? Which policies applied? What actions did it take? And can we prove all of that afterward?
These are not observability questions. They are questions of identity and authority.
The missing primitive is behavioral identity
We identify agents by convenient labels: customer-support-v4, research-agent, production, latest.
Those names describe what humans intend. They do not describe behavior.
An agent's behavior depends on far more than its name or its model. Its instructions matter. Its tools, policies, knowledge, memory strategy, retrieval configuration, model configuration, and surrounding runtime all matter. Change enough of those and, operationally, you have changed the agent, even if its name stayed exactly the same.
That leads to a principle we believe will become foundational for enterprise agents:
An agent should have an identifiable behavioral revision that follows it through evaluation, certification, authorization, execution, and audit.
The important part isn't how that identity is represented. The important part is that it exists.
Certification must bind to something real
Imagine an agent passes 1,000 evaluation cases on Monday and is approved for production. On Tuesday, someone edits its system instructions.
Should Monday's certification still apply?
What if its tools change? Its knowledge? Its security policy? Its model?
At some point the answer has to become no. Otherwise certification is merely a historical statement: something resembling this agent once passed these tests. That isn't sufficient for systems that take consequential actions.
Certification should instead mean: this identified agent behavior satisfied this identified set of requirements using this identified body of evidence. And authorization should be able to reason about that fact at runtime.
A different lifecycle for agents
We think the production lifecycle for agents will look less like ordinary model deployment and more like a governed chain.
Each transition answers a different question. Declare: what is this agent supposed to be? Evaluate: how does it behave under controlled conditions? Certify: does the evidence satisfy our requirements? Authorize: is this certified agent permitted to take this action, here and now? Execute: what actually happened? Observe: how is it behaving in the world? Audit: can we reconstruct and prove the chain afterward?
The power comes from connecting the stages. An evaluation platform can tell you how an agent performed. An observability platform can tell you what a model call did. A policy engine can tell you whether a rule returned allow or deny. An audit log can tell you an event occurred.
Enterprises need to connect those facts into one answer: why was this agent allowed to do this?
Context is part of the execution
There is an uncomfortable consequence here. For an AI system, the code is not the whole program.
An agent's effective behavior is partly constructed at runtime from context: instructions, conversation history, retrieved knowledge, memories, available tools, tool results, policies, the current task. Thousands of tokens are assembled before the model makes a decision.
So observability cannot stop at "Model X received 8,412 tokens." For governed systems, we need the provenance of those tokens. Not by retaining every piece of sensitive data forever, but enough to establish what classes of information influenced the execution, where they came from, and whether they were permitted to be there.
That turns context from an implementation detail into part of the agent's operational evidence.
Observability tells you what happened. Evidence tells you why it was allowed.
Traces are valuable. They let us inspect model calls, tool calls, latency, errors, and flow.
But a trace alone doesn't establish governance. Suppose an agent transfers $40,000. A trace shows: agent → reasoning → payment tool → success.
The governance questions are different. Which agent revision requested the transfer? Was that revision certified? Which policy authorized the action? Which tool capability was granted? What information did the agent have? Was the authorization decision made before the side effect? Did the action exceed a budget or risk threshold? Which evaluation evidence justified allowing this class of action at all? And can an auditor follow that chain without trusting the agent's own explanation?
This is why we believe execution evidence will become as important to agent infrastructure as telemetry. Telemetry helps engineers understand systems. Evidence helps organizations establish trust.
Production should become evaluation data
There is an enormous opportunity hidden in this architecture.
Teams build artificial evaluation environments that approximate production. But production generates the richest evaluation material there is: real tasks, real retrieval, real tool decisions, real edge cases, real failures, real policy interactions.
If execution produces strong enough provenance, a production interaction can become a reproducible evaluation case. Not by repeating every external side effect, and not by pretending a stochastic model will emit identical text. The system preserves enough evidence to ask a far more valuable question:
Given what happened in production, how would the next version of this agent have behaved?
That creates a loop: production → evidence → evaluation → new revision → certification → production. The world becomes part of the test suite.
Replayability does not mean deterministic AI
Large language models are stochastic. A replay system should not promise that the same model will produce the same tokens forever. That is the wrong standard.
The useful standard is reproducible execution evidence. Can we identify the behavior that was running? Reconstruct the relevant context? Identify the external evidence the agent observed, the policies and capabilities that applied, and the model configuration that actually ran? Evaluate another version against equivalent evidence without repeating dangerous side effects?
If so, organizations gain something better than deterministic replay: counterfactual evaluation. What would our new agent have done? Would the new policy have blocked this? Would the next release have prevented this incident?
The system of record for agents
Every major enterprise function eventually gets a system of record. Sales has one. Identity has one. Source code has one. Infrastructure has one.
AI agents will need one too. Not a directory of agent names, but a system that connects identity (what agent is this?), evidence (what do we know about its behavior?), certification (what has been approved?), authority (what may it do?), execution (what did it actually do?), and accountability (can we prove the chain afterward?).
We call this emerging category the Agent System of Record. Its purpose isn't to replace models, agent frameworks, evaluation tools, or observability systems. It is to establish the trust boundary around them.
Trust should not come from the agent
One final principle. An agent should not be trusted because it says it did the right thing. It should not approve itself. It should not define the evidence used to certify itself. And its explanation after the fact should not be the sole source of truth about what occurred.
Trust has to come from independently recorded evidence and independently enforced controls. That is a familiar principle in security engineering. It will become just as important in agent engineering.
From intelligent agents to accountable agents
The first era of generative AI was about capability. Can the model write, reason, code, use tools, operate autonomously?
The next era is about controlled capability. Should this agent be allowed to act? Which version? Under what policy? With which capabilities? Based on what evidence? Who approved it? And can we prove afterward that those conditions actually held?
Organizations running thousands of agents will not answer those questions with spreadsheets, disconnected traces, and naming conventions. They will need infrastructure that treats identity, evaluation, certification, authorization, execution, and evidence as parts of the same lifecycle.
The future of enterprise agents isn't simply autonomous. It is accountable.
If your organization is moving from experimenting with agents to allowing them to act, the question changes from "Does it work?" to "Can we trust it to act?"
Multisynapse is the Agent System of Record we're building for that transition.
Evaluate what you intend to run. Certify what you evaluated. Authorize what you certified. Prove what actually ran.