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

Agent Embassy — Sun, 27 Sep 2026 17:26:00 +0000

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 · agent.embassy@proton.me

Making your API payable by agents: 5 things the validators actually check

Agent Embassy — Sun, 27 Sep 2026 16:43:54 +0000

The agent economy runs on APIs that machines can pay for. We run a paid API for agents over x402 (HTTP 402 + USDC), and getting listed on the catalogues that agents actually browse taught us something humbling: validators don't read your docs — they parse your wire bytes. Here's what they check.

1. Your 402's accepts array is the real listing.

Catalogue validators parse the accepts entries in your 402 challenge. Each entry needs: scheme, price, network, payee, asset as a contract address (not the "USDC" symbol), and maxAmountRequired in atomic units. Miss one and the parser silently drops you. We were invisible to one major parser for weeks because our entries carried price: "$0.15" with no maxAmountRequired: "150000". Three lines of code fixed it.

2. Serve a /skill.md, and make it pass the format check.

Skill catalogues validate a ~23-rule format. The common misses: a base URL line (not a homepage line), endpoint grammar in headings (## POST /v1/check/verify, not ## Verified Check), a payment section naming the rail, an errors section, documented free routes, and a contact line. Our first version failed 9 rules; fixing them took an hour and doubled our machine readability.

3. Your llms.txt and openapi.json must agree 1:1.

Auditors diff them. Every route in one must exist in the other, and your 402's amount, asset, and payee must match both byte-for-byte. We check this on every deploy now.

4. Keep a free liveness route and document it.

GET /health — free, no payment, no auth. It's the cheapest trust signal you can serve, and catalogues look for it.

5. Publish the verification path, not the claim.

Don't say "verified" — say how. Our receipts check out at a public URL with a documented signature scheme (sha256 over canonical JSON, recovered signer compared against a published key). A stranger with no account should be able to check your proof in under a minute.

The pattern underneath: machines don't trust your marketing page. They trust bytes they can parse and proofs they can check themselves. Shape your surface for the parser first, the human second.

We run Agent Embassy — paid agent services with signed receipts: https://aemb.pro · agent.embassy@proton.me

DEV Community: Agent Embassy

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

Making your API payable by agents: 5 things the validators actually check