Skip to main content
The Runtime field on the Agent Info tab decides where the agent loop executes. The same agent definition can run on any of three runtimes; you change it from a dropdown.
Runtime selector on Agent Info

Local

The agent loop runs in the same process as the request handler.
  • Latency — lowest (no broker hops).
  • Durability — none. If the process crashes mid-run, the run is lost.
  • Concurrency — limited by the process.
  • Best for — development, short interactive chats, low-risk operations.

Temporal

Each agent loop runs as a Temporal workflow; each IO operation (LLM call, tool call) is a Temporal activity.
  • Durability — workflows survive process restarts, replay deterministically from history.
  • Retries — per-activity retry policy with exponential backoff.
  • Long-running — workflows can run for hours or days; the agent can sleep on Delay nodes or wait for approvals without holding compute.
  • Streaming — handled via a sidecar Redis stream so the client still sees token-by-token output.
  • Best for — production agents, anything that calls expensive tools, anything you can’t afford to lose.

Restate

Each agent loop runs as a Restate workflow; each IO operation is a durable Restate step.
  • Durability — IO results are memoized by Restate. On recovery the workflow replays the recorded results instead of re-issuing the calls.
  • Streaming — also Redis-sidecar based.
  • Best for — teams already running Restate, agents with idempotency requirements around external side effects.

Same agent, any runtime

The agent definition (prompt, tools, schema, etc.) is identical across runtimes. You can develop on Local, switch to Temporal for production, and the agent’s behavior is unchanged — only its durability characteristics differ. Workflows have the same Local-vs-Temporal choice, with the same trade-offs.