The agent calls approved actions, not a database shell.
Public demoGet access
Public demo
Preparing safe database demo...
Loading the agent timeline, policy checks, and approval workflow.
Public demo
Loading the agent timeline, policy checks, and approval workflow.
The source database stays unchanged. Synapsor reads approved rows, records evidence, and turns risky changes into reviewable proposals instead of giving the model raw SQL or direct write access.
The agent calls approved actions, not a database shell.
Synapsor applies server-controlled scope before evidence is returned.
The public demo stores review state in Synapsor and never mutates the seeded source database.
Writeback model
Synapsor uses a read-only source credential for governed reads. It does not use that credential to update Postgres or MySQL. When a write is approved, your backend worker applies the proposal using your separate write credential.
Synapsor reads approved, tenant-scoped evidence.
Risky writes become reviewable proposals. The source database remains unchanged while review state is pending.
Your backend applies approved proposals with your own write credential.
Pick Postgres or MySQL, run one seeded request, and see the important result: Synapsor reads approved evidence while the source database stays unchanged.
Live run graph
The graph separates the unchanged external source lane from the Synapsor review branch lane so auto-branching is visible without implying Postgres/MySQL itself is branched.
AUTO BRANCH ON PROPOSAL forks Synapsor's change-control record, not your external database.
Postgres stays the source of truth and remains unchanged during review.
Synapsor owns the review branch/proposal record: diff, evidence, approval state, replay, and worker handoff.
Policy-approved proposals become worker-ready; review-gated proposals stay staged until approved.
What branches is Synapsor's review record: proposed row diff, evidence, approval state, writeback intent, and replay. External Postgres/MySQL tables are not physically branched or merged.
Loading safe-write run graph...
The static path below mirrors the interactive graph while the canvas initializes.
Pick a seeded Postgres or MySQL mission. The agent will use Synapsor-approved reads instead of raw database access.
Investigate a revenue issue and prepare a reviewable proposal while Postgres stays unchanged.
SelectedInvestigate refund complaints and prepare a review path while MySQL stays unchanged.
Writeback model
Synapsor uses a read-only source credential for governed reads. It does not use that credential to update Postgres or MySQL. When a write is approved, your backend worker applies the proposal using your separate write credential.
Synapsor reads approved, tenant-scoped evidence.
Risky writes become reviewable proposals. The source database remains unchanged while review state is pending.
Your backend applies approved proposals with your own write credential.
Developers keep their existing Postgres/MySQL app database. Synapsor stores the safe agent contract, reads through imported mappings, and returns evidence/proposals to the app.
Your backend or CLI creates a Postgres/MySQL source in Synapsor. Connection details are stored server-side; the browser and model never receive them.
Synapsor inspects tables/views, primary keys, tenant columns, and fields suggested for review. You decide which fields agents can see before importing mappings.
Synapsor creates external mappings, an agent context, approved tools, and a workflow. SESSION values such as tenant_id and current_invoice_id come from your app.
The agent invokes a capability. Synapsor runs bounded live reads against the source using allowed mappings, tenant scope, row limits, and query audit.
For changes, Synapsor records a proposal and diff first. Your backend worker applies approved writeback later with a separate write credential, allowlisted columns, and bound parameters.
The guided demo is the UI flow above. The implementation details below are intentionally collapsed so a new developer first sees the integration path: existing DB, safe mappings, approved tool, evidence, proposal, writeback worker, and replay.
Postgres/MySQL remains the source of truth. Synapsor uses a least-privilege source registration instead of moving the whole database.
You select tables/views, allowed columns, tenant keys, primary keys, row limits, denied fields, and query timeouts.
The agent calls a named capability. It does not receive a database password, arbitrary SQL access, or control over tenant_id.
Every run records source rows, redactions, policy chunks, query fingerprints, row counts, and trusted session scope.
Risky changes are staged as reviewable proposals. Your backend worker applies approved writeback later with a separate write credential.
The run can be inspected later from stored evidence, query audit, review-branch/proposal state, and writeback status.
This mirrors the signed-in setup flow: developers choose the source tables and business workflow in UI, then Synapsor generates context, capabilities, workflow, evidence rules, and proposal boundaries behind the scenes.
revenue.billing_context, revenue.get_customer_billing_context, revenue.propose_collection_followup, revenue.late_invoice_followup_flow
No database password, no arbitrary SQL tool, and no authority to choose hidden session values such as tenant or current object id.
These snippets are for developers who want to inspect the exact demo implementation. The normal onboarding path should use the guided setup UI first, then copy or edit generated artifacts when needed.
-- Synapsor safety contract for an agent reading existing Postgres/MySQL mappings.
-- SESSION values are bound by your backend; the model cannot choose tenant_id or principal.
CREATE AGENT CONTEXT revenue.billing_context
ROOT EXTERNAL external_revenue.invoices AS invoice
LOOKUP invoice.id = SESSION current_invoice_id
BIND tenant_id FROM SESSION tenant_id
BIND principal FROM SESSION principal
JOIN EXTERNAL external_revenue.customers AS customer
ON customer.id = invoice.customer_id
AND customer.tenant_id = SESSION tenant_id
JOIN EXTERNAL external_revenue.contracts AS contract
ON contract.customer_id = customer.id
AND contract.tenant_id = SESSION tenant_id
SEARCH EXTERNAL external_revenue.policy_chunks AS policy_hits
USING TEXT(policy_hits.body)
QUERY ARG question
FILTER policy_hits.tenant_id = SESSION tenant_id
TOP 5
OUTPUT SLOTS
invoice_id AS invoice.id,
customer_name AS customer.name,
balance_cents AS invoice.balance_cents,
days_late AS invoice.days_late,
renewal_date AS contract.renewal_date,
policy_hits AS policy_hits
EVIDENCE ON;
CREATE AGENT CAPABILITY revenue.propose_collection_followup
ARG reason TEXT REQUIRED
HIDDEN tenant_id FROM SESSION tenant_id
HIDDEN principal FROM SESSION principal
HIDDEN current_invoice_id FROM SESSION current_invoice_id
USE CONTEXT revenue.billing_context
EXECUTION PROPOSAL
REQUIRES EVIDENCE
WRITE PROPOSAL TARGET EXTERNAL external_revenue.renewal_risks
OPERATION UPDATE
LOOKUP invoice_id FROM SESSION current_invoice_id
TENANT tenant_id FROM BINDING tenant_id
COLUMNS
status FROM VALUE 'pending_review',
recommended_action FROM ARG reason
AUDIT revenue.writeback_audit;
CREATE AGENT WORKFLOW revenue.late_invoice_followup_flow
SESSION REQUIRE tenant_id, principal, current_invoice_id
ALLOWED CAPABILITIES (
revenue.get_customer_billing_context,
revenue.get_open_support_tickets,
revenue.check_contract_terms,
revenue.propose_collection_followup
)
EVIDENCE REQUIRED
AUTO BRANCH ON PROPOSAL -- Synapsor review branch, not a Postgres/MySQL branch
ON RISK low AUTO_APPROVE
ON RISK medium REQUIRE APPROVAL ROLE 'revenue_lead'
CHECKPOINT EVERY STEP;
CREATE SETTLEMENT POLICY revenue.low_risk_followup_policy
FOR WORKFLOW revenue.late_invoice_followup_flow
AUTO APPROVE WHEN PAYLOAD risk = 'low'
ELSE LEAVE PROPOSED;
-- External proposals are approved for trusted writeback.
-- A worker you control applies the parameterized UPDATE later.
-- No external database merge happens here.
-- MySQL lane: read-only workflow. It has no AUTO BRANCH clause because this
-- public example demonstrates scoped reads, evidence, audit, and replay only.
CREATE AGENT CONTEXT ecommerce.order_context
ROOT EXTERNAL external_ecommerce.orders AS orders
LOOKUP orders.id = SESSION current_order_id
BIND tenant_id FROM SESSION tenant_id
BIND principal FROM SESSION principal
JOIN EXTERNAL external_ecommerce.customers AS customer
ON customer.id = orders.customer_id
AND customer.tenant_id = SESSION tenant_id
SEARCH EXTERNAL external_ecommerce.refund_policies AS policy_hits
USING TEXT(policy_hits.body)
QUERY ARG question
FILTER policy_hits.tenant_id = SESSION tenant_id
TOP 5
OUTPUT SLOTS
order_id AS orders.id,
order_status AS orders.status,
total_cents AS orders.total_cents,
customer_name AS customer.name,
policy_hits AS policy_hits
EVIDENCE ON;
CREATE AGENT CAPABILITY ecommerce.answer_order_question
ARG question TEXT REQUIRED
HIDDEN tenant_id FROM SESSION tenant_id
HIDDEN principal FROM SESSION principal
HIDDEN current_order_id FROM SESSION current_order_id
USE CONTEXT ecommerce.order_context
EXECUTION READ ONLY
REQUIRES EVIDENCE
RETURN JSON;
CREATE AGENT WORKFLOW ecommerce.refund_review_flow
SESSION REQUIRE tenant_id, principal, current_order_id
ALLOWED CAPABILITIES (
ecommerce.answer_order_question
)
EVIDENCE REQUIRED
CHECKPOINT EVERY STEP;