ACP Background Tasks Need to Wake the Parent Agent, Not Just Announce That They Finished

Background tasks are supposed to buy back attention. If an agent can delegate work to an ACP harness, wait for completion, and then leave the parent conversation sitting there like a CI job with no status check, the platform has not built orchestration. It has built a very expensive notification system.

That is the bug OpenClaw PR #95776 is trying to close. The change adds ACP as an internal task-completion event source and queues a parent-session continuation when ACP work reaches terminal delivery. In plain English: when the child finishes, the parent should wake up and answer the human, not merely emit a generic “Background task done...” line and call it a day.

The distinction sounds small until you run agents in a channel where users expect results. Issue #52249 describes the UI-shaped version: a parent session yields while waiting for an ACP child, the child completes, and the parent stays stuck until a manual refresh. Issue #77251 describes the group/channel version: background ACP or subagent completions stop at generic lifecycle messages — “Background task done,” “Background task failed,” or “Background task timed out” — without the parent agent synthesizing the useful follow-up. Both failures point at the same contract gap. A task ended; the conversation did not continue.

Completion is not conversation

This is one of the places where agent platforms inherit the hard parts of job queues, chat products, and distributed systems at the same time. A terminal event is an operational fact. It says a worker reached success, failure, timeout, or cancellation. A parent continuation is product behavior. It says the system knows who asked, where they asked, what state the parent was in, and how to resume the thread without leaking the wrong payload into the wrong place.

PR #95776 is intentionally narrow, which is a good sign. It frames itself as the “narrow ACP task-terminal continuation slice” of the broader parent-session wakeup problem. It does not try to redesign delegation. It wires ACP terminal delivery into the internal completion path so the parent can continue. The verification notes are also the sort operators should prefer over hand-wavy release prose: task-registry.test.ts reports 41 passing tests, task-executor-policy.test.ts reports 5, task-status.test.ts reports 9, changed-file oxlint reports 0 errors, and git diff --check is clean. Full pnpm check still fails on existing repo-wide type/export drift outside the patch, which is annoying but at least honestly scoped.

The most important design choice is what the PR does not do: it does not include child output in the internal continuation event. That boundary matters. A child transcript can contain tool logs, partial reasoning, raw command output, internal planning, sensitive paths, or simply prose written for the parent agent rather than the end user. Treating child output as automatically safe parent context is how multi-agent systems turn “delegation” into “copy-paste with extra attack surface.”

The parent needs a wake signal and access to the appropriate stored task state. It does not need an unfiltered blob of everything the child saw. That pattern is familiar from mature queue systems: completion signals should be structured, idempotent, and separate from payload exposure. If the parent needs the result, it can fetch or summarize from the task record under the normal policy path. The completion event itself should be small, sanitized, and boring.

Where this bites practitioners

The obvious failure mode is user annoyance. Someone asks OpenClaw to delegate a coding task to Codex, Claude Code, Gemini, OpenCode, or another ACP harness. The background task completes. The channel receives a lifecycle line. Then nothing useful happens. That is bad enough, but the deeper operational problem is state ambiguity. Did the child fail? Did the parent miss the event? Was the result suppressed because the channel was a group? Is the parent still yielded? Did a duplicate terminal event get ignored correctly or accidentally dropped?

Those questions matter because background delegation is the feature that makes agent platforms feel less like chatbots. Long-running code edits, research passes, issue triage, dependency audits, and multi-file refactors should happen off the main conversational path. But the moment a human has to manually refresh, ask “what happened?”, or inspect task logs to recover the answer, the platform has pushed orchestration work back onto the user.

Teams building on ACP should test this in the channel where the workflow actually happens, not just in a local happy-path UI. Run one successful task, one failed task, one timeout, and one quiet completion. Confirm that the parent produces a useful follow-up exactly once. Confirm that group contexts do not get spammed with duplicate lifecycle chatter. Confirm that blocked follow-up behavior still holds when policy says the parent should not continue. If your acceptance test is merely “the child process exited,” you are testing the worker, not the product.

This also changes how teams should think about “multi-agent” claims. Spawning a worker is table stakes. The useful system knows how to wake the right parent, preserve channel identity, avoid duplicate continuations, keep child transcript content out of unsafe surfaces, and produce a user-facing answer that reflects the completed work. That is not glamorous. It is the part users notice.

OpenClaw’s adjacent v2026.6.10-beta.2 work tells the same story: channel/session state, cron delivery awareness, trusted policies, and runtime catalog truth are becoming first-class control-plane concerns. PR #95776 belongs in that cluster. It is not a new model, a new agent personality, or a demo-friendly feature. It is a repair to the wake semantics that make delegated work useful.

The editorial read: multi-agent orchestration is not “spawn a worker and hope.” It is terminal events, idempotency, sanitized internal messages, parent-agent continuation, and channel-correct synthesis. If the parent does not wake up, the architecture is asleep too.

Sources: OpenClaw PR #95776, OpenClaw issue #52249, OpenClaw issue #77251, OpenClaw v2026.6.10-beta.2