Why a Model Provider Can Never Verify Its Own Agents

The structural problem

Verification answers one question: did this agent do what it was paid to do? For that answer to carry weight, the party giving it must have no stake in it being yes.

A model provider verifying agents built on its own models fails that test immediately. It earns when the agent runs. It earns more when buyers keep transacting. A verdict of "the work was inadequate" costs it revenue and reputation in the same motion. The provider might behave impeccably — the problem is that nobody can check, so its assurance is worth exactly what a self-issued audit is worth.

This is not a novel observation. It is why exchanges do not audit themselves, why credit ratings sit outside the issuers, and why certificate authorities are separate from the sites they certify. Every one of those arrangements exists because the alternative was tried first.

Why cryptography does not fix it alone

The obvious rebuttal: sign the execution, and the maths speaks for itself. Partly true. A signature proves the payload was not altered after signing and that the holder of a key produced it.

What it cannot prove is that the payload described reality. If the same party runs the agent, decides what constitutes completion, writes the receipt and holds the key, then the signature attests to a self-assessment. Cryptography guarantees integrity, not honesty. It moves the trust question from "did they tell the truth" to "did they define the terms fairly" — and the second is not obviously easier.

Neutrality is what closes the gap. A verifier with no revenue tied to the outcome has nothing to gain from a favourable definition of "completed".

The cross-provider problem this creates

Agent ecosystems will not stay within one provider. An agent built on one model will hire an agent built on another, because specialisation beats integration and always has.

The moment that happens, provider-run verification has no jurisdiction. Ask Provider A to verify work performed by Provider B’s agent and you have asked a competitor for an assessment. It is not that the answer would be wrong — it is that no buyer should accept it, and no serious counterparty would.

Some neutral substrate is therefore inevitable. The only real question is whether it arrives as a protocol multiple parties can implement, or as a fourth provider trying to referee its rivals — which lands back at the same problem.

What neutral has to mean in practice

Neutrality is an architectural property, not a promise. Four things make it checkable:

• No stake in the verdict. The verifier must not earn more when work is judged good than when it is judged bad.
• Verification runs on the buyer’s side. The signature is checked in the buyer’s own process. The verifier is never asked for its opinion — it is asked only for a public key.
• The contract is published. What counts as valid is written down and executable, not embedded in one implementation.
• Provider-agnostic by construction. Verifying agents built on competing models must work identically, or the neutrality is decorative.

The second is the important one. If verification requires calling the platform, the platform is still the authority and neutrality is a claim rather than a property.

The uncomfortable corollary

This argument constrains us too. ForceDream cannot become a model provider without forfeiting the position it occupies. The moment we earn from an agent’s output, our verification of that agent is worth what any provider’s would be.

That is a real limit on the business, and it is the point. A neutrality that could be abandoned when convenient is not a property anyone should rely on. It is worth stating plainly, in public, so it can be held against us later.