Ballet vs Temporal
TL;DR: Temporal is durable execution infrastructure — you write workflows in code (Go, TypeScript, Python) that survive crashes and run for days. Ballet is a full agent operations product with Ask Ballet authoring, playbooks, connectors, and a Studio UI. Choose Temporal when you need a custom orchestration SDK; choose Ballet when you want a ready-made agent ops platform.
What Temporal is
Temporal is an open-source durable execution platform. Developers define Workflows (deterministic orchestration logic) and Activities (side effects like LLM calls or API requests). Temporal persists event history so workflows resume exactly where they left off after failures, deploys, or long waits. In 2026 it positions heavily as the orchestration layer for production AI agents — human-in-the-loop signals, multi-day conversations, and agent sandboxes.
Where Temporal is strong
- Durable execution — workflows survive process crashes and infrastructure restarts.
- Long-running processes — wait hours or days for human approval without losing state.
- Language SDKs — Go, TypeScript, Python, Java, .NET for full code control.
- Production AI agents — official patterns with LangGraph, OpenAI Agents SDK, and more.
- Enterprise scale — multi-region replication, Nexus for cross-team service calls.
How Ballet is different
- Layer — Temporal is an infrastructure SDK; Ballet is a product (UI + API + runtime).
- Authoring — Temporal: write workflow code; Ballet: Ask Ballet + visual playbook editor.
- Time to value — Temporal: build an app around the SDK; Ballet: describe a playbook, confirm, run.
- Connectors — Temporal: you integrate APIs; Ballet: first-party + MCP built in.
- Observability — Temporal Web UI / CLI vs Studio run timeline and step output.
- Target team — platform / backend engineers vs ops builders + engineers.
- Hosting — self-host or Temporal Cloud vs fully managed Ballet cloud.
Temporal gives you primitives; you still build the product — auth, UI, connector registry, agent prompts, and ops dashboards. Ballet ships those layers: console agent, playbook editor, MCP tools, triggers, and run observability.
Think of it as: Temporal is the engine; Ballet is the car.
Durable wait / human-in-the-loop
Both systems park a long-running process and wake it with an external signal — same product idea, different tokens:
- Temporal — Workflow ID + named Signal (clients often Query for “awaiting approval”).
- Ballet —
runId+ server-issuedrequestIdonstate.resume.
In Ballet, a Code step calls metaphor.waitForInput to park mid-step as suspended. Studio Continue or POST /api/runs/:id/reply with that requestId wakes the same run. Discover park state via GET /runs/:id, SSE input_request, or the Studio curl snippet. See How do I wake a suspended run with reply or resume?.
When to choose Temporal vs Ballet
Choose Temporal when:
- You are building a custom platform and need maximum control over workflow code.
- Your agents must run for weeks with complex signal/wait patterns you own in SDK.
- You have platform engineers to operate Temporal clusters or Temporal Cloud.
Choose Ballet when:
- You want durable playbook runs (including HITL pause/resume) without writing orchestration SDK code.
- Ask Ballet should plan and build workflows from natural language.
- You need MCP connectors, webhook triggers, and Studio debugging out of the box.
Some teams may use both: Temporal for core product infrastructure; Ballet for internal agent ops and playbook automation. They are complementary, not direct substitutes.