Structured-output subagent failures are silently dropped from workflow results

Type: bug · Area: multi-agent workflows / subagent orchestration

Environment

• Claude Code, model Opus 4.8, background workflow orchestration
• Pattern: pipeline() / parallel() fanning out subagents that each return a validated object via a JSON schema

Summary

When a subagent is required to return structured output against a JSON schema and it exhausts the StructuredOutput retry cap (observed: 5 attempts), the agent() call throws. Inside pipeline()/parallel() a throwing item resolves to null, and the idiomatic .filter(Boolean) at the end removes it. Net effect: the workflow reports "completed" while having silently returned a subset of the requested work, with the shortfall visible only in a secondary failures/logs field that is easy to miss.

Steps to reproduce

1. Author a workflow that fans out N subagents over N items, each with a large/strict schema (additionalProperties:false, many required nested fields).
2. Give the items uneven surface area so the largest one or two produce very long output.
3. Run it. The large items exceed the retry cap and fail; the array comes back with fewer than N entries after .filter(Boolean).

Expected

A workflow that cannot complete all requested units should make that loud and unmissable in the primary result — not require the author to diff result.length against the input length or read a separate failures field.

Actual

result silently contains fewer items than requested; overall status is "completed."

Impact

High for correctness-sensitive work (audits, migrations, reviews). A partial result presented as complete is exactly the substitution failure these workflows are meant to prevent. The larger and more valuable the unit (biggest subsystem, most complex file), the more likely it is the one dropped — so the most important item is the one most likely to vanish.

Suggested direction

• Make dropped-item count a first-class, surfaced outcome (non-zero dropped → visible in the primary summary, not just logs).
• Consider a strict mode where any dropped item fails the workflow unless explicitly tolerated.
• A recovery mechanism (bounded auto-retry with a degraded schema) would prevent most of these in the first place — filed separately as a companion enhancement.

Filed from real multi-agent workflow usage. Happy to provide sanitized run traces on request.