What is the difference between a Workflow and an Activity in durable agent design?

A Workflow is the deterministic orchestrator that defines the sequence and keeps state across retries. An Activity is the place where unstable work happens, such as API calls, LLM inference, or database queries. This separation lets the orchestrator replay safely while the risky operations can fail, retry, and eventually succeed or stop cleanly.

Why the Workflow Is the Orchestrator and the Activity Is the Unstable Work Unit

A durable agent design uses the Workflow as the control plane and the Activity as the execution plane. The Workflow decides what should happen next, preserves progress, and can be replayed without changing the outcome. The Activity is where side effects and volatility belong, because it can fail, retry, and return a result without breaking the orchestrator’s deterministic state.

That split matters because durable systems need both predictability and freedom to interact with the outside world. If the orchestrator itself performs non-deterministic work, replay can diverge from the original run and the state machine stops being reliable. If the unstable work is isolated into Activities, the Workflow can resume from the last known checkpoint instead of re-running everything.

This is the same design principle behind keeping decision logic separate from action logic. The Workflow should express the business sequence, branching, timers, and compensation rules. The Activity should encapsulate I/O-heavy or failure-prone operations, such as calling APIs, reading databases, or invoking an AI Agent Observability, Audit and Incident Response Guide-style action path where traceability and recovery matter more than pure determinism.

What Changes When the Boundary Is Wrong

The boundary is not just a style choice. It determines whether retries are safe, whether replay is trustworthy, and whether failures stay local or poison the whole run. A durable workflow that includes unstable side effects can duplicate external actions, reissue calls, or drift from the sequence it originally intended.

By contrast, Activities are allowed to be messy because the framework expects them to be retried or to fail independently. That makes them the right place for latency, transient errors, rate limits, and integrations that may not behave consistently on every execution. In practice, the Workflow holds the durable intent, while the Activity holds the operational uncertainty.

For agentic systems, the same separation also helps control delegated action. A workflow can decide when an agent is allowed to proceed, while an Activity can execute one bounded step at a time under an explicit policy. That is why least privilege and per-action authorization are often stronger when the code path that makes the decision is not the same path that performs the external side effect.

How to Use the Split in Practice

Think of the Workflow as the place for logic that must replay identically, and the Activity as the place for anything that depends on the outside world. Sequencing, timers, state transitions, and compensation belong in the Workflow. API calls, database queries, LLM inference, and other unstable operations belong in Activities because they are not guaranteed to return the same answer twice.

That division also improves debugging. When a run misbehaves, you can inspect the Workflow history to understand the decision path, then inspect the Activity boundary to see which external operation introduced delay, failure, or inconsistency. It becomes much easier to tell whether the problem is in orchestration, integration, or the underlying dependency.

Where teams get into trouble is letting Activities grow into hidden orchestrators. Once an Activity starts making its own branching decisions, coordinating retries, or chaining multiple external calls, the durable boundary becomes blurred and the design loses clarity. If a step needs to be replay-safe, make it part of the Workflow; if it needs to touch an unreliable dependency, make it an Activity and keep its contract narrow.

Risk and Threat Considerations

The main risk in durable agent design is unsafe replay or duplicated side effects. If unstable operations sit inside the Workflow, a retry or replay can repeat a payment, resend a message, or re-run an action that should have happened once, which turns resilience logic into an exposure path.

Failure mechanism: Non-deterministic logic inside the orchestrator changes the execution history on replay, so the engine can no longer reconstruct the same state from the same inputs.

Impact: The system can produce duplicate external effects, inconsistent state, and misleading audit history, especially when retries and partial failures occur under load.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	ASI02 — Tool Misuse	Workflows and Activities separate orchestration from tool execution.
	ASI03 — Identity & Privilege Abuse	Agent actions need explicit authority boundaries between decision and execution.
Recommendation — Keep tool execution in bounded Activities and validate each tool invocation. Separate policy decisions from execution and enforce per-action authorization.
NIST SP 800-53 Rev 5	AU-3 — Content of Audit Records	Durable replay and action tracing depend on preserving execution history.
	IA-5 — Authenticator Management	Activities often invoke authenticated external services and secrets.
	AC-6 — Least Privilege	Activities should be narrowly scoped because they perform the risky external work.
Recommendation — Record workflow state changes and external action outcomes in audit logs. Manage credentials used by Activities with rotation, protection, and revocation. Scope each Activity to the minimum access needed for its single task.

Practitioner Guidance

What to verify: Check that every Workflow decision can be reconstructed from its recorded history alone. If a branch depends on a live API response, database read, or model output, that logic belongs in an Activity, not in the durable path.

Decision rule: If the code must be replay-safe, deterministic, and stateful across retries, keep it in the Workflow. If it can fail independently, vary between runs, or needs external I/O, isolate it in an Activity and make the boundary explicit.

Practitioner takeaway: Durable agent design works when orchestration is treated as a deterministic record of intent and Activities are treated as bounded points of uncertainty, because that is what preserves both correctness and recoverability.