Agents in workflows

A workflow node can dispatch to two kinds of agents, and both appear in the same picker when you build a pipeline.

Platform-deployed agents

Agents built and deployed in the workspace join the picker under their friendly name — but only while they are deployed and running. An agent that exists but is not live cannot actually receive a dispatch, so it is filtered out of the picker. Deploy the agent first, then add it to the pipeline.

Right after a deployment you do not need to wait for the agent to warm up: if the agent is still starting when the platform reaches out to it, the platform retries briefly instead of failing, so registering or running against a just-deployed agent no longer fails spuriously.

External agents

Agents running outside the platform can participate too, once they are registered in the workspace with their endpoint and (optionally) a credential. They appear in the picker suffixed with (external), and the platform attaches the registered credential on every dispatch to them. See External agents for how registration works.

Registration is safe to repeat: registering an agent whose endpoint URL (or name) is already on record updates the existing entry in place — its skills, schemas, and card are refreshed — rather than failing as a duplicate. Redeploying an agent behind a stable URL therefore keeps its registration current automatically; only a genuinely new URL-and-name pair creates a new entry.

Registered skills can carry typed input schemas — either advertised on the agent's card or supplied at registration. The workflow planner uses them to decide which fields a run must collect: a required schema field that is not fed by a previous step becomes a $userinput.<field> input on the Run panel (see Planning a workflow), and the same schemas drive the structured forms shown when invoking a typed skill directly.

One contract every dispatched agent should know about: workflow steps are delivered at least once. If an interruption leaves a step's outcome unknown, the platform re-dispatches it rather than silently dropping it. Every dispatch for a given step carries the same X-Workflow-Execution-ID and X-Workflow-Step-ID request headers across attempts, so an agent whose actions must not happen twice can use them to deduplicate.

When an agent is removed

Workflows keep a reference to each agent they dispatch to. If one of those agents is deregistered, every workflow that references it is marked orphaned:

• Orphaned workflows stay visible and editable in the list and detail pages — nothing is deleted.
• Runs are refused with an explanatory error until the pipeline is fixed.
• The workflow reactivates automatically when either the pipeline is edited so every node points at an available agent, or an agent with the same name is registered again.

The console surfaces this state with an orphaned status chip and a banner on the workflow detail page explaining how to recover. Conversely, an edit that introduces an unknown agent orphans the workflow on save — the status always reflects whether every node is currently resolvable.

Scheduled runs

Workflows support recurring execution. Choose a frequency when creating the workflow (hourly, daily, weekly, or monthly), or add, change, and remove the schedule later by updating the workflow — under the hood the schedule is a cron expression with a time zone, so API clients can set any recurrence, not just the console presets.

Behavior to know:

• Scheduled runs create ordinary executions — they appear in the executions list and are monitored exactly like manual runs.
• The console presets fire at 09:00 UTC for daily, weekly (Monday), and monthly (1st of the month); hourly fires on the hour.
• Removing the schedule (or deleting the workflow) removes the recurring trigger; no further automatic runs start.
• An invalid cron expression is rejected at save time.

The workflows list shows each workflow's schedule (manual when none), so you can see at a glance which ones run on their own.