We keep finding the same pattern: a failure mode appears to be solved, then reappears one layer later in a form that is harder to see.
Better generation does not remove uncertainty. Better retrieval does not guarantee that the right evidence was selected, interpreted or allowed to influence an action. Stronger policy does not prove that execution stayed inside the policy boundary. A signed receipt does not prove that the underlying event happened exactly as claimed. Each improvement can reduce one class of error while moving the unresolved part of the problem somewhere else.
Failure migrates across the stack
In ordinary software, we often isolate faults by component: input validation failed, a query returned the wrong row, a permission check was missing, or a deployment changed behavior. Agentic systems complicate that model because decisions are distributed across retrieval, reasoning, tools, credentials, external services and state changes. The visible answer may be correct while the execution path is not. The requested action may be permitted in theory while the effective authority at the moment of execution is broader than intended.
This is why capability, authority and execution need to be treated as different things. A system can describe what an agent is capable of doing, what it was granted permission to do, what credentials made reachable, what action was actually dispatched, and what changed afterward. Those states can overlap, but they are not interchangeable. Collapsing them into a single “allowed” or “successful” label hides the exact place where assurance is needed.
Retrieval moved the uncertainty problem
Retrieval-augmented systems are a good example. Retrieval can reduce unsupported generation by grounding a model in external material, but it creates another chain of questions: where did the material come from, was it current, was it transformed, which parts influenced the decision, and was the information permitted to flow to the destination that received it?
The same issue appears in provenance. Recording a source is useful, but provenance becomes much more valuable when it survives transformation. If private information is summarized, combined with public information and then passed into a tool call, the security question is no longer limited to the final text. It includes the trajectory that produced it. Provenance has to follow the data far enough to constrain what can happen next.
Receipts are evidence, not reality
Receipts, signatures and attestations can make agent activity much easier to inspect, but they introduce an evidence ceiling. A cryptographically valid record proves only the claims that are actually bound to the verified material. A signature can establish who signed a record and that the signed bytes were not altered. It does not automatically establish that a runtime measurement was genuine, that a signing key belonged to the measured runtime, or that an external side effect occurred exactly as the record says.
That distinction matters because agent systems increasingly produce their own explanations of what happened. Self-reported evidence is useful, but independent evidence is stronger. The verifier should be able to separate the agent’s claim, the authorization decision, the dispatch boundary, the observed state change and the final receipt. Where those sources agree, confidence can increase. Where they diverge, the system should preserve the disagreement instead of flattening it into a pass.
Uncertainty should survive the pipeline
One recurring design mistake is forcing every stage to produce a definitive answer. Sometimes the correct result is not “allowed” or “denied,” but “not established from the available evidence.” Missing evidence should remain missing. A verifier should not upgrade an incomplete observation into a stronger claim simply because downstream software expects a boolean.
This leads to a practical rule: every layer should have a claim ceiling. Policy can establish a policy decision. A gateway can establish what it dispatched. An observer can establish what it observed. A receipt can bind specific evidence. None of those components should silently promote its result into a claim about facts it did not independently establish.
Verification has to include the transition
The most consequential part of an agent action is often the transition between intention and resulting state. An agent may intend to edit one file, call one endpoint, transfer one value or update one record. The assurance problem is not finished when the action is authorized. We also need to know whether the dispatched operation matched the authorized operation, whether the expected prior state was still valid, what changed, and whether an independent observer can bind the result back to the original authority.
That makes drift a first-class concept. Intended state, authorized state, executed state and observed state can diverge. Detecting that divergence after the fact is useful; preventing it from being hidden is more useful. A trustworthy system should preserve enough evidence to explain where the path separated and what can still be established.
The architecture matters more than the label
Terms such as governance, safety, provenance and verification can sound complete while referring to very different boundaries. The useful question is not whether a system “has governance.” It is which decisions are governed, where enforcement happens, what authority is actually reachable, what evidence is independently observable, and which claims remain unproven.
That is the direction our recent work keeps reinforcing. The goal is not to make agents sound more certain. It is to make the surrounding system more precise about what was requested, what was permitted, what was reachable, what executed, what changed and what can be independently verified afterward.
The failure didn’t disappear. It moved. The next problem is building systems that can explain, constrain and prove what actually happened.