What Actually Moves When You Switch Backends?

This checkpoint uses one concrete situation—a developer moves from a local Agent Server to another backend while working in OpenHands Agent Canvas—to connect ownership, routing, identity, caches, credentials, workspace scope, and conversation validity. The goal is not to repeat each mechanism separately, but to make a useful judgment: which parts of the user’s intention can remain continuous, and which runtime state must be rebuilt before the next action is safe.

One intent, two kinds of continuity

Suppose a developer is reviewing a repository through Canvas. The task is stable: inspect the code, make a change, and explain the result. The place where that task runs is not stable. A local Agent Server may use the developer’s machine and its existing provider login. A remote or Cloud backend may use a different workspace, authentication method, event path, and recovery model. The interface can preserve the task as a recognizable human goal, but it cannot carry every detail of the local runtime into the new authority.

This distinction is the key integration. Canvas supplies continuity of intent and coordination. The active backend supplies continuity of execution only while the conversation and workspace remain valid there. A backend switch changes the authority under the interface, so values that look like ordinary state—host, key, organization, workspace, query results, conversation ID—become meaningful only in relation to the new backend.

flowchart LR intent["Same user intent"] --> canvas["Canvas coordination"] canvas --> selection["Active backend and auth"] selection --> local["Local namespace"] selection --> cloud["Cloud namespace"] local --> localState["Local cache, workspace, conversation"] cloud --> cloudState["Cloud cache, workspace, conversation"] canvas --> continuity["User goal and familiar surface"] localState -. "must not leak" .-> cloudState

The diagram separates what the interface can preserve from what the backend must re-establish. “Review this repository” can remain the same sentence in the chat box. The repository path, credentials, cached settings, event connection, and conversation record cannot be assumed to have the same meaning after the switch. Portability is achieved by re-binding the request to the new namespace, not by copying old authority across it.

This produces three layers of continuity that are easy to confuse. The first is semantic continuity: the user still wants the same review or code change. The second is interface continuity: Canvas can keep the same navigation, conversation list, and settings concepts. The third is runtime continuity: the same agent process, workspace, credentials, and event stream remain alive. A switch can preserve the first two while deliberately breaking the third. That is not a failed abstraction; it is the condition that prevents an old runtime from being mistaken for a new one.

That is why a backend entry needs a kind, authentication mode, and sometimes an organization scope in addition to a host. A local Agent Server expects a session-key header. The Cloud API normally expects a bearer token, while a Cloud runtime sandbox may use a session key through a runtime-specific host. The selected backend tells Canvas which transport and credential boundary to use.