Hosted workflow

Rails Postgres plus Synapsor

Keep ActiveRecord for Rails while Synapsor governs model-facing agent capabilities and proposals.

Problem

Rails apps can already update records, but agent-facing writes need evidence, branch staging, approval, and replay.

Why app glue gets messy

A raw ActiveRecord tool gives the model too much authority unless a separate safety layer is built.

How Synapsor helps

Synapsor provides the review and writeback boundary while Rails keeps normal app behavior.

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

Agents call reviewed Synapsor capabilities; approved proposals can be applied by Rails jobs.

Production checks

ActiveRecord remains the normal app write path.
Synapsor is the model-facing trust workflow.
Approved writeback should run in a Rails job with idempotency.
Source doctor should run after migrations touching imported tables.

schema.sql

create_table :tickets, id: :string do |t|
  t.string :tenant_id, null: false
  t.string :customer_id, null: false
  t.string :status, null: false
  t.text :resolution_note
end

agent.ddl.sql

CREATE AGENT WORKFLOW support.rails_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

run = db.agent_runs.start(workflow="support.rails_ticket_flow", input={"ticket_id": "T001"})