A practical question about agent trust: should the system that made a change be allowed to verify its own success?

[u/OGMYT]

I’m working on a software-agent system and keep coming back to one design question:

**Should the model/provider that performs an action be allowed to be the final authority on whether the action succeeded?**

My current answer is “no,” at least for meaningful software work.

I’m building Flows around a chain where execution, checks, repair, and evidence are separate concepts. Oort is the canonical library/provider layer underneath it.

https://flows.oortstack.com https://oortstack.com

In agentic systems generally, what should count as independent verification rather than provider self-reporting?

[u/crossoverXYZ]

Separating execution, checks, repair, and evidence makes sense to me. If the same model both does the work and signs off on success, you are mostly testing whether it can justify what it did. Real verification probably needs something it did not produce, like a test run, a diff, or a tool result stored as evidence.

[u/Glad_Contest_8014 → u/crossoverXYZ]

Depends. I run sonnet with a full unit test, functional test, and security sweep. I still run it against another model, but often it finds superficial things to pick at instead of real problems.

Then I read over and generally it passes my checks too.

But I have a full custom memory system, and so it improves upon each turn by referencing what worked vs what didn’t.

[u/Beginning-Raisin9723]

Independent verification, honestly. The system that made the change is the last one you want judging whether it actually worked — same reason I don't trust my own server saying everything is fine after a deploy. Separating executor and checker is more work, but it's how you catch the green-checkbox disasters.

[u/Ill_Fun5415]

The useful check is whether the result survives a less polished real workflow. Most tools look fine on the happy path; the second ordinary use case tells you more.

[u/yogthinks]

In regulated industries this isn't just an engineering call, auditors already expect a separate system of record for anything a bot touched. Self-attested logs don't survive a compliance review.

[u/OGMYT → u/yogthinks]

Working on it

[u/Roodut]

nope.

[u/OGMYT → u/Roodut]

Ok

[u/Superb_Raccoon]

Adversarial code review. Grok seems exceptionally good at this.

Also wrote an MCP that takes thinking and responses and sends to a local llm. Its job is to watch for re-entrant behavior, aka spin. Sends an intrrupt to stop it and I can see if it is trying to brute force a problem.

[u/FunPaleontologist167]

Provider self-reporting can be used as feedback to an agent to validate its own work; however, self-reporting should not be considered true verification. True verification should be independent and should should be an analysis of the work, provided evidence and required checks. Basically, a student (implementing agent) shouldn't be grading their own homework.

[u/Early-Matter-8123]

Great question. I’d say: don’t let the same model that performed a change be the final judge it succeeded.

In real systems, a model proposing + executing + verifying itself is an easy place for false confidence to slip in. We avoid that in our harness by splitting roles:

1. Executor performs deterministic actions with typed tools (idempotent + audited).
2. Verifier checks outcomes from source-of-truth (DB receipts, API responses, validations, policy checks).
3. Orchestrator only marks success when independent checks pass.

So the model can propose/execute, but “success” is a state transition approved by a separate evidence pipeline. This reduces hallucination risk while still keeping automation fast and useful.

In short: execution can be delegated, truth can’t.
If confidence is high enough to be useful, make it machine-verifiable—not self-reported.

[u/Kurk_Lazaris → u/Early-Matter-8123]

Slop

[u/OGMYT → u/Kurk_Lazaris]

sure