Tycho Enterprise
Your agent refunded a customer.
Prove it refunded the right one.
An HTTP 200 means the request was accepted. It doesn't mean the right customer got the right amount under the right policy, or that it settled.
Agent: ✅ Refund issued for order #4471. 🔍 Tycho: FAILED ✗ correct_value claimed $49.00 Stripe re_1P2a: $94.00 refunded ✗ correct_object credited cus_PARENT, order belongs to cus_SUB ✓ existence refund exists in Stripe receipt 0x9f3a…c1 · hash-chained, immutable
The API said success. The wrong customer got double. Every verdict writes an immutable receipt.
The evidence
We interviewed 15 teams running agents in production.
9 teams
said verification is what's blocking them from giving agents more autonomy.
6 teams
had delayed or pulled back a deployment because they couldn't prove what the agent changed.
11 teams
had an incident where the agent's claim overstated what actually happened.
10 teams
had an API return success while the business outcome was wrong.
"An HTTP 200 tells me the integration worked. It does not tell me we refunded the right person."
Support operations lead · paraphrased from an interview
The six semantic checks
Read the system of record. Render a verdict.
Existence
Tool timed out; the agent claimed success; nothing actually happened.
Correct object
Credit applied to the parent account, not the subsidiary.
Correct value
Wrong amount, wrong currency.
Terminal state
Async job accepted, then failed after the 200.
No duplicate
A timeout retry issued a second refund.
Intent match
Refund taken from the order total, not the eligible line item.
How it works
We never observe the agent. We read reality.
-
Intent
What a human authorized.
-
Agent acts
Tycho never observes this.
-
Reality
We read your Stripe, Salesforce, or database on separate credentials, never the agent's tools.
-
Verdict
VERIFIED · FAILED · INDETERMINATE, plus an immutable receipt.
- Claimed
- refund $49.00 · order #4471
- Checked
- correct_value · correct_object · existence
- Observed
- Stripe re_1P2a · $94.00 → cus_PARENT
- Verdict
- amount + payee mismatch
The economics
You don't need another dashboard. You need to stop reviewing every action your agent takes, and look only at the ones that fail.
Today a human checks every refund, credit, and cancellation an agent touches. Tycho clears the ones that hold up and writes each a receipt, so review goes to the exceptions instead of the queue.
Deployment & security
Runs where your data already lives.
Stays in your network
Your credentials and system-of-record reads stay in your network. The connector call, the raw responses, the six checks, and the verdict all run on your side. Not air-gapped: the extraction payload and the verdict do leave.
Read-only by construction
Tycho cannot write to your systems. Ever. There are no write methods.
Scoped, revocable credentials
You provision them and can kill them without calling us.
Immutable receipts
Hash-chained: claimed → checked → observed → verdict.
Your access controls decide whether an agent is allowed to act. Nobody checks whether the action was right.
See Tycho against your own systems.
Bring one workflow your agents run in production. We will show you the verdict, and the receipt, against your real Stripe, Salesforce, or database.