Execution Authority · Compared: Agent orchestration frameworks

Decionis vs agent orchestration frameworks

LangGraph, Temporal and the OpenAI Agents SDK run the agent: the graph, the durable workflow, the tool loop, and the pause where a human approves a step. Decionis decides whether the consequential action inside that loop may execute — allow, hold for a named person, or block — from outside the framework, and signs the record. Most agent deployments need both; the framework's pause is where the gate's verdict lands.

Run a live decision All comparisons

The short version

Different questions, different tools

Choose Decionis when…

the step you are pausing for has consequences the framework does not understand: a payment, a refund, a credit decision, a deploy, a tool call with an amount in it. You need the judgement made on the action's own facts against your own policy, from outside the process that proposed it; a person bound to that exact action when the rules require one; a grant that executes once; and a signed record a bank, a customer or an auditor can verify afterwards without access to your workers.

Choose agent orchestration frameworks when…

you are building the agent itself: the control flow between model calls and tools, state that survives a crash, retries and timeouts, streaming, parallel branches, and the interrupt-and-resume mechanics of a human-in-the-loop step. Orchestration frameworks are built for exactly that, and a decision gate is the wrong tool for making an agent's loop durable or its graph debuggable.

Running both

The framework owns the pause; Decionis owns the answer. Before the tool that moves money runs, the graph node, activity or tool wrapper calls the gate with the captured intent. ALLOW resumes the run with a single-use grant; ESCALATE parks the run exactly where the framework already knows how to park it — an interrupt, a signal, a pending approval — until a named person approves this action; BLOCK ends it with a reason. The framework's checkpoint and the gate's dossier then describe the same event from two sides: what the agent was doing, and what it was allowed to do.

What the category is shipping

What this box is shipping for agents — and what it hands to Decionis

LangGraph (LangChain)

LangGraph's interrupts pause a graph at any node — an approval node can call interrupt() with the question to ask — and the run resumes when the application re-invokes the graph with a Command carrying the answer; the documentation describes the mechanism as dynamic and application-defined. The pause is the framework's; who may approve, whether the action needs approval at all, and the signed record of the outcome are not part of it.

Checked 2026-09-14 · LangGraph — Interrupts (retrieved 14 Sep 2026)

Temporal

Temporal presents durable execution as the runtime AI applications and agents are built on: workflows that survive crashes and restarts, with retries and timeouts handled by the platform rather than rebuilt by every team. A durable pause-until-approved step is exactly what it makes reliable; the judgement about the step, and a signed record of it, are outside what the page describes.

Checked 2026-09-14 · Temporal — AI applications and agents (retrieved 14 Sep 2026)

OpenAI Agents SDK

The OpenAI Agents SDK's human-in-the-loop flow lets a tool declare that it needs approval; run results surface pending approvals as interruptions, and a serialisable run state lets the application pause and resume after decisions are made, including for nested agent-as-tool calls. That is the pause-and-resume mechanics inside the SDK; the policy that decides, the named approver and the externally verifiable record are the application's to supply.

Checked 2026-09-14 · OpenAI Agents SDK — Human-in-the-loop (retrieved 14 Sep 2026)

Each of these is an input to the authority decision, not a substitute for it — see “Running both” above.

Side by side

Where the two differ

Dimension	Decionis	Agent orchestration frameworks
What it decides	Whether this specific action may execute, under this policy, and under whose approval.	What the agent does next: which node, tool or activity runs, and how the run resumes after a pause.
Where it lives	Outside the agent's process, in front of the commit, with the credential held by the executor rather than the agent.	Inside the application: the graph, the workflow worker, the SDK runtime the agent runs in.
The human step	A named approver, bound to the exact action, with the evidence attached; the approval is re-evaluated by policy, never taken as the verdict.	A pause-and-resume primitive — an interrupt, a signal, a pending approval — surfaced to whoever the application chooses.
What the rules read	The action's amount, target, counterparty, environment and collected approvals, against versioned policy.	Whatever the node's code checks; the framework carries state and control flow, not the policy.
Bypass	The gate sits on the action, so an agent that reaches the tool another way still meets it.	A tool called outside the graph or the workflow is not paused by it.
Evidence afterwards	A signed Decision Dossier per action, verifiable outside the stack: verdict, inputs, approver, and what then executed.	Checkpoints, run histories and traces — excellent for debugging the run, not a signed statement of what was permitted.
Failure between decision and execution	A lost response leaves the attempt open until it is reconciled; nothing is retried on its own.	Retries are the framework's strength; whether a retried side effect was authorised twice is a question it does not ask.

Asked directly

The questions this choice comes down to

LangGraph already pauses for human approval. Why add a gate?

Keep the pause; it is the right primitive. What the framework cannot say is whether this action needs a person at all, whose approval counts, or what the record should show afterwards. The gate answers those from your policy: most actions are allowed without a pause, the ones inside a threshold are held for the person the policy names, and the interrupt resumes only with a grant bound to the exact action that was approved. The approval itself is evidence the policy re-evaluates, not a bypass around it.

Human-in-the-loop for MCP agents

Our workflows are durable in Temporal. Isn't the workflow history enough?

For reconstructing the run, yes: a workflow history is superb evidence of what the code did. It is not a signed statement that a specific action was permitted under a specific policy version by a specific person, and it lives inside the platform that executed the action. The dossier is that statement, verifiable by someone with no access to your workers — and durable execution is exactly what makes the pause-until-approved step reliable.

What the dossier records

How do permission limits and human approval fit into an agent loop?

Capture the intent where the tool would be called — the node, the activity, the tool wrapper — and ask the gate before the call. The verdict carries the permission limit the way policy wrote it: inside the band, ALLOW with a single-use grant; over it, ESCALATE to a named approver; never, BLOCK. The framework's own pause mechanics carry the wait. The agent never holds the credential; the executor that claims the grant does, so tool execution stays behind the boundary whatever the loop proposes.

Where it plugs into your agent stack

Is the OpenAI Agents SDK's tool approval the same thing?

It is the same shape of pause — a tool declares that it needs approval, the run surfaces the pending approval, and the run resumes after a decision — inside the SDK's runtime. Decionis decides what that decision should be, from outside the runtime, records who made it, and executes once against a grant. Use the SDK's approval flow to park the run; use the gate to answer it.

The category, in full

See a governed decision before you change anything

Run a scenario in the sandbox and download the signed Decision Dossier it produces, or install shadow mode and watch what would have been held on your own traffic.

Start in shadow mode

Loading…