OpenClaw’s Hub-Delegated ACP Workers Make Multi-Agent Orchestration Less Thread-Shaped

OpenClaw’s ACP delegation work is easy to describe badly: “persistent external harness sessions without threads.” Accurate, but too small. The more interesting point is that PR #91093 admits something most multi-agent products still pretend is not true: the thread is a UI affordance, not an orchestration primitive.

Discord and Telegram threads are convenient. They give users a visible place to continue a coding session, and they give the platform a relatively obvious object to bind state to. But many real surfaces are not thread-shaped. WebChat, WeChat, embedded support chat, mobile assistants, and enterprise messengers often give you a single visible conversation, not a durable nested workspace for every delegated worker. If persistent coding sessions require threads everywhere, then the orchestration model is being dictated by the channel, not by the task.

PR #91093 adds hub-delegated persistent ACP workers: background external harness sessions that can survive across turns without being bound to a channel thread. The PR was created June 7, updated June 19, and is large enough to deserve careful review: 3,319 additions, 928 deletions, and 196 changed files by the research window. It defines three ACP spawn shapes: mode: "run" for non-persistent one-shot work, mode: "session" plus thread: true for thread-bound persistence, and delegate: true for hub-owned persistent workers.

Persistence needs a contract, not just storage

The most important design choice is that OpenClaw did not simply relax mode: "session" and let non-thread sessions exist in a vague middle state. The PR explicitly forbids thread binding for delegated workers and keeps mode: "session" without thread fail-closed. That is good API design. Persistence by itself is not a contract. It is just state that refuses to die.

A useful persistent worker needs rules. Who owns it? How is it named? Who can send follow-up messages? Can two labels collide? How does it close? What happens when it idles? Can it echo messages back into its parent and accidentally create agent-to-agent loops? What metadata must be present before a repair path is allowed to revive the session? These questions are not implementation details; they are the product.

The proposed API makes those semantics explicit. An agent can spawn with sessions_spawn({ runtime: "acp", delegate: true, label?, task }), follow up with sessions_send(label=...), list workers, and operators can use /acp delegate list|status|close <label>. The PR’s reviewer checklist focuses on owner-boundary correctness, owner-scoped label uniqueness, parent-owned A2A skip conditions, lifecycle maintenance, close ordering, fail-closed metadata repair, and JSON-store versus SQLite discovery parity. That is exactly the right checklist. The feature is not “can Claude Code keep running?” It is “can a user safely operate a persistent external worker from a hub surface without accidentally crossing identity, lifecycle, or routing boundaries?”

External harnesses are becoming part of the comparison matrix

OpenClaw’s ACP docs position ACP as the path for external harnesses such as Claude Code, Cursor, Copilot, Droid, OpenClaw ACP, OpenCode, Gemini CLI, and similar ACPX systems. That matters because coding-agent comparison is no longer just model quality or editor integration. The question is whether an orchestration platform can manage heterogeneous workers with predictable ownership and recovery semantics.

If a team compares Claude Code, Codex, Cursor, OpenCode, and Gemini CLI in 2026, it should ask operational questions, not only benchmark questions. Can a worker survive across turns? Does persistence require a chat thread? Are labels scoped globally or to the owning hub session? Can a user accidentally send a follow-up to another user’s worker because the label looked friendly? How does idle cleanup work? What does “close” mean if the external harness is still alive? Can the platform repair a lost session ID, and what proof does it require before doing so?

Those questions sound bureaucratic until the first delegated worker touches a production repository or cloud account. Persistent background agents are authority-bearing objects. They can keep context, credentials, file-system access, and task momentum after the visible conversation has moved on. That is the whole point. It is also the risk. A stale worker is not like a stale browser tab. It may still know what to do.

The UI should not leak into the control plane

The deeper lesson is that channel UI shapes should not become control-plane shapes by accident. Threads are a nice way to show continuity, but they are not the only way continuity exists. A hub-delegated worker needs a control-plane identity independent of whether the user is on Discord, Telegram, WebChat, WeChat, or a future client nobody has shipped yet.

This is where many multi-agent systems get theatrical. They show agents talking to agents in a chat transcript and call that orchestration. Useful orchestration is less cinematic. It is labels, owners, lifetimes, repair rules, capability boundaries, and auditability. The PR’s A2A loop-prevention work is a perfect example. Once agents can message other agents, it is not enough to make the messages flow. The platform also has to know when not to respond. Otherwise a parent-owned delegate can become a ping-pong machine with a build directory.

There is also a user-experience win here. In a hub surface, a person should be able to say “send that to the backend worker” or “close the migration worker” without being forced into a separate visible thread for every task. That is not just cleaner UI. It maps better to how people think about delegated work. A named worker is closer to a background job, a teammate, or a service account than to a chat room.

What practitioners should do with this

Teams building internal agent platforms should treat this PR as a design prompt. If your system supports persistent external workers, write down the worker contract. Define the owner. Define label scope. Define the close path. Define idle and max-age behavior. Define what metadata is required for repair. Define whether a worker can receive messages from another agent and what loop-prevention rules exist. If the answers live only in code paths, the system is not ready for broad use.

Teams evaluating vendors should ask for a demo that breaks the happy path: two users create workers with the same label, a worker loses its backend session ID, a parent tries to message its own delegate, an idle worker is revived, and a hub session attempts to reach a worker it does not own. The vendor’s answer to those edge cases will tell you more than a polished “agent writes a todo app” clip.

PR #91093 is ambitious and therefore risky. Nearly 200 files changed means migrations, stores, commands, UI assumptions, and repair logic all have to agree. That is why the review should be boring and proof-driven. But the direction is right. Agent orchestration needs to move beyond thread metaphors. Persistent workers need ownership, labels, lifecycle policy, and loop prevention. Anything less is just a chat transcript with a longer memory.

Sources: OpenClaw PR #91093, OpenClaw ACP agents docs, PR review/comment thread, decoupled session context issue #53548