Subagents That Finish Silently Are a Product Bug, Not a UX Quirk

The most damaging bug in a multi-agent system is not always the one where the worker fails. Sometimes the worker finishes, the parent synthesizes the answer, the transcript contains the output, and the human still gets nothing. That is the failure mode in OpenClaw issue #96105, and it is exactly the sort of product bug that turns “autonomous delegation” from a selling point into a trust tax.

The report describes a Telegram direct chat where the main agent promised to wait for a background subagent and return with a consolidated result. The main session id was ed73e650-576c-48ca-9668-2ce2dce73896; the subagent run id was ad0c39c925014caf9. At 18:44 JST, the main agent told the user, in Portuguese, “Disparado. Vou esperar o agent terminar e te trago o consolidado…” — essentially, “Launched. I’ll wait for the agent to finish and bring you the consolidated result.” Around 18:50, the subagent finished and produced a multi-section report. The main agent then generated a long consolidated reply, visible in local transcript JSONL. The user never received it. At 21:51, the user pinged again, frustrated.

The quote embedded in the issue is the part platform teams should not hand-wave away: “You always say you’ll wait and bring me the consolidated result, and you never bring it.” That is not a benchmark complaint. It is a user describing learned distrust. Once users believe the system routinely promises follow-up and goes silent, every future delegation carries an emotional retry cost: should I ask again, check logs, refresh the UI, or avoid the feature entirely?

Delegation creates an obligation, not just a task

Most agent runtimes model background work as a task lifecycle: queued, running, completed, failed, timed out. That is necessary for orchestration, but insufficient for conversation. When the main agent says “I’ll come back with results,” the runtime has created a user-visible obligation. That obligation is not satisfied when the child task completes. It is not even satisfied when the parent model drafts the answer. It is satisfied only when the user receives the answer in the channel where the promise was made.

#96105 is useful because it separates three stages that are too often collapsed: computation, synthesis, and delivery. Computation appears to have succeeded: the subagent finished. Synthesis appears to have succeeded: the parent generated the consolidated reply. Delivery failed somewhere after that. The issue lists several plausible culprits — channel-router drop, hook/heartbeat/dedup/anti-flood swallowing, runtime failure to flush model text to the source channel, or missing routing metadata when the completion event is treated as a system tick. The exact cause matters for the fix, but the product requirement is already clear: generated-but-not-delivered assistant messages need telemetry and recovery.

This is where multi-agent orchestration gets harder than demo videos suggest. Spawning a worker is easy. Showing progress is manageable. Closing the loop reliably across asynchronous completion, parent continuation, channel routing, and provider acknowledgement is the platform work. If the runtime cannot distinguish “the model wrote an answer” from “the user saw the answer,” it is missing the state that actually matters.

OpenClaw is already moving in the right direction, but the surface is broader

The timing overlaps with OpenClaw PR #95776, opened June 22, which adds ACP terminal task completion as a parent-continuation source. That PR wakes parent sessions on ACP task completion, dedupes continuation events by ACP run/session, keeps child output out of the continuation event, and reports focused validation across task-registry tests, task-status tests, auto-reply session tests, and lint. It addresses a related class of issue where ACP background work stopped at lifecycle messages like Background task done, failed, or timed out instead of producing a real parent-agent reply.

That is the right architectural direction: terminal task events should wake the parent, not merely annotate the task. But #96105 suggests the remaining failure surface is larger than ACP wakeups. Native subagents, Telegram routing, cron-triggered work, anti-flood controls, dedup hooks, and channel-specific delivery code can all become places where a completed answer disappears. A wakeup mechanism solves “the parent never resumed.” It does not automatically solve “the parent resumed, generated the answer, and the channel never got it.”

The distinction matters for observability. Agent platforms have become good at showing tool-call traces and task states. They are less consistent about output delivery receipts. For chat systems, that is backward. The user does not care that the answer exists in JSONL if the product never delivered it. Operators need a timeline that includes child completion, parent continuation event, model generation, outbound send attempt, channel/provider acknowledgement, retry decision, and final user-visible status.

How to test the thing users actually experience

Practitioners should stop validating multi-agent workflows only through internal task completion. Test the whole loop in the real channel. In Telegram, Slack, Discord, WhatsApp, webchat, or whatever surface your users rely on, trigger a delegated task that takes long enough to complete asynchronously. Confirm the main agent states a follow-up promise. Then verify that the child completes, the parent wakes, the final answer is generated, the channel send is attempted, and the provider acknowledges delivery. Break each stage deliberately. If the channel send fails, does the runtime retry? If the user pings before completion, does it preserve context? If dedup sees a similar outbound, can it swallow the final report?

The issue’s requested fixes are also the right product primitives: telemetry when an assistant message is generated but not delivered, an ack/echo path so the orchestrator can retry once, and a MAIN_CONTRACT-style pending outbound expectation when the agent promises to come back. That last idea is especially important. The runtime should know when an agent has made a follow-up commitment. If a child finishes and no user-visible answer lands within a reasonable window, the system should warn, retry, or surface a blocker. Silence should be an explicit state, not an accidental outcome.

The broader lesson is that multi-agent systems accumulate trust by closing loops. Every “I’ll get back to you” that resolves into silence teaches the user to supervise the supervisor. That defeats the point of delegation. OpenClaw’s bug report is narrow, but the design rule is general: a background task is not done when the worker exits; it is done when the promised result reaches the human.

Sources: OpenClaw issue #96105, OpenClaw PR #95776, OpenClaw issue #77251, OpenClaw issue #52249