[Spec] How should a child task's input-required state propagate through a parent FlowNode? #183

Per the A2A spec ll. 1056–1059, an input-required task is resumable by sending a new message with the same taskId / contextId. The Agent Spec doesn't define the parent-flow side of this contract when a FlowNode invokes a child agent over A2A.

Scenario

Parent flow A contains a FlowNode that invokes agent B. Agent B reaches an InputMessageNode and yields input-required. What is the parent A expected to do?

a) Pause its own run and surface B's pending input to A's client (nested HITL propagation)
b) Treat the child pause as a leaf event and continue A's flow (fire-and-forget)
c) Implementation-defined

The spec is silent. Implementations diverge. In practice this matters whenever an agent composes a sub-agent that itself contains a HITL gate — a very common pattern for orchestrators that delegate to leaf agents with operator approval steps.

Why filing as spec-level

The A2A protocol covers the bilateral task contract. The Agent Spec's FlowNode is the natural place to nail down "what happens when the invoked agent returns input-required" — it sits exactly at that protocol seam.

Possible answers worth documenting in the spec

• A FlowNode MUST propagate the child's input-required to its own client, mirroring the contract for InputMessageNode (most explicit option)
• A FlowNode MAY declare propagate_pending_input: true | false per-node (gives flow authors a choice)
• The parent run's status transitions when a child A2A task yields are normatively defined for each child task state

Current consequence

Without a defined contract, every implementation either:

• Reinvents nested-HITL surfacing (real platform work — runtime needs to render child task state in the parent's UI)
• Falls back to operationally-deep-linked separate runs ("open this in a new tab, then return")

Both are workable, but they produce very different UX and authoring contracts depending on which runtime the same OAS file targets.