Skip to content
pcxpcx docs

Workflow

Graphs of steps that run when something happens, over the tools of every module - one generic tool block reaches any module’s RPC, so every new module is a block with no extra code. Built-in API blocks (GitHub, Slack, Stripe, REST) come from the http module’s presets.

Triggers

Section titled “Triggers”
Trigger Starts when
schedule a scheduler job names the workflow
webhook a webhooks source posts to it (the verified body is the input)
event an event of the host’s bus, with an optional filter
manual a person or an agent runs it (workflow_run)
call another workflow, or an agent calling it as a tool

Blocks

Section titled “Blocks”
  • Actions: tool (one RPC of a module), model (one model call with a prompt and an output schema - classify, extract, sum up), agent (a turn of a team member with its own tools), workflow (another workflow).
  • Flow: if, switch, for_each (a body per item, up to 16 at once), parallel (all / first / first N), wait (a duration, a time, or an event), approval - the run stops until a person (or the team’s trust) approves, as a board decision with a risk.
  • Data: the outputs of the blocks are the run’s state (steps.<id>, input, trigger in CEL); set, state (a key-value store kept between runs), filter, transform, validate.
  • Every block has retry and timeout, and an error edge that takes the run on when it fails after its retries.

Notes

Section titled “Notes”
  • A run is pinned to the version it started on; changing a workflow never changes a run in flight.
  • A workflow asks for grants - the modules its blocks may call; each call is checked again at run time. Calls that act outside are decisions when the team’s trust says so.
  • Runs have budgets (steps, tokens, cost, wall time).
  • The workflow-builder built-in agent and skill build workflows with you.