200 OK Is Not an Outcome: The Missing Check in AI Agent Workflows

Adam Mangan — Thu, 08 Oct 2026 08:38:31 +0000

Your agent calls the right tool. The API returns 200 OK. The trace is green. The agent reports the job complete.

Now inspect the place the task was meant to change.

The target is wrong. Or the result is incomplete. Or the evidence belongs to an earlier state. Or the authority under which the task began has changed.

Nothing in the success response has to be false. The mistake is promoting that response into a stronger claim: the authorised outcome is VERIFIED.

I came to this problem while building an advanced Director Bridge and AI Production Suite intended to make AI do work inside complex professional software. I was not asking a chatbot for an answer. I was asking a system to carry out tasks that changed something beyond the chat window.

My background is in diagnosing mechanical and computer-controlled machinery. In that world, a command to an actuator, a lit indicator and the actuator’s actual position are different facts. You check the machine under the real load. That habit followed me into software.

It eventually became UAEP — Universal Agent Execution Platform. The platform is aimed at execution assurance across heterogeneous systems, not at replacing the model, tool, workflow engine or external authority system.

Four things developers often collapse into one

When an agent says “done,” ask which fact has actually been established:

The request was accepted. A service acknowledged an input.
An operation ran. A tool or workflow produced an execution result.
The destination changed. The required external state actually exists at the intended target.
That outcome is currently justified. The observation is applicable to the authorised objective and has not silently become stale or irrelevant.

These are related, but they are not interchangeable. A green trace can establish the first two while leaving the last two unresolved.

Consider a simple review exercise in your own system: let the agent complete its normal tool path, but make the intended destination unavailable for independent observation. Does the system still say “verified”? If so, the status is claiming more than the evidence supports.

Then try a different case: let an earlier action genuinely succeed, change the objective or its authority basis, and see whether a cached receipt is treated as continuing permission for a later action. Historical evidence can remain true without authorising what happens next.

These are questions about the meaning of success, not about whether your HTTP client works.

What an honest boundary must say

For a consequential action, “I checked recently” is not necessarily the same as “this was authorised when the effect committed.” If authority can change between those moments, the external execution path needs an enforceable condition at the relevant boundary. An assurance system cannot truthfully claim to have prevented an unguarded external effect merely because it classified the effect as wrong afterward.

That distinction mattered in UAEP’s own testing. External developers raised falsification cases. The first exposed a real weakness at an external assurance boundary. A later, broader campaign found an external enforcement failure. I preserved those results, corrected the affected boundaries and reran the hostile cases rather than changing the expected answers.

The final bounded, self-run synthetic successor campaign scored 29/29 cases with zero protocol errors, zero false VERIFIED conclusions and zero false-authorised consequential effects in the tested strict path. Seventeen legitimate authorised effects committed. This is an internal measured result, not an independent audit, universal guarantee or production-security certification.

The useful principle is simpler than the numbers:

Planning expansion must not become authority expansion. Execution success must not become verified destination reality by assumption.

A question worth bringing back to your team

The next time an agent completes a task, do not stop at “Did the tool return success?” Ask:

What external state was authorised? What state exists now? What observation establishes that fact? Does the observation apply to this execution and this current objective?

If the destination cannot be established, UNKNOWN is a useful answer. It is much safer than manufacturing VERIFIED from a confident completion message.

I am Adam Mangan, an independent Australian inventor. UAEP is the execution-assurance platform that grew from that question. Its implementation is confidential while I explore commercial options. An Australian provisional patent application was filed 16 September 2026 — application no. 2026907889.

Read my full inventor story and explore the public UAEP site. If you have a bounded, reproducible counterexample to a claimed VERIFIED outcome, I want to hear it.

DEV Community: Adam Mangan

200 OK Is Not an Outcome: The Missing Check in AI Agent Workflows

Four things developers often collapse into one

What an honest boundary must say

A question worth bringing back to your team