State, Human Judgment, and the Cost of Continuity

Once Dify can place a stateful Agent inside a workflow, “memory” is no longer a sufficient description of what persists. The specific problem is to distinguish immutable Agent material, mutable workspaces, materialized participants, request-time access, and human approval across nested runs. Understanding those transitions lets the reader decide what must be retained, who owns it, and why continuity can fail without being silently replaced.

Continuity has layers, not one kind of memory

Dify's Agent runtime separates four resources that are easy to collapse into one vague idea of an environment. A Home Snapshot is an immutable version of Agent-owned Home content. A Workspace is mutable working data owned by a product scope such as a conversation, a build draft, or a workflow run. An Execution Binding is one materialized participant: it connects an Agent to a Workspace, gives that participant a private Home, and carries a resumable session. A RuntimeLease is temporary access to the physical binding while an operation is active.

These resources answer different questions. A Home Snapshot asks which baseline content an Agent should receive. A Workspace asks where mutable working files belong. A Binding asks which concrete participant and session a product flow is using. A RuntimeLease asks whether the current operation is allowed to access that participant now. Treating them as interchangeable makes it impossible to tell whether a later request should reuse a session, share files, materialize a new Home, or merely reacquire access to an existing resource.

The support assistant makes the distinction practical. A conversation may need to retain an Agent's working files across turns, while a pure workflow run may need an isolated workspace that ends with the business process. Two participants can use the same workspace while keeping separate materialized Homes in a Local backend. The same Agent can consequently have more than one active binding in a product context, with each binding carrying its own session and Home identity. Shared work data and private Agent state are related, but they are not the same resource.

Dify API owns the lifecycle ledger. It stores records for Home Snapshots, Workspaces, and Bindings, along with opaque backend references and the latest Agent session snapshot. Dify Agent does not connect to the product database or maintain this persistent registry. The backend reference is intentionally opaque: the API knows which binding it selected, while the runtime backend interprets the reference and supplies the physical resource. The session snapshot can be serialized and restored; a live lease, backend SDK object, credential, or temporary access token is not placed into that snapshot.

This ownership boundary changes how creation works. If an Agent has an exact Home Snapshot, the selected backend must materialize that snapshot; the system must not quietly fall back to another Home. If no logical snapshot is configured, the backend can materialize its deployment-default Home for a new binding. That default is mutable and private to the binding; it is not automatically an immutable snapshot record. The distinction prevents a temporary materialization from being mistaken for a versioned artifact that can be reproduced later.

Before an Agent request, Dify resolves the product context to a specific binding. For a conversation, the session store can reuse the participant associated with that conversation and Agent. For a pure workflow, the ownership scope is tied to the workflow run or node execution. If the binding is missing, retired, owned by the wrong context, or based on a mismatched Agent configuration generation, the request fails fast. It does not search by Agent, recency, or candidate count and create a replacement. That refusal is deliberate: a new environment might look operationally convenient but would change the meaning of continuity and could expose the wrong files or session.