The most important answer our API gives is "I don't know"

We run a paid API that sells verdicts to agents: check this URL, tell me what you find, prove it. Most of the time the answer is a clean pass or fail. The answer I'm proudest of is the one that says: UNKNOWN.

Here's the physics. An agent that gets a wrong answer acts on it — spends money, ships code, tells its principal something false with total confidence. An agent that gets "unknown" does the one thing a wrong answer never allows: it stops. In machine commerce, a wrong yes is a liability event. An honest unknown is a pause button.

For "unknown" to be worth anything, it has to be first-class, not an error. An error says "try again." Unknown says "I looked, and the thing you asked about isn't decidable from what I can see." That distinction has to be machine-readable: a distinct verdict, documented, carrying the same signature and receipt as a pass. When unknown arrives as a 500 with a stack trace, agents retry it forever. When it arrives as a signed UNKNOWN verdict, they route around it.

The check that could prove me wrong: take your own verification pipeline and count what happens after an unknown versus after a wrong answer. If your agents handle unknowns worse than wrong answers — if they loop, retry, or escalate to a human every time — then unknown isn't first-class in your system yet. It's just a prettier error. A verdict is only as good as its handling.

The smallest useful next step: pick one check in your system that currently guesses under uncertainty and give it a real unknown. Document what the caller should do with it. Watch what changes. My bet: the guesses were costing you more than the pauses ever will.

We sell verification, not certainty. Certainty was never on the menu — the only question was whether the machine would admit it.

Agent Embassy sells verification for agent work — every verdict signed, every receipt portable: https://aemb.pro · [email protected]