Context
flows schedule has no --local-agent flag. flows run and flows resume both accept one (packages/sdk/src/cli.ts:107,111,113); the schedule usage line at packages/sdk/src/cli.ts:100 does not:
flows schedule <flow.yaml|flow.ts> [--cron "<expr>" | --every <n><s|m|h|d>] [--tz <IANA>] [--input <...>] [--name <name>] [--no-connect] [--json]
So the documented way to schedule a flow parks forever at any agent step — silently, on a timer, with nobody watching. For a product whose headline is scheduled agentic workflows, this is a significant hole.
Reported in the Relayflows v2 Field Report (2026-09-18, Julian Fann). Their workaround was cron driving flows run --local-agent. The transport: 'relay' route needs an agent-relay session and a cloud login, which reported expired (The agent-relay cloud login has expired), so they could not test it.
What to change
Pick one, and make it explicit either way:
- Accept
--local-agent on flows schedule, persisting it with the schedule so each tick attaches a worker the same way flows run does.
- Refuse at creation time. If a scheduled flow contains an
agent step and no worker surface is configured, refuse the schedule command with a message saying an agent step needs an attached worker and naming the supported ways to provide one.
Silently accepting a schedule that can never progress past its first agent step is the one outcome to rule out.
Acceptance
flows schedule of a flow with an agent step either runs that step on a tick, or is refused at creation with a message naming the fix.- A test covers the agent-step-plus-schedule combination and asserts the chosen behaviour.
flows schedules shows whether a schedule has a worker surface, so an existing broken schedule is discoverable without waiting for a tick.
Out of scope
Context
flows schedulehas no--local-agentflag.flows runandflows resumeboth accept one (packages/sdk/src/cli.ts:107,111,113); thescheduleusage line atpackages/sdk/src/cli.ts:100does not:So the documented way to schedule a flow parks forever at any agent step — silently, on a timer, with nobody watching. For a product whose headline is scheduled agentic workflows, this is a significant hole.
Reported in the Relayflows v2 Field Report (2026-09-18, Julian Fann). Their workaround was cron driving
flows run --local-agent. Thetransport: 'relay'route needs an agent-relay session and a cloud login, which reported expired (The agent-relay cloud login has expired), so they could not test it.What to change
Pick one, and make it explicit either way:
--local-agentonflows schedule, persisting it with the schedule so each tick attaches a worker the same wayflows rundoes.agentstep and no worker surface is configured, refuse theschedulecommand with a message saying an agent step needs an attached worker and naming the supported ways to provide one.Silently accepting a schedule that can never progress past its first agent step is the one outcome to rule out.
Acceptance
flows scheduleof a flow with an agent step either runs that step on a tick, or is refused at creation with a message naming the fix.flows schedulesshows whether a schedule has a worker surface, so an existing broken schedule is discoverable without waiting for a tick.Out of scope