Agent runtime vs. workflow engine: a clarifying boundary

There's a recurring confusion in agent-shop architecture review: teams reach for a workflow engine (Temporal, Restate, Inngest) to "make agents durable", and end up with two systems fighting for ownership of the same state.

Two different jobs

A workflow engine owns deterministic replay of long-running stateful business logic. Its primitives are activities, signals, timers. It assumes your code is the source of truth.

An agent runtime owns the execution of a non-deterministic, LLM-driven program. Its primitives are model calls, tool calls, memory pages, sandboxes. It assumes the LLM is the source of next steps.

Where they meet

The agent runtime should run on top of the workflow engine, not next to it:

• Each LLM call becomes an activity (idempotent, retried by the workflow).
• Each tool call becomes an activity (capability-checked at the boundary).
• Memory writes are journaled by the workflow.
• The agent program is the workflow's "code".

This is the architecture used implicitly by Cloudflare Agents, Restate's agent demos, and the durable-execution path in DBOS. Drawing the boundary explicitly is what unlocks the rest of the design.

What this means for your stack

Pick one workflow engine. Wrap your agent runtime calls in its activity API. Stop trying to have your runtime also solve crash-safe resume on its own.