Vocion vs. Temporal

A durable AI agent workflow is an agent procedure whose state survives process restarts, deploys, and multi-day waits, so a run can pause — for a retry, a schedule, or a human decision — and continue later from exactly where it stopped. Temporal is a standard durable-execution engine for this: workflows, schedules, and signals, with state maintained by the platform rather than a hand-written state machine. Temporal advertises exactly this for agents: "Guarantee all executions of all processes run to completion successfully in spite of failures" and "Easily facilitate human-in-the-loop interactions like validating LLM results or approving agent decisions" (https://temporal.io/solutions/ai). Temporal is infrastructure, not an agent platform: it does not define what an agent is, hold a registry of them, or provide a review surface for a person. Vocion is an open-source agent workforce platform that adds those layers on top of a workflow runtime: agents and workflows authored as YAML in git, approval steps, a review queue, and an audit trail.

This page is "Temporal alone vs. Temporal plus an operating layer," not Vocion vs. Temporal as competitors — Temporal is infrastructure Vocion's stack includes, not something it replaces. Rows where building directly on Temporal is the better choice stay in. Last verified 2026-09-08, against @vocion/core v2.37.0.

What durability buys an agent

An agent that calls three tools and waits on one of them for two days should not lose its place if the process restarts in between. Durable execution means the workflow's history — which steps ran, what they returned — is persisted by the engine, so a resume replays from that history rather than starting over or duplicating a side effect like a sent email.

What Temporal provides out of the box

Durable workflow execution with automatic retries, schedules for recurring runs, signals for delivering an external event (like a human decision) into a paused workflow, and a visibility store for querying running and historical workflows. Temporal's own AI positioning page names exactly the human-in-the-loop case: "validating LLM results or approving agent decisions" via a signal into a paused workflow (https://temporal.io/solutions/ai). None of this is agent-specific — Temporal has no concept of an agent, a skill, or a prompt; a workflow is a function, and what runs inside it is up to the caller.

What you still have to build, on Temporal alone

On Temporal alone, the honest list: agent definitions and prompts (as code, versioned however your repo is versioned), a registry of those agents, a review UI a non-engineer can use to approve or reject a paused workflow, per-action approval thresholds tied to confidence, an audit link from a specific output back to the configuration that produced it, connectors to the systems the agent reads and writes, and cost/trace reporting across runs. Temporal's docs do not claim to provide any of these — it is infrastructure for durable execution, by design.

A durable workflow that pauses for a human

In a Vocion workflow.yaml, an approve step pauses the run in the review queue until a person decides, and an ask step pauses until a person supplies a value — unless a default resolves to a non-empty string, in which case the step completes without pausing, so the same workflow serves an automated caller and a person starting it by hand (docs/entities/workflow.md). The worked example in that same doc is a discovery-call-to-follow-up workflow: an ask step for the salesperson's notes, then an approve step gated on the drafted email. Operationally, the paused run sits as a row the reviewer can see in the dashboard or fetch over the API; deciding it resumes the workflow at the next step.

Where the pending item lives while the workflow waits

In the review queue, reachable over HTTP: GET /api/v1/reviews lists pending items (with kind, assignedTo, and pagination), and POST /api/v1/reviews/decide resolves one (README.md). The write API's /api/v1/reviews surface is nine endpoints total — list, propose, rewrite, decide, auto-executed, assign, snooze, signal, and a per-item lookup (packages/core/src/app/api/v1/reviews/) — covering the review record and its triage actions, but none of them is a webhook subscription or a streaming connection: a client polls GET /api/v1/reviews to find out what is waiting. Temporal's own signal mechanism is push in the sense that a signal call wakes the specific paused workflow it targets (https://docs.temporal.io/encyclopedia/workflow-message-passing); the two are not directly comparable, since a Vocion reviewer is choosing from a worklist rather than sending a signal to one workflow they already know the ID of.

A note on the autonomy ladder

Vocion documents five mission autonomy levels — draft only, ask before action, act within rules, manage a goal, improve itself (docs/entities/mission.md) — but requiresApprovalForMutation (packages/core/src/services/authz.ts) has three branches, checked in this order: an explicit approvalRequired flag on the task forces a gate at any autonomy level (the mission planner sets this when a task sends or changes something external, packages/core/src/services/missions/planner.ts); a mutation that is not external is never gated, at any level; only then does level <= 2 require approval, with every level above that not requiring it by default. So for the common case — an external mutation the planner did not already flag — levels 3, 4, and 5 are behaviorally identical; the distinction between "act within rules" and "improve itself" is not enforced by this function, only by whether the planner set approvalRequired on that task. This matters for a durability comparison because the default pause-for-a-human boundary in Vocion today is binary (levels 1-2 vs. 3+) unless a task overrides it, not five distinct enforcement tiers, whereas a Temporal-based system's pause points are whatever the workflow author codes them to be — arbitrarily granular, at the cost of writing that logic yourself.

Temporal's role in running Vocion today

Not for workflow durability today. Vocion's own workflow steps persist to Postgres directly — the self-hosting guide states plainly that "in v1 workflows store state in workflow_run rows. If the process dies mid-run, the run sits paused at its last persisted step," and describes Temporal-backed workflow durability as forthcoming work (docs/guides/self-hosting.md). Temporal is part of the reference deployment stack regardless: it runs scheduled and event-driven automations, including source-sync crons, on a Temporal Schedule and Workflow underneath (docs/object-model.md describes the Automation entity as dispatching "Temporal schedule or event match"). So today, on Postgres-only durability for the workflow steps that hold approve/ask gates, Temporal itself is a better-tested answer to "did the process crash mid-step" than Vocion's own step runner is as of this date — a plain instance of a row where Temporal alone is the stronger primitive.

When to build directly on Temporal

Say it without hedging: one team, one or two workflows, engineers as the only reviewers of paused runs, an existing Temporal cluster already in production, and no need for an agent catalog a non-engineer can browse. Temporal's durability guarantees, retry semantics, and visibility tooling are mature and battle-tested at a scale Vocion has not built or documented equivalents for. Adding an operating layer on top is only worth it once more than one team, or more than engineers, need to see and act on what an agent is doing.

Comparison table

Which to pick

Build directly on Temporal if your team is small, your reviewers are engineers who are comfortable reading workflow history in the Temporal Web UI, and you do not need a catalog of agents that a non-engineer can browse or approve against. Add Vocion's layer on top of durable execution if the people deciding what an agent is allowed to do are not the people writing the workflow code, or if you need to answer "why did this run do that" from an audit row rather than from application logs.

Related

• Actions — trust.yaml and the auto-approve threshold model referenced above.
• Missions — the autonomy levels that decide when a mutation needs approve at all.
• The review queue over HTTP — the full /api/v1/reviews surface.
• Vocion vs. LangGraph — the same operating-layer argument against a control-flow library instead of a durable-execution engine.

Read docs/entities/workflow.md for the full approve/ask step reference, or clone vocion-core and run the discovery-followup example workflow to see a paused run resume on a human decision.