What the agent reports
“Customer created.”
Tool call succeeded
Reliability checks for autonomous agents
Your agent said it worked. Did it?
An agent can report success as soon as the tool call returns, without checking whether the row, issue, or ticket is really there. AgentUptime proposes going back to check.
You describe once what an action should leave behind. After that, every agent running that action gets the same check, and every check ends in one of three answers: verified, failed, or unknown.
This is a concept page. There is no SDK, verifier, or hosted reliability service. The research form below records only the answers shown—no contact details or analytics.
The gap
A tool call that returns 200 is not proof that anything happened.
Retries, rolled-back transactions, partial writes, dropped queue messages, and invented record IDs all look identical in an agent transcript. They look like success.
What nobody checked
Does customer_42 exist?
Unknown
Tool call succeeded≠Result exists
How it would work
Write the check once. Every agent reuses it.
A check belongs to the action, not to the agent. If three agents all open GitHub issues, they share one check, and you maintain one check.
Agents
- Support triage
- Backlog groomer
- On-call responder
Shared action
github.issue.create
One check
Read the issue back from GitHub
verifiedfailedunknown
-
01
Install it in the runtime
One install where your agents already run. Nothing changes about how they call tools.
-
02
Say what should exist afterwards
For each action worth checking: the issue exists, the row has these values, the receiving agent got the task.
-
03
Let it read the real system
After the agent acts, the check queries the source of truth directly, not the agent's own report.
-
04
Keep the answer
Verified, failed, or unknown, recorded against the action so you can see which agents drift.
The same pattern covers a database write, a payment, or a handoff between two agents.
Three examples
What a check actually catches.
Illustrations of the idea. These are not built integrations.
The claim“I opened issue #183.”
The checkDoes issue #183 exist, with that title?
CatchesAn issue number invented after a failed retry.
The claim“Customer saved.”
The checkDoes the row exist, with the expected values?
CatchesA write that rolled back inside the transaction.
The claim“Sent to the review agent.”
The checkDid the review agent receive that same task?
CatchesA task dropped in the gap between two agents.
Where it would run
Your credentials never leave your environment.
The check runs inside your runtime, using the access your agent already has. AgentUptime would never need your GitHub token, your database password, or your SaaS keys.
Only the outcome travels: which action ran, what was expected, and what the check found. That's enough for history, alerts, and spotting an agent that's started reporting work it isn't doing.
Conceptual. Neither the local check nor the hosted view exists today.
Your environment
- Agent runs an action
- Tool or API responds
- Check reads the real system
- verified · failed · unknown
outcome only, no credentials↓
Hosted view
History, alerts, policies, and a reliability record per agent.
The detail, for engineers
Every check leaves a receipt.
A receipt is the short record of one checked action: what the agent claimed, what should have been true afterwards, how that was tested, and what came back.
- ClaimWhat the agent reported
- ExpectedWhat should exist as a result
- CheckHow it was tested, independently
- Statusverified, failed, or unknown
Illustrative format
{
"action": "database.customer.create",
"claim": "completed",
"expected": "customer_42 exists",
"check": "independent_read",
"status": "unknown"
}Sketch for discussion, not a shipped format.
Concept research
What does your agent do that you wish you could verify?
Written for teams running multi-step or autonomous agents that change something outside themselves, or hand work to another agent.
This form records your answers. It does not ask for your name, email, company, or IP address. A random browser key helps avoid duplicate responses, but it does not prove that each response is a unique team.