Action block

An Action block is a step that runs after the Agent produces its answer. Unlike a Tool, the Agent does not choose whether to call it — the Flow does, based on wiring. And unlike a Tool, the Action’s arguments come from mapping Agent output fields into the Action’s inputs, not from the LLM picking them. Use Actions for anything you want to happen because the Agent decided X — not for anything the Agent needs to decide during its reasoning.

​

Examples

• Send an email summary after the Agent classifies a ticket.
• Write a row to a CRM after the Agent extracts fields from a contract.
• Post a Slack message when the Agent flags a high-risk trace.
• Kick off a downstream pipeline.

​

Configuring an Action

Same shape as a Tool:

• Kind — HTTP or Inline.
• Endpoint / code — where the call goes or what runs.
• Input mapping — how to fill the Action’s inputs from upstream Agent output. Drag from output fields to Action inputs, or write a small JSONPath expression.

​

Approvals

Actions can require approval before firing. Held Actions appear in the Approvals queue with the arguments already resolved — reviewers see exactly what would happen. Common case: an Action that sends a customer refund is set to require approval. The Agent decides when, but a human confirms whether.

​

Order of execution

If a Flow has multiple Actions downstream of an Agent, they fire in the order shown in the Inspector’s Action order list. Drag to reorder. Failures in one Action don’t block the next unless you mark the Action must succeed — then a failure aborts the remaining Actions and marks the run as errored.

​

Retries

Set per-Action retry policy: attempts, backoff, and which HTTP status codes count as retryable. Off by default — turn on for flaky third-party APIs.

​

Difference from a Tool, at a glance