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

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.

Start with A2A spec lines 1056–1059 and the Agent Spec definitions for FlowNode and InputMessageNode. Compare the three proposed propagation behaviors and determine the parent status and client-facing contract for each relevant child task state. Done means the chosen behavior and its authoring implications are stated normatively in the spec.