Hosted workflow

Prisma Postgres plus Synapsor

Keep Prisma for ordinary app transactions and use Synapsor for agent-facing trust workflows.

Problem

A Prisma app can query and mutate Postgres safely for normal users, but model-facing tools need evidence, tenant binding, proposals, and replay.

Why app glue gets messy

Exposing Prisma methods directly as tools pushes trust, approval, and audit into ad hoc wrappers.

How Synapsor helps

Synapsor sits beside Prisma: Prisma keeps the app path, while Synapsor records approved tool calls and proposal writeback.

Value sources

Example names and seed ids are developer-defined. SESSION values are set by your backend. ARG values come from the SDK/HTTP call. Handles such as wrp://..., evidence://..., and agent-run://... are returned by Synapsor and should be stored for audit/replay.

Read the value-source guide

Expected outcome

The app keeps Prisma migrations and transactions while agent actions become replayable Synapsor workflows.

Production checks

Prisma remains the normal application data layer.
Synapsor capabilities are the model-facing tools.
Writeback happens through trusted server code after approval.
Handles are stored for audit when the app needs them.

schema.sql

model Ticket {
  id             String @id
  tenantId       String
  customerId     String
  subject        String
  status         String
  resolutionNote String?
}

agent.ddl.sql

CREATE AGENT WORKFLOW support.prisma_ticket_flow
SESSION REQUIRE tenant_id, principal, current_ticket_id
ALLOWED CAPABILITIES (
  support.answer_ticket_question,
  support.propose_ticket_resolution
)
EVIDENCE REQUIRED
AUTO BRANCH ON PROPOSAL
CHECKPOINT EVERY STEP;

python

# Python services can call the same Synapsor workflow even if the app DB uses Prisma elsewhere.
run = db.agent_runs.start(workflow="support.prisma_ticket_flow", input={"ticket_id": "T001"})