Overview
These examples show the workflow syntax as a production-shaped contract: define allowed capabilities/actions, start a durable run, attach each step to a run_id, and inspect the resulting graph.
The app or agent framework still chooses the next step. Synapsor stores the trusted state: session requirements, allowed tools, evidence/proposal links, branch names, guardrail events, external action intents, and replayable outputs.
Support refund agent: customer asks for refund -> agent searches policy -> agent checks invoice -> agent decides refund -> agent calls Stripe -> agent updates ticket -> agent writes memory. With Synapsor, the workflow records evidence, stages refund proposals on a native branch or Synapsor review branch depending on target, holds medium/high risk for approval, and queues external actions idempotently.
E-commerce order assistant: frameworks can keep product chat and routing, while Synapsor checks tenant/customer/cart session fields, restricts order-change capabilities, stages cancellation/refund proposals, and sends confirmation email once through an external-action outbox.
Analytics metric agent: instead of exposing raw run_sql, Synapsor can require official metric definitions, evidence type metric_definition, tenant binding, and approved read-only metric capabilities before answering revenue questions.
RAG / policy assistant: the framework decides when to retrieve, while Synapsor ensures chunks are tenant-allowed, current-version evidence is recorded, citation coverage is enforced, and future replay can show exactly which policy chunk version supported the answer.
GitHub PR / coding agent: the coding framework can analyze files and propose changes, while Synapsor keeps issue evidence, proposed diff, test plan, approval-before-PR rules, and GitHub external-action records in the run graph.
Voice / call-center agent: realtime voice systems can handle conversation speed, while Synapsor records durable call evidence, summaries, CRM proposals, approved side effects, and replay/debug history.
This fits an existing LangGraph, OpenAI Agents SDK, CrewAI, MCP, or custom loop: let that layer decide whether the next hop is triage, refund, approval, or response, while Synapsor enforces the database rules around capabilities, evidence, external actions, and native branches or external review branches for risky writes.
The practical effect is a smaller app surface: expose a few reviewed Synapsor capabilities instead of many low-level tools, bind tenant/principal/customer ids from trusted session context, queue side effects through an outbox, and reconstruct the run later from database state rather than prompt history.
Use the workflow as the governed database boundary around framework routing. Your app can still call triage, refund, approval, and response steps in whatever order the framework chooses, but Synapsor rejects steps that violate the declared session, capability, evidence, branch, external-action, or settlement rules.
Use workflow examples when the same user request crosses more than one capability call, human handoff, native branch proposal, external review-branch proposal, or external side effect. For a single read-only answer, an agent capability may be enough.
The strings like support.ticket_triage_flow, step_answer_ticket, and settle-run-TCK-1001 are developer-defined names or idempotency keys. Values like run_id, evidence ids, proposal lookup ids, branch names, and action_instance_id are returned by Synapsor and should be stored by your app.
Support refund agent
What people build today: a support/refund agent routes a customer ticket through policy lookup, invoice lookup, refund decision, provider call, ticket update, customer email, memory update, and audit logging.
Where app glue gets messy: prompt text says cite policy, an MCP tool can issue the refund, app code checks the amount, worker code retries the provider call, another table stores audit, another function updates memory, and another route asks a manager for approval.
With Synapsor, the workflow contract requires trusted tenant, principal, ticket, and customer session values; allows only reviewed support/billing capabilities; requires evidence; stages risky refund writes on a native branch or Synapsor review branch depending on target; and holds medium/high risk for approval.
customer asks for refund
-> start support.ticket_refund_flow
-> answer_ticket_with_evidence
-> policy and invoice evidence
-> propose_refund on auto branch
-> approve or settle
-> queue Stripe/Zendesk/Resend action
-> EXPLAIN AGENT RUN for replayE-commerce order assistant
What people build today: product search, order lookup, order creation, cancellation, refunds, recommendations, confirmation email, and customer memory are often separate low-level tools.
The database may not know whether the customer could access that order, whether a cancellation needed approval, whether a recommendation used approved inventory, or whether the confirmation email was sent twice.
With Synapsor, the order workflow binds tenant/customer/cart session fields, allows only reviewed commerce capabilities, stages cancellation/refund proposals, and queues provider calls through idempotent external actions.
customer asks to cancel order
-> start commerce.order_assistant_flow
-> check_order_status
-> propose_order_change
-> native branch or Synapsor review branch proposal
-> approval if sensitive
-> queue shopify/sendgrid external action once
-> replay order decision laterAnalytics metric agent
What people build today: a model gets schema lookup and run_sql tools, then tries to answer business questions such as revenue, churn, or active users.
That is useful, but risky: the model may invent joins, misunderstand the official metric definition, ignore tenant policy, or expose data it should not.
With Synapsor, the workflow can deny raw SQL, require an official metric definition, bind tenant/region from trusted session, and return the metric answer with definition and query-plan evidence.
user asks for net revenue
-> start analytics.metric_answer_flow
-> approved metric definition required
-> tenant/region bound from session
-> approved read-only metric capability
-> evidence: definition + query plan
-> fail closed if metric is unknownRAG / policy assistant
What people build today: retrieval, chunk grading, answer generation, and maybe citation rendering live in the app or framework.
That does not guarantee the retrieved chunks were allowed for this tenant, from the current policy version, retained for replay, and attached as durable evidence.
With Synapsor, the workflow requires policy evidence, enforces tenant/domain filters before ranking, records chunk ids and versions, and lets future replay show exactly what policy text supported the answer.
user asks policy question
-> start policy.answer_policy_flow
-> policy.answer_question capability
-> hidden tenant/domain filter
-> current policy chunk evidence
-> compact evidence lookup id to model/app
-> replay uses stored chunk versionsGitHub PR / coding agent
What people build today: read_file, write_file, search_repo, create_branch, open_pull_request, comment_on_issue, and run_tests tools are exposed directly to a coding agent.
The risk is not that coding agents are useless; the risk is unclear repo scope, unclear evidence, PRs opened before review, missed test evidence, or a failed run with scattered provider state.
With Synapsor, the workflow records issue evidence, scopes repo/issue from trusted session, stages proposed diffs, requires maintainer approval before opening a PR, and records GitHub side effects in the run graph.
developer asks to fix issue
-> start dev.pr_review_flow
-> analyze_issue evidence
-> propose_code_change branch proposal
-> propose_test_plan
-> maintainer approval
-> queue GitHub PR external action
-> inspect issue -> evidence -> diff -> tests -> PRVoice / call-center agent
What people build today: realtime voice agents identify a customer, answer account questions, schedule follow-up, update CRM, send summaries, and escalate to humans.
Realtime frameworks optimize for conversation speed. The missing piece is often durable business audit: what customer data was used, what was promised, which CRM change was proposed, and how to replay the outcome.
With Synapsor, the voice workflow records call steps, account evidence, summaries, CRM proposals, follow-up actions, approval requirements, and replay/debug state while the voice framework handles the live conversation.
customer calls support
-> start voice.customer_call_flow
-> voice framework handles realtime conversation
-> Synapsor records account evidence
-> summarize_call step
-> CRM/follow-up proposal
-> approval if needed
-> external action confirmation
-> inspect the run graph laterWorkflow run graph example
Each step becomes durable run state that can be explained, audited, and replayed.
Returns run_id and records the input handle for the request.
Links capability_run_id, evidence_bundle_id, and optional proposal_id to a step_key.
Stores deterministic reason codes and risk decisions outside prompt text.
Queues an idempotent side-effect intent for a worker to claim and confirm.
Returns ordered steps and edges for debugging, audit, and support review.
Proposal workflow with auto branch
Proposal-capable workflow runs can create Synapsor-native branches or external review branches while production-visible state remains unchanged until settlement, approval, or trusted writeback.
AUTO BRANCH ON PROPOSAL tells Synapsor to stage proposal writes on a native branch or external review branch by target.
PROPOSE AGENT CAPABILITY returns a wrp://... handle and branch metadata.
SETTLE AGENT RUN applies a deterministic workflow policy to approve, commit, merge, hold, or reject.
Developer notes
- Create capabilities and settlement policies before starting workflow runs that reference them.
- Use stable step_key values from your app or framework so retries and traces are readable.
- Use run.checkpoint(...) or POST /v1/agent/runs/checkpoints when a framework checkpoint must become durable Synapsor state.
- Do not let the model invent run_id, proposal lookup ids, branch names, or action_instance_id values; read them from Synapsor responses.
- Use idempotency keys for settlement and external actions so retrying a network failure does not duplicate effects.
- Use EXPLAIN AGENT RUN and system views before exposing a workflow to beta users.