2
4 Comments

Your AI agent says it stopped the action. Can you prove it?

I’m looking for one company running AI agents that can actually do something consequential.

Not generate a summary.

Not answer a question.

Not produce a draft for a human to approve.

I mean an agent that can:

  • move money
  • change customer data
  • modify infrastructure
  • trigger an external service
  • approve or reject something
  • execute an operational action

I want to test one question against a real production architecture:

If that agent loses authority after it has started working — but before the action actually happens — what stops the consequence?

And there’s a catch.

“Policy denied it” isn't enough.

“Permission was revoked” isn't enough.

“The agent stopped” isn't enough.

“We logged a denial” isn't enough.

The evidence has to survive the system making the claim.

If an instruction already reached a payment processor, cloud API, CRM, database or another downstream resource, an internal DENIED event does not prove the consequence was prevented.

That gap is what I’m building OpsWatch to independently verify.

We separate three things that are often collapsed into one:

Was the action authorised?

Did the action execute?

What evidence proves the downstream outcome?

That becomes particularly uncomfortable when authority changes while an agent is already operating.

An agent can be legitimately authorised at 10:00:00.

At 10:04:59, that authority can disappear.

At 10:05:00, the action can still occur.

If your architecture can independently prove that the final action was stopped at the resource, excellent.

I want to see it.

If it can't, that's the boundary I'm interested in testing.

I’m not looking for another theoretical discussion about whether AI agents need governance.

I’m looking for organisations already deploying consequential agents, or firms putting those systems into enterprise environments.

Bring me one real workflow.

We’ll freeze the case before testing it.

Then we'll determine what your system can actually prove when authority changes at the worst possible moment.

If it passes, we document that.

If it fails, we find the boundary.

If the answer is uncertain, we don't turn uncertainty into a pass.

Who has a production agent they’re confident would survive that test?

on September 11, 2026
  1. 1

    This is the right layer for agent trust. I’d separate evidence into four checks that must agree: authorization (who/what was allowed), dispatch (intent left the agent), execution (tool/API actually ran), and downstream confirmation (resource state after). Tie them with an idempotency/action ID verified at the resource boundary — otherwise “I stopped it” is just another claim.

    1. 1

      Yes — I think making dispatch explicit improves the model.

      Authorization → Dispatch → Execution → Downstream confirmation

      Those are four different claims, and evidence for one shouldn’t automatically be accepted as evidence for another.

      The dispatch boundary is particularly important because that’s where control can leave the system while certainty about the consequence hasn’t arrived yet.

      An agent can prove it decided to stop.
      An orchestration layer can prove it didn’t intentionally dispatch.
      A tool can prove whether it executed.
      But only evidence at the resource boundary can establish the resulting consequence.

      And I agree on the action/idempotency ID. If the evidence from those layers can’t be bound to the same action, an auditor is left correlating events rather than proving a chain.

      That’s where I think independent assurance becomes interesting: don’t ask one component to tell us the whole story. Preserve the evidence from each boundary and test whether those claims actually agree.

      Because “I stopped it” is only meaningful if the consequence boundary can support the same conclusion.

  2. 1

    The core insight here is about measurement separation. Most organizations measure agent decisions, not outcomes. Authorization, execution, and resource verification are separate measurement problems - but they're building one system ("we stopped it") to answer all three.

    What you're describing is the cost of collapsed metrics: they can't independently prove what happened at the boundary. They're measuring intent instead of consequence.

    The moment authority changes mid-operation, their measurement system breaks because it was never designed to separate "the agent claims it stopped" from "the resource actually prevented the consequence." Those are two completely different measurement systems.

    1. 1

      Exactly. I think “collapsed metrics” is a very good way of describing the failure.

      If authorization, execution and evidence are collapsed into one state, the system can report success or denial without actually proving the consequence.

      That’s why I’m increasingly thinking the important boundary isn’t the agent itself — it’s the point where the action becomes real.

      At that boundary I want three independently answerable questions:

      Was the action still authorized?

      Was it actually executed?

      What evidence exists from the resource where the consequence could occur?

      If those answers can’t be independently established, then “we stopped it” is really only a statement of intent.

      And that’s exactly why I think an unresolved state matters. Uncertainty shouldn’t be silently converted into proof.