Live demo
The response is lost. Did the action succeed?
Run a scripted agent action that inserts a credit record into a real demo database. The network drops the response. Conseqa then independently checks what changed, using the intent it recorded before execution. No payment is made and no LLM is called.
Run one scripted action to see whether the database changed, even though the caller received an error.
Scripted action · real demo database · no LLM call or money movement · not saved to a workspacePress Run the demo to write a synthetic credit record to the demo database. The caller loses the response. Conseqa then searches for the record using the key it durably registered before execution.
Usually about ten seconds. The lifecycle, verdict and evidence come from this run. Explanatory labels describe each step.
- Check the demo table
The action writes a synthetic record to one table in a real PostgreSQL database. A separate capacity reservation never creates the provider record or counts as evidence that the action executed.
- Start the private runner
The demo starts an embedded runner with a local SQLite store. Its verifier uses a separately configured connection for SELECT queries; production deployments should enforce a least-privilege read-only role.
- The agent issues a store credit — and the reply is lost
Before the statement is sent, the SDK records what the write is supposed to achieve and issues a correlation key that goes into the row itself. Then the connection dies mid-flight and the agent is left holding an error and no credit id.
- The runner asks the database
Not a retry. The runner searches for the row by the key that was issued before the statement went out — which is what makes a lost write findable by identity rather than by guessing from timestamps and amounts.
- Verdict
Two axes, not one: what the action did, and whether its consequence holds. The evidence is the fields that decided it.
Want to inspect the result after the run? Run it in your workspace to save the real lifecycle and evidence in a separate Live demo environment. Sign-in and workspace setup are required; no provider credentials are needed for this demonstration.
What is actually real here
The SDK, local runner, database write and network interruption execute during your run. The public repository contains a standalone version using published packages.
Each run inserts a synthetic credit record into a shared PostgreSQL demo table. On successful verification, the page reads back and displays that row. It does not issue a payment or contact a real customer.
A TCP proxy forwards the database traffic and drops the next response after the action starts. The caller receives a real connection error. Because the traffic is encrypted, the proxy cannot prove that the write committed; the subsequent database lookup establishes that.
The verifier searches by the pre-registered correlation key and checks the matching row with SELECT queries. It never repeats the INSERT. Configure a least-privilege database role to enforce this boundary in your own deployment; this page does not audit role permissions.
If no matching row is found before the verification deadline, the result is Unknown. Missing evidence does not prove that nothing committed or that retrying is safe. A demo service interruption is shown separately from a contract verdict.
Run it against your own database
The hosted demo uses a shared demonstration database. The standalone version uses your own Neon database and the published SDK, runner and CLI packages, so you can inspect the write and recovery directly.
git clone https://github.com/Devrajsinh-Jhala/conseqa-demo
cd conseqa-demo && npm install
cp .env.example .env # then fill in your Neon connection strings
npm run demoPrerequisites: Node.js 22.13 or later and a Neon database. Set the connection strings in .env before running. This example uses Neon SQL-over-HTTP for verification. Allow time for account and database setup on your first run; the demonstration itself usually takes about ten seconds.
What this does not prove
One lost write against one table. It is the smallest complete version of the problem, not the shape of it in your system.
- Your provider is not a table. A refund lives behind an API with its own read model, its own eventual consistency and its own idea of what a duplicate is. The connectors for Stripe and Razorpay carry that; a database row does not.
- One failure, chosen in advance. The demo drops exactly one reply at a moment it picks. Missing or inaccessible evidence can lead to Unknown (
INCONCLUSIVE), rather than a claim that the action succeeded or failed. - Public runs are not saved to an account. This page uses a temporary runner. The signed-in workspace demo saves its lifecycle and evidence; a persistent customer runner remains a separate production integration step.
- No load, no clock skew, no partial outage. Ten seconds of the happy path through an unhappy network.
If you want to see this against the system you actually run, that is a better use of twenty minutes than anything on this page.