The first generation of agent governance focused on whether an action should be allowed. That is necessary, but it is only half of the trust problem. After an agent acts, a different claim begins: what actually happened?
The missing question appears after execution.
A guardrail can authorize a tool call, a transaction, a deployment or a workflow transition. But a later record that says CONFIRMED, REFUTED or UNPROVEN is not the same kind of object as the authorization decision that preceded it.
The authorization belongs to decision provenance. The later observation belongs to outcome provenance. Conflating the two makes a system look more certain than its evidence actually supports.
Four questions
Was the action authorized?
Is the claimed outcome bound to this execution?
What outcome was observed?
Who observed it, from what vantage, against what evidence?
Source class is necessary — and insufficient.
An outcome can be described as agent_reported, attested or recomputable. That tells a verifier something important about how the outcome was established. It does not necessarily identify the observer or the observation surface.
Two records can both be attested while coming from materially different positions:
source_class: attested outcome_observer_id: verifier-A outcome_vantage: ethereum_rpc source_class: attested outcome_observer_id: wallet-provider outcome_vantage: internal_ledger
The label is the same. The trust path is not.
A real implementation comparison exposed the gap.
In a public CrewAI architecture discussion, an external implementer compared a shipped verdict_outcome mechanism against a provider-neutral causal provenance proposal rather than merely agreeing with it in the abstract.
The comparison found independently arrived-at overlap: outcome records already carried their own source_class, separate from the decision-side source class; the later record cited the earlier decision; and the outcome evidence mechanism travelled with the observation.
But the comparison also exposed a specific missing axis: no distinct outcome_observer_id and no distinct outcome_vantage beyond source_class.
Keep the two provenance legs separate.
A binding authorization receipt proves that a decision allowed an action under some policy and evidence. An outcome receipt proves what was later observed. Neither should silently claim independent execution replay unless the cited evidence actually supports that stronger verification class.
The useful design rule is therefore:
decision_provenance != outcome_provenance shared vocabulary: source_class observer / issuer identity vantage evidence refs timestamps / anchors trust context
Why this matters beyond guardrails.
The same distinction appears wherever agents touch consequential state: programmable wallets, payment APIs, escrow, settlement, cloud infrastructure, code deployment, database mutation and agent-to-agent workflows.
Consider a payment agent. The policy engine may correctly authorize a $500 transfer. The payment API may return a timeout. A ledger may later show a debit. A blockchain observer may show settlement. A webhook may say completed. These observations are not interchangeable simply because they all appear after the same authorization.
A verifier needs to know which execution they refer to, which observer produced each fact, which vantage that observer had, and what evidence supports the conclusion.
This is where verification becomes infrastructure.
As agents become more autonomous, the market will not only need systems that answer can the agent act? It will need systems that answer what did the action actually do, and can someone independent verify that causal path?
That suggests a broader verification surface around outcome receipts, observation identities, causal binding, evidence portability and cross-vantage reconciliation.
The next test should be falsifiable.
The observer/vantage distinction becomes useful only if it changes verification behavior. A small conformance suite should be able to distinguish same source class with different observers, the same observer using different vantage points, missing observer identity, ambiguous vantage, and evidence mechanisms that cannot support the claimed observation surface.
Open production question
When your agent reports that an authorized action succeeded, can a third party determine who actually observed that success — and from where?
If the answer is “we have a status field,” that is not yet the same thing.
Agents do not become trustworthy merely because they were authorized. Consequences need witnesses, and witnesses need provenance.
Evidence boundary
This feature treats the CrewAI thread as public production-discussion evidence of independent architectural convergence and a concrete logged gap. It does not claim CrewAI adoption, endorsement, certification or completeness. Detailed source notes are preserved in the repository alongside the article.