Examples

Prisma with Synapsor

Keep Prisma for normal app reads/writes. Use Synapsor for agent-facing capabilities, evidence, proposals, and replay.

Overview

Prisma remains your normal application data layer. Synapsor is added only where an agent needs governed access to business data.

The app keeps Prisma migrations, normal transactions, and normal user workflows. Agent-facing paths call Synapsor capabilities instead of exposing Prisma models or raw SQL to the model.

For risky writes, the agent creates a Synapsor proposal. A trusted worker can then apply an approved proposal through Prisma or parameterized SQL in your app environment.

Developer notes

Do not expose Prisma client methods as raw model tools for sensitive data-change paths.
Keep tenant/user scope in SESSION and HIDDEN bindings.
Use Prisma or your existing transaction layer in the trusted writeback worker after approval.
Store Synapsor-produced evidence/proposal/run handles with support tickets or audit records.

App split

prisma-and-synapsor.ts

// Normal app path: Prisma owns ordinary product behavior.
const ticket = await prisma.ticket.findUnique({
  where: { id: ticketId },
});

// Agent-safe path: Synapsor handles tenant binding, evidence, proposal, and replay.
await synapsor.session.set({
  tenant_id: req.user.tenantId,
  principal: req.user.id,
  current_ticket_id: ticketId,
});

const run = await synapsor.agentRuns.start({
  workflow: "support.ticket_resolution_flow",
  input: { ticket_id: ticketId },
});

const result = await run.invokeCapability("support.answer_ticket_question", {
  stepKey: "answer_ticket",
  arguments: { question },
  responseEnvelope: true,
});

Examples

bash

synapsor sources create postgres --name app_postgres --url env:APP_POSTGRES_URL --ssl require --mode live_read
synapsor sources import app_postgres --schema public --tables tickets,customers,policy_chunks --tenant-column tenant_id
synapsor sources generate app_postgres --template support-ticket-agent --namespace support