[Spec] No primitive for external-event or time-based wait

[groganz]

The standard Flow node library in OAS 26.1.0 covers LlmNode, ApiNode, AgentNode, FlowNode, MapNode, StartNode, EndNode, BranchingNode, ToolNode, InputMessageNode, OutputMessageNode, ParallelMapNode, ParallelFlowNode (per the Standard library of nodes section).

None of these expresses "wait for an external event" or time-based delay. InputMessageNode is the only pause primitive and is explicitly user-input semantics — "wait for a user input and restarts after getting it" (spec ll. 1351–1359), with output typed as user-input string.

Use cases with no spec-blessed expression today

• Scheduled execution — "send this email at 9am Tuesday"
• Recurring execution — "fire this flow every cron tick, resuming from a paused node"
• External-trigger wait — "pause until the upstream system emits event X"
• Time-based delay — "wait 24h after the previous step, then continue"

Today, implementations must choose one of

1. Split the agent into N separate runs orchestrated externally (loses the single-flow declarative narrative)
2. Hijack InputMessageNode with vendor metadata to signal "resume via scheduler, not human" (semantic abuse — the spec says user input)
3. Extend the spec with a non-portable node type (loses portability — defeats the framework-agnostic premise)

All three are common in practice across teams hitting this gap.

Concrete proposal

A WaitNode (or ScheduleNode) primitive parameterised on the wait source:

{
  "component_type": "WaitNode",
  "id": "wait_for_send_trigger",
  "wait_source": {
    "trigger_ref": { "$component_ref": "trigger_subflow" }
  },
  "outputs": [
    { "title": "release_payload", "type": "object" }
  ]
}

wait_source would be a discriminated union over at least:

• trigger_ref — wait on the output of a sibling subflow that produces a trigger config
• delay_seconds — fixed delay
• cron — cron expression
• external_event — implementation-defined event channel

A2A representation would need a matching task state — either reuse input-required with a wait_source discriminator on the task metadata, or introduce a new waiting-for-event state.

Why a spec primitive rather than a vendor extension

If the spec doesn't bless a pattern, every implementation invents a different one and portability of OAS files across runtimes breaks for any flow that needs to express deferred execution. A primitive in the standard library would let runtime adapters converge.

Happy to draft a proposal PR if there's appetite. Even a "this is out of scope, here is the recommended pattern" answer would be valuable so implementers stop diverging on workarounds.