OpenClaw’s Cross-Agent Reply Bug Shows How Fast a Multi-Agent Demo Turns Into a Routing Problem

Multi-agent demos have a bad habit of looking finished right up until the result comes back to the wrong person. That is the real story behind OpenClaw PR #70607, a tiny routing fix that reads like a one-character typo and behaves like a trust bug. On paper, nothing catastrophic happened. A parent agent spawned a child agent, the child did the work, and completion delivery fired. In practice, the answer landed in the child agent’s own binding instead of the parent session that asked for it. That is not a cosmetic flaw. It means the orchestration path succeeded while the human-facing control plane failed.

The specific bug is almost comically small. According to the PR, the relevant logic in resolveRequesterOriginForChild used !== where it needed ===. That one-character mistake caused cross-agent spawns to resolve the child’s binding and overwrite the parent’s requesterAccountId. The patch flips the condition so binding resolution now applies only to self-spawns, while genuine cross-agent handoffs preserve the originating parent identity. GitHub’s metadata shows the pull request opened at 2026-04-23T12:33:53Z, touched just two files, and changed 63 total lines. Small diff, large blast radius.

What makes this worth a full post instead of a changelog footnote is that it exposes where multi-agent systems usually stop being magic and start being distributed systems. Everyone wants to talk about planning, delegation, specialist workers, and orchestration graphs. Fewer people want to talk about reply paths, channel bindings, account identity, and delivery metadata. But those boring details are what determine whether a multi-agent product feels reliable or haunted.

The linked issue #70574 says the failure mode was deterministic. That matters. Deterministic routing bugs are not flaky edge cases, they are structural. And the surrounding issue history says this was not a one-off stumble. Issue #69201 reported children losing deliveryContext thread metadata. Earlier, issue #58874 fixed a subagent announce flow that hardcoded sourceChannel: "webchat" regardless of the real origin channel. Read together, that trail says OpenClaw is moving from “can spawn subagents” to “can preserve end-to-end conversational identity.” Those are not the same engineering problem, and the second one is where products either mature or embarrass themselves.

There is a broader lesson here for anyone building agent systems. The moment one agent can delegate to another, you inherit the old distributed-systems questions in new clothes. Which identity owns the response. Which context survives the hop. Which thread receives the completion. Which default binding wins when the initiating session and the worker’s home channel disagree. Logs may show a successful child run, but if the completion arrives in the wrong conversation, the user experiences failure. Agent vendors keep learning this the hard way because orchestration looks like cognition in a demo and looks like message routing in production.

That is why the right way to evaluate multi-agent tooling is not “did the worker run?” It is “did the result come back to the exact place, account, and thread that requested it, with the correct metadata preserved?” Builders should test that explicitly across Slack threads, Discord threads, web chat, cron-triggered runs, and router-worker chains. If your QA plan ends at tool execution, you are testing the interesting half and ignoring the expensive half.

It is also why the current market language around multi-agent systems is often too generous. Many platforms are really showing parallel task execution with a thin routing layer and calling the whole thing a collaborative swarm. Real collaboration requires reply ownership, attribution, handoff semantics, and observability. Otherwise you are not shipping teamwork, you are shipping background jobs that occasionally forget who asked.

OpenClaw deserves some credit here for the shape of the fix. The patch does not add another override flag or a best-practices doc. It restores the parent’s origin identity centrally in the routing logic. That is the correct instinct. When reply ownership is a platform invariant, the fix should live in the shared path, not in per-channel duct tape. The early code-review reaction reflects that. Greptile reportedly gave the fix a high-confidence read, and the issue had already been mirrored outside the main repo, which suggests operators had felt enough pain to escalate it quickly.

Still, this kind of bug should reset expectations for anybody betting heavily on multi-agent coding workflows right now. The industry keeps acting as if the hard part is model specialization, planner quality, or prompting style. Those matter, but the next tranche of failures is going to be operational: routing, identity, replay, retries, delivery semantics, and policy inheritance. The glamorous part of agent systems is delegation. The product part is getting the delegated result back to the right human without breaking trust.

For practitioners, the takeaway is practical. If you are running a router-plus-worker pattern, add routing assertions to your test matrix. Verify completion destination, thread preservation, source-channel fidelity, requester identity, and behavior across self-spawn versus cross-agent spawn paths. If you are buying rather than building, ask vendors to demo that exact behavior instead of another “look, three agents collaborated” animation. A multi-agent platform that cannot guarantee reply routing is not mature, it is just busy.

My take is simple. The most interesting part of PR #70607 is not the typo. It is the reminder that multi-agent systems are really communication systems with AI attached. Once the reply path gets real, the magic act ends and the engineering begins. That is good news, because boring invariants are how software becomes trustworthy. But it is also a warning: the platforms that win this category will not just be the ones that can delegate work. They will be the ones that can bring the answer home.

Sources: OpenClaw PR #70607, issue #70574, issue #69201, issue #58874