When Your Agent Pipeline Goes Dark: Three Multi-Agent Coordination Failures ClawMetry Surfaces

A single agent failing is annoying. A multi-agent pipeline failing is expensive and invisible in a completely different way. When a solo agent loops or hangs, at least the problem is local. When an agent pipeline breaks, the failure can be three hops away from where you're looking, each individual agent appears healthy from its own perspective, and the cost accumulates silently across every level of the stack.

I want to walk through three failure patterns I've been seeing repeatedly in 2026 as teams move from single agents to orchestrated pipelines. These aren't the same failures as the overnight token loop or the silent hang. Those are single-agent problems. The patterns below are fundamentally multi-agent: they emerge from the relationship between agents, not from any individual agent's behavior.

Incident 1: The Orphaned Sub-Agent

Here's how the tree looked: the orchestrator spawned a coding sub-agent to implement a feature and run its test suite. The coding agent, following instructions, spawned its own sub-agent to execute the tests in an isolated environment. The test runner consumed too much memory during test setup, was OOM-killed by the OS, and exited with no output and no error file.

From the coding agent's perspective, it had dispatched a task and was waiting for results. From the orchestrator's perspective, the coding agent was running a long task. Both were correct. Both were indefinitely blocked. The OOM kill was the only error in the system, and it happened inside the test-runner process which wrote nothing to the agent's visible output before dying.

Source: pattern synthesized from multi-agent coordination failures reported in OpenClaw and LangGraph community forums, June–July 2026

What makes this particularly costly: every level of the stacked wait kept its context window warm. The orchestrator was spending context tokens on the "in progress" state. The coding agent was doing the same. Three agents accruing context cost, producing zero output. Six hours later, the batch job deadline passed and a human noticed the expected result had not arrived.

What ClawMetry surfaces

Without cross-agent visibility, each agent looks fine in isolation. The sub-agent tracker is the only place in the stack where you can see the whole tree at once and notice that a leaf has gone silent while the rest of the tree is stuck waiting for it.

Incident 2: The Schema Drift Gap

This failure mode became widely documented in early 2026 when several agent frameworks upgraded their tool schema generation simultaneously. The pattern: a tool call that was valid under one schema specification becomes invalid under a new version of the spec. The LLM API (both OpenAI and Anthropic) rejects the malformed schema and returns an error. But many agent frameworks have error handlers that catch this rejection and substitute a null/None result rather than propagating the error upward. The agent receives None where it expected a rich tool response and continues.

Source: documented in Braintrust's 2026 agent debugging analysis; pattern confirmed in n8n v2.4.7→v2.6.3 migration reports and FlowiseAI schema incidents, February–March 2026

In a multi-agent context this is especially damaging because the agent that initiated the failing tool call may be several hops removed from the orchestrator. The orchestrator sees that sub-agent B returned a result. It doesn't know that sub-agent B's result was built on a null tool response. The garbage propagates upward through the chain, getting incorporated into each agent's reasoning, until a human notices that the final output makes no sense.

The reason this is hard to catch: the framework returned success at every level. HTTP 200s throughout. No exception. No log entry at ERROR level. The only signal is the content of the tool response, which was None.

What ClawMetry surfaces

The sub-agent tracker (left) and transcript tool call timeline (right) make cross-agent failures visible as a unified view.

Incident 3: The Compaction Mid-Pipeline

Context compaction is a necessary fact of life for long-running agents. When a context grows beyond the model's working window, it gets summarized. Summaries lose detail. Usually the lost detail doesn't matter. But in a multi-step pipeline, the agent's context contains not just the task history but the pipeline contract: “your output must be valid XML for downstream parser v3.”

When that instruction is compacted away, the agent doesn't know it's lost. It continues executing its task diligently, producing output in its default format (typically Markdown or plain text). The downstream parser (which uses XPath extraction and expects XML tags) scans the output, finds no tags, and returns an empty string with a success status code. It's doing its job correctly: the instruction says “return the parsed content,” the content has nothing to parse, the parsed result is empty. No error.

Source: pattern synthesized from reports of compaction-related pipeline failures in developer communities; compaction behavior confirmed in OpenClaw and Claude Code documentation, 2026

The cost here isn't just the wasted run. It's the diagnostic time. Without the full session transcript, reconstructing what happened requires digging through logs across three or four services: the orchestrator, the compaction event, the agent's session, and the downstream parser. All of them logged success. Finding the dropped instruction requires knowing where to look and in what order.

What ClawMetry surfaces

The common thread

Each of these three failures has the same fingerprint: every individual component reports healthy status, but the system as a whole is broken. This is qualitatively different from single-agent failures. A single agent looping has one bad actor you can point to. A multi-agent pipeline failure has no bad actor: every agent is behaving correctly given what it can see. The pathology lives in the gaps between agents.

• Incident 1: Orchestrator healthy, coding agent healthy, test runner… gone. No single agent misbehaved. The gap between test runner exit and coding agent awareness is where the failure lived.
• Incident 2: Tool returned a response (null), framework substituted a value (None), agent received it and continued. All transitions were technically successful. The failure lived in the semantic gap between what was sent and what was expected.
• Incident 3: Compaction ran correctly, agent summarized correctly, agent continued correctly from the summary. The failure lived in what the summary omitted.

Traditional APM gives you per-service health. That's not sufficient for this failure class. You need a unified view of the agent tree: sub-agent relationships, cross-session context propagation, and the full verbatim record of what each agent was given at each step.

What we built for each of these

For orphaned sub-agents

The sub-agent tracker at /api/subagents shows every child session spawned by every parent, with last-event timestamps and cost attribution. The stalled-session detection (active session with no new events for a configurable threshold) applies at every level of the tree, not just the top-level orchestrator. Cloud Pro adds Slack/PagerDuty alerts that include the full parent-child tree so you can see the whole picture at a glance.

For schema drift

The transcript viewer stores every tool call verbatim, including null and error responses that frameworks would normally swallow. The tool call timeline makes anomalous responses (empty content, schema rejections, unexpected types) visible in context. Usage analytics surface tools with high null-response rates across sessions, so you catch the drift before it compounds.

For compaction mid-pipeline

Compaction events are first-class markers in the session transcript, timestamped and stored with the pre- and post-compaction context. This is the single most important forensic record for diagnosing compaction-related failures: instead of reconstructing from scattered logs, you open the transcript and read the compaction summary directly to see what was dropped.

The sub-agent tracker and transcript viewer are part of the open-source local-first DuckDB store. Cross-session tracing and Slack/PagerDuty alerting are Cloud Pro features.

The honest part

ClawMetry surfaces these failures once they've happened. We're not a static analyzer that tells you in advance that your pipeline's error handling is insufficient, or that a compaction event might drop a specific instruction. We also can't know that a sub-agent should have returned by time T without you configuring an SLA for that session type. The stalled-session detection is only as good as the threshold you set.

What we do well: we give you the complete forensic record. When something goes wrong in a multi-agent pipeline, the difference between a two-hour debugging session and a five-minute one is usually whether you have the full transcript, the sub-agent tree, and the compaction history in one place. That's what ClawMetry stores, locally, without the data leaving your machine.

Multi-agent failures are going to get more common. Teams are stacking agents three, four, five levels deep. The gap between each level is a potential failure surface that traditional APM doesn't see. That's the space we're building for.