Public demo
Loading the agent timeline, policy checks, and approval workflow.
No Synapsor Cloud account, API key, billing, or browser login. The local runner starts disposable Postgres and MySQL fixtures, exposes semantic MCP tools, creates evidence-backed proposals, and proves guarded writeback, idempotency, stale-row conflict, and replay.
The Docker-only demo command owns the setup. It builds the local runner image, creates the disposable databases, seeds fixtures, runs the MCP smoke path, exports replay artifacts, and tears down the local resources.
# After cloning the Synapsor Runner repository:
./scripts/demo-docker.sh
# Optional contributor path if Node/Corepack is already installed:
corepack pnpm demo:localThe MCP client sees semantic tools such as billing.propose_late_fee_waiver, not a generic SQL escape hatch.
Tenant, principal, and object scope are bound by the runner config and request context, not invented by the model.
The request produces evidence rows plus an exact before/after change set. Nothing has touched the source database yet.
Approval is a separate local CLI action. The model cannot approve or commit its own proposal.
The trusted runner applies a single-row parameterized update with tenant, primary-key, allowed-column, version, and idempotency checks.
The demo exports the run, evidence, proposal, approval, writeback receipt, idempotent retry, and stale-row conflict receipt.
The demo asks for a late-fee waiver. Synapsor Runner records the evidence, target row, expected row version, and proposed patch. The source database still says the original invoice is overdue until a separate approval and runner execution happen.
Invoice INV-1021
Tenant: acme
late_fee_cents
- 5500
+ 0
status
- overdue
+ waiver_pending_reviewThe runner builds the SQL from a reviewed writeback mapping. It checks tenant, primary key, allowed columns, expected version, idempotency, and affected row count before returning an applied, conflict, failed, or canceled receipt.
UPDATE invoices
SET late_fee_cents = $1,
status = $2,
updated_at = NOW()
WHERE id = $3
AND tenant_id = $4
AND updated_at = $5; -- conflict guard from the proposal snapshotThe local demo is designed for the first 10 minutes of evaluation. It does not require hosted Synapsor, and it does not upload your database URLs, passwords, prompts, table data, or write credentials.
When teams need shared approvals, RBAC, hosted replay search, or runner fleet status, the same runner can register with Synapsor Cloud using a scoped runner token.
Seeded invoices, customers, support evidence, and policy rows for the main demo path.
Seeded order workflow fixture to prove the same runner shape works outside Postgres.
Local stdio server exposing semantic database tools from runner config.
SQLite proposal/evidence/replay store inside the demo workspace.
Applies approved jobs only after approval and guard validation.
The script removes disposable containers, volumes, and temp files after the run.
1. Docker starts disposable Postgres and MySQL fixtures.
2. The MCP server exposes semantic tools, not execute_sql.
3. The agent request creates a Synapsor proposal with evidence and an exact diff.
4. The source database remains unchanged before approval.
5. Approval creates a guarded writeback job for the trusted runner.
6. The runner applies a parameterized UPDATE with tenant, primary-key, allowed-column, version, and idempotency checks.
7. A retry returns the same idempotent receipt.
8. A stale proposal returns conflict and applies no write.
9. Replay exports the evidence, proposal, approval, writeback receipt, and conflict receipt.