The wayflowcore worker dispatches a flow via a single blocking client.sendTask call. Agent Spec already has a notion of trigger-gated runs (pending_trigger / armed lifecycle), but the gate is checked only at run-start — there's no per-step hook to inspect mid-flight node transitions and gate them on an external scheduler.
Use case
"Send the email when the trigger fires, not when the run dispatches."
With run-start gating only, the only way to express this is to split orchestration into multiple runs (lose the single-flow declarative narrative) or invent a custom node-type extension. Both approaches diverge across teams.
What would help (any of)
- A documented per-step hook in the executor lifecycle that runtime adapters can wire to inspect / gate node transitions
- A first-class executor for an external-wait node type that yields the conversation back to the caller pending an external resume signal
- A spec-blessed pattern for resuming a paused conversation via a non-human-input event — companion to
InputMessageNode for the scheduler case
Tactical workaround in use today
A custom node that yields with task_state="input-required" plus a vendor metadata.resumeSource="trigger-release" marker. The dispatcher detects the marker, persists the held a2aContextId, transitions the run to a custom waiting_* status, and exits cleanly. An external job later resumes by sending a new A2A message into the held context — same mechanism as resuming an input-required user prompt.
This works but is semantically off (the spec says input-required means user input) and platform-specific. A documented hook or canonical pattern would let adapters converge.
Related upstream spec gap
The fundamental missing primitive (no WaitNode / ScheduleNode in OAS 26.1.0) is also worth flagging at the spec level — filed separately at oracle/agent-spec for that broader discussion. This issue is specifically about the wayflowcore implementation side: even with a spec extension, the runtime needs a hook to make it work end-to-end.
The wayflowcore worker dispatches a flow via a single blocking
client.sendTaskcall. Agent Spec already has a notion of trigger-gated runs (pending_trigger/armedlifecycle), but the gate is checked only at run-start — there's no per-step hook to inspect mid-flight node transitions and gate them on an external scheduler.Use case
"Send the email when the trigger fires, not when the run dispatches."
With run-start gating only, the only way to express this is to split orchestration into multiple runs (lose the single-flow declarative narrative) or invent a custom node-type extension. Both approaches diverge across teams.
What would help (any of)
InputMessageNodefor the scheduler caseTactical workaround in use today
A custom node that yields with
task_state="input-required"plus a vendormetadata.resumeSource="trigger-release"marker. The dispatcher detects the marker, persists the helda2aContextId, transitions the run to a customwaiting_*status, and exits cleanly. An external job later resumes by sending a new A2A message into the held context — same mechanism as resuming aninput-requireduser prompt.This works but is semantically off (the spec says
input-requiredmeans user input) and platform-specific. A documented hook or canonical pattern would let adapters converge.Related upstream spec gap
The fundamental missing primitive (no
WaitNode/ScheduleNodein OAS 26.1.0) is also worth flagging at the spec level — filed separately atoracle/agent-specfor that broader discussion. This issue is specifically about the wayflowcore implementation side: even with a spec extension, the runtime needs a hook to make it work end-to-end.