This announcement touches a systems problem I’ve been working on from a different direction.
Once an agent can run long-lived workflows, call tools, operate in sandboxes and modify external systems, I think there is another boundary worth separating:
EXECUTION SUCCESS ≠ VERIFIED DESTINATION REALITY
An agent can select the correct tool.
The tool can execute successfully.
The API can return 200/OK.
The workflow can report complete.
And the required external destination state can still be wrong, stale, incomplete, unresolved, or supported by evidence that does not actually justify the conclusion being claimed.
That led me to build a deterministic execution-assurance layer I call UAEP — Universal Agent Execution Platform.
The question it asks after execution is:
Did the authorised action actually produce the required external destination state, and is the available evidence applicable and sufficient to truthfully call that result VERIFIED?
Where that cannot be established, the system preserves UNKNOWN / NOT_VERIFIED rather than treating successful execution as proof of outcome.
Three assurance relationships ended up surviving the work so far:
DestinationConformance
Does observed destination reality actually satisfy the authorised objective?
EvidenceApplicability
Does the evidence genuinely apply to this objective, execution, resource, version, authority and environment?
RecoveryClosure
After failure, repair, rollback, compensation or re-entry, has the original objective actually been closed and independently reverified?
The difficult cases turned out to be much nastier than simple tool failure.
Some of the conditions I’ve been attacking include:
- a remote action may have committed but the response was lost
- blindly retrying could duplicate a consequential external effect
- multiple retry layers may unknowingly amplify the same operation
- an API can return success while the required destination state is still wrong
- a backend can accept work and fail later
- cancellation can return success while the operation still crosses its commit point
- evidence can be authentic but stale
- evidence can be correct but belong to the wrong objective, execution, resource, version or environment
- several verifiers can agree while depending on the same poisoned or stale source
- events can be duplicated, replayed or arrive out of causal order
- concurrent writers can both appear locally successful
- 999 of 1000 operations can succeed without justifying a full-success conclusion
- compensation can report success without actually restoring the required state
- an operation can succeed after an authorised deadline and still fail the actual objective
- valid old state can reappear and look current
- authority can expire or be revoked while work is still in flight
- the execution environment or backend can change underneath an apparently valid result
- a provider can change semantics while existing evidence still looks superficially valid
- units, locale or reference-frame differences can make apparently valid evidence mean the wrong thing
- the observer can time out while the worker reports completion, or vice versa
- recovery can appear operationally successful while the original objective remains unverified
- the assurance layer itself can become overloaded or degraded
- there may simply be no sufficiently authoritative way to observe final state
- an entirely new failure may occur that does not fit any existing classification
In those cases, I don’t think the right answer is to force the event into SUCCESS or FAILURE.
If the evidence cannot justify the conclusion, UNKNOWN has to remain a legitimate engineering state.
The current implementation has been through reproducibility and replay testing, conditional-finality / authoritative-readback cases, independent physical-observer testing and bounded black-box evaluation.
Within the qualified demonstrations, false VERIFIED remained at zero.
I also built a bounded black-box evaluator because I don’t want this judged only from my description of the architecture. The useful test is whether an independent reviewer can construct a case that makes the implementation incorrectly promote an unresolved, stale, mismatched or insufficiently evidenced result into VERIFIED.
I’m not looking for agreement.
I’m looking for the case that makes it lie.
For people building long-running agents, tool execution, orchestration, distributed systems or autonomous workflows:
What is the nastiest realistic situation you can construct where every visible layer appears successful, but the external destination reality should still remain UNKNOWN or NOT_VERIFIED?
If somebody identifies a genuinely new failure class, I’ll formalise the assumptions and expected failure condition first, then attack the current implementation with it rather than moving the goalposts after seeing the result.
