Choreograph

Durable execution. Governed delegation.

Temporal and DBOS make execution durable. The harness builds the agent. Choreograph governs the work.

Authority, approvals, effects, provenance and audit on one typed task. Open source. Postgres-native. Built for human-AI operations.

Temporal

Your workflow can wait. Who can move it forward?

Temporal makes code durable. Choreograph makes delegation governed: who may act, which checks must pass, and what can happen next.

The bag cannot connect at Frankfurt. The AI finds a direct flight, but only in business class. A support lead must approve the exception before the passenger accepts the new journey.

Airline exception workflow: Temporal application controls and a Choreograph task contract coordinate a business-class rebooking, human approval and related work.
Figure 1This flight. This exception. This approver.
Open full diagram

Illustrative airline workflow. The approval rule belongs to this example.

Temporal — build the business controls.

Workflow code, messages and validators carry the process. Your application defines business roles, approvals, scoped tools and dependent work.

Choreograph — declare the business contract.

States, roles, reviews, tools and dependencies live on the task. People and agents act against the same contract.

Authority belongs to the step.

Declare who may act, who must review, which tools the step grants and what each role may read. Give the agent a scoped job, not a blank cheque.

An old approval is not a free pass.

Check changes against the current recorded state, rules and dependencies. If the proposal changes, its approval must still cover the action being taken.

Approve the action. Not a promise.

Bind review to the proposed change and its intended effects. Release the approved booking, payment or refund only after that approval commits.

One business contract. Not a control framework rebuilt for every workflow.

Audit & replay

Replay the execution. Audit the decision.

Who approved it? Under which rules? What actually happened? Follow the decision across tasks, reviews, effects and evidence.

Audit and replay comparison: Temporal reconstructs execution from Event History; Choreograph joins approvals, rule versions, booking receipts and agent proposals in a verifiable business record.
Figure 2The decision, its authority and its consequences. One record to interrogate.
Open full diagram

Temporal — replay the execution.

Event History plus Workflow code reconstructs execution state.

Choreograph — reconstruct the decision.

Join the change to its actor, approval, rule version, effects and evidence. Reconstruct the business state and verify the record.

Query

Query the operation. Not one run at a time.

Ask across tasks, approvals, effects and model turns.

Evidence

Keep inference, confirmation and approval distinct.

What the model inferred, what a system reported and what a person approved remain separate evidence.

Versioned rules

Change the rules. Keep the old decisions explainable.

Each task remains tied to the business rules that governed it.

How much infra do you want to run?

Deployment comparison: a production self-hosted Temporal cluster has frontend, history, matching and worker services with persistence, visibility and optional archival; Temporal Cloud is an alternative. Choreograph’s core runtime connects task state, reviews and evidence through one runner and one PostgreSQL database.

Temporal is the mature distributed platform. Choreograph is lightweight by design: one runner, one PostgreSQL database, open source and self-hostable.

What belongs to the platform?

ConcernTemporalChoreograph
ExecutionDurable Workflow ExecutionDurable typed business state
AuthorityApplication / integration logicDeclared on the task
EvidenceEvent History + searchable metadataJoinable business record
ReplayReconstruct executionReconstruct decision context
EvolutionVersion Workflow codeVersion TaskType declarations

Temporal is the stronger execution engine. Choreograph is the business contract it leaves you to model.

Temporal FAQ

Can’t I build this in Temporal?

Yes. Temporal is the mature choice for distributed durable execution. Choreograph’s proposition is different: keep authority, reviewed actions, dependent work and evidence in one task model instead of rebuilding that contract in every application.

Does Temporal already support audit and replay?

Yes. Choreograph’s distinction is the business record: actor, approval, pinned rules, effects, refusals and model evidence remain joined to the work and independently verifiable.

What about DBOS?

DBOS is the lightweight durability fit: durable workflows inside the app, backed by Postgres. Architecturally, it can sit beneath Choreograph while TaskTypes remain the business-process model.

Does Choreograph replace Temporal?

No. Temporal makes long-running code durable. Choreograph gives the business work a shared model for state, authority and evidence.

LangGraph

Keep the agent. Put authority outside its prompt.

LangGraph already supports code checks and human interrupts. Choreograph puts the business contract on the task, not in each agent’s implementation.

The same invoice, two ways.

Sixteen steps take an invoice from inbox to reconciliation. The question is what those steps are.

Program-first · LangGraph (Guardrail)

The nodes are operations; arrows say “run this next.” Checks and approval routes are wired into the program. In this example, the bank call is node 15: it fires inside the run.

Arrow = instruction
LangGraph invoice workflow: sixteen numbered operations form a branching program. Validation and human approval nodes lead to Execute at node 15, then reconciliation.
Figure 3Steps wired into a program.
Open full diagram

Task-first · Choreograph (Guarantee)

Four typed tasks declare states, actors and guards. An edge says “this actor may make this transition if its guard holds.” The Program is composed at run-time from the dependencies. INTAKE has no direct edge to PAID; that shortcut cannot be committed.

Edge = permission
Choreograph invoice state machines: invoice, vendor, line-item and payment tasks have guarded transitions. A crossed-out INTAKE to PAID shortcut has no edge. Humans own approval edges; bank effects follow commit.
Figure 4Transitions permitted by a declaration.
Open full diagram

An arrow says what happens next. An edge says what may happen. What has no edge cannot happen at all.

Guardrail vs Guarantee

Program-first · LangGraph (Guardrail)

One application trust domainAgent, routing check and bank tool share one application process. The bank call exits from inside the run; code in that process has shared access. Your application process Agent loopreasoning and tools route_after_pricing()the check you wired book_payment()the bank call · node 15 Inside run Bank Shared state and tool access
Figure 5One trust domain.

One process—the reasoning, the check, the bank call. The check is real, but it holds only as long as every path routes through it; the dashed line is the path nobody wired.

And because the tool fires mid-run, a check that fails late fails after the money moved.

Task-first · Choreograph (Guarantee)

A separate enforcement boundaryAny harness proposes a typed action through the Gate, where authority, guards and the chain are enforced. Accepted and refused actions are recorded in PostgreSQL. A separate executor performs effects after commit. The agent has no direct bank path. HarnessLangGraph · Pydantic AI · Claude Code Typed action The Gate Authorization · guards · chain The substrate · one PostgreSQL commit commit refused Acceptances and refusals, hash-linked After commitIdempotent executor Bank
Figure 6The check is beyond the agent’s reach.

The same agent thinks just as freely—but it can only propose. Every proposal crosses the Gate, where authorization, guards and the chain run inside the database transaction. What’s accepted becomes a commit; what’s refused becomes a commit too.

Only then does an idempotent executor touch the bank. Notice what the drawing has no arrow for: there is no path from the harness to the bank. That absence is the architecture.

A guardrail is something your program does. A guarantee is something done to your program.

Same rule. Three ways to control it.

Previous approved price: €100. Automatic booking up to €105. Above that, finance-lead review.

item_price <= 1.05 * previous_approved_price

1. Prompt-only control

System instructions

Do not increase the price by more than 5%. Ask a person to approve larger increases.

Book at €108?

May still proceed

The model is instructed to comply. In this setup, no independent check stops a violating action.

2. Application validation

if proposed_price > approved_baseline * 1.05:
    require_human_review()

Book at €108?

Blocked by app code

A deterministic check stops the €108 proposal. Your team owns the validation path.

3. Choreograph task guard

Automatic-booking transition

item_price <= 1.05 * previous_approved_price

€104

Booked automatically

€108

Automatic path refused

Finance lead reviews exception

Approved exception
→ booked

The rule, the authority, and the recorded outcome live on the task.Refusal / approval recorded.

Figure 7A prompt asks. Code checks. A task carries the contract.

Prompt-only control

The model is asked to obey.

Application validation

Code enforces the check. Your application owns every path that must use it.

Choreograph task guard

The automatic path carries the rule. A failed guard routes to a separate human-authorised path; the refusal stays on record.

The workflow and the human.

LangGraphChoreograph
Where does the workflow live?In an executable graph of nodes and routes.In a typed declaration: versioned, hash-pinned and enforced by the substrate.
What is the human?An interrupt pauses the graph for human input; the program then resumes.An authorised actor at the same Gate, with their own approval edge, lease and record.

The LangGraph column describes the application-level setup shown here. Separate enforcement and audit services can be added; they are not supplied by the graph alone. Bank effects in Choreograph demonstrations are sandbox drafts.

Choose the runtime. Keep the business contract.

Temporal, DBOS and LangGraph solve different parts of the stack. Choreograph keeps the rules of the work in one place.

Temporal

Battle-tested distributed durability.

Use it when scale, polyglot SDKs and enterprise operations matter. Choreograph can remain the task-level authority and evidence model around the work.

DBOS

Durable execution without the orchestration cluster.

Open-source durable workflows run inside the app and checkpoint to Postgres. DBOS is a natural plumbing layer beneath TaskTypes.

LangGraph

Keep the agent graph.

Let LangGraph build the agent. Give its consequential business actions a shared task contract.

One database. One transaction boundary.

DBOS can commit application data and its durability record in Postgres. That makes it a natural durability layer under Choreograph while TaskTypes remain the home of business choreography.

Choreography in TaskTypes. Durability underneath.

Open source. One Postgres. Run it yourself.

Choreograph keeps task state, reviews and evidence in PostgreSQL. Bring your models and business systems. No orchestration cluster is required for the core runtime.

Enterprise when you need it. Lightweight when you don’t.

Open source under Apache‑2.0 when the repository opens.

Pydantic AI is the reference harness. Temporal and DBOS are architectural fits here, not shipped adapters. Payment demos use sandbox drafts.

Stop rebuilding the rules around every agent.

Bring us the approvals, exceptions and audit work your team keeps stitching together. Put the business contract on the task.