Your workflow said it worked. Did the database actually change?

AgentSkeptic answers with read-only SQL at verification time—not with trace success flags or chat narratives.

Teams ship agent and automation workflows where traces, tool responses, and success flags look green while the database row is missing, stale, or wrong. AgentSkeptic closes that gap by comparing structured tool activity to read-only SQL against your SQLite or Postgres at verification time: it tells you whether observed state matched expectations derived from what the workflow claimed—not whether a step narrative sounded successful. It is a snapshot check, not proof of causality or execution.

Pasteable terminal proof (bundled demo)

### Success (`wf_complete`)

workflow_id: wf_complete
workflow_status: complete
trust: TRUSTED: Every step matched the database under the configured verification rules.
steps:
  - seq=0 tool=crm.upsert_contact result=Matched the database.

{
  "schemaVersion": 15,
  "workflowId": "wf_complete",
  "status": "complete",
  "steps": [{ "seq": 0, "toolId": "crm.upsert_contact", "status": "verified" }]
}

### Failure (`wf_missing`)

workflow_id: wf_missing
workflow_status: inconsistent
steps:
  - seq=0 tool=crm.upsert_contact result=Expected row is missing from the database (the log implies a write that is not present).
    reference_code: ROW_ABSENT

{
  "schemaVersion": 15,
  "workflowId": "wf_missing",
  "status": "inconsistent",
  "steps": [
    {
      "seq": 0,
      "toolId": "crm.upsert_contact",
      "status": "missing",
      "reasons": [{ "code": "ROW_ABSENT" }]
    }
  ]
}

The moment it bites

Your run finished with a green trace or a tool response that looks like success, but the ticket is still open in Postgres, the CRM row never landed, or CI passed while production would fail. That embarrassment is the forcing function: you need read-only SQL against authoritative tables—not another narrative.

What AgentSkeptic adds

You emit structured tool activity (for example NDJSON lines with tool IDs and parameters). The engine derives expected rows or fields under your registry rules and runs read-only `SELECT`s. You get verified, missing, or inconsistent with reason codes such as ROW_ABSENT—still at verification time, not as proof that a specific API call wrote the row.

Shareable failure pattern

The bundled demo contrasts `wf_complete` (row matches) with `wf_missing` (trace-shaped success story, row absent). That contrast is the product in one glance: success flags lie; observed SQL does not.

What to do next

Run the homepage demo, follow /integrate for first-run on your database, or install the CLI from the repository README. When you need licensed npm features, use the commercial package and API keys described on the site.

To turn a verification run into a pasteable URL, use the CLI flag documented in docs/shareable-verification-reports.md and read the LangGraph-oriented guide at /guides/verify-langgraph-workflows.