Skip to main content
Workflows give you precise control over how an agent navigates a conversation. Instead of relying purely on the agent’s LLM to decide what to do next, you define a directed graph of steps — the agent follows the graph, executing nodes in order and branching based on conditions or LLM decisions. This makes complex, multi-step interactions reliable, auditable, and testable.

What Is a Workflow?

A workflow is a directed graph composed of nodes and edges. Nodes represent discrete steps in a conversation. Edges represent transitions between steps, optionally conditioned on data from the previous node. You author a workflow by writing structured instructions — natural language descriptions of each step, what the agent should do, and when to move on. Feather’s compiler translates these instructions into a compiled_graph object, which the runtime executes.
A workflow is attached to an agent revision, not directly to an agent. This means your workflow and your agent’s system prompt, tools, and policies are all versioned together. Updating your workflow requires creating and publishing a new agent revision.

The Authoring Model

1

Write instructions

Create a workflow with a human-readable instructions block. Describe each step you want the agent to take, in plain language. Reference node types by name to signal what kind of step each one is (e.g. “Ask the user for their order number. This is an agent step.”).
2

Compile the workflow

Call POST /v1/workflows/revisions/{revision_id}/compile. Feather’s compiler parses your instructions and generates a compiled_graph — a structured JSON representation of all nodes, edges, and conditions.Compilation is asynchronous. Poll compilation_status on the revision until it reaches completed or failed.
3

Review the compiled graph

Inspect the compiled_graph to verify that Feather interpreted your instructions correctly. You can also visualize the graph in the Feather dashboard’s workflow editor.
4

Attach to an agent revision

Call POST /v1/agents/revisions/{agent_revision_id}/workflows with the workflow revision ID. The workflow is now active for any conversation that uses this agent revision.
5

Test in the playground

Use POST /v1/workflow/playground/sessions to run the workflow interactively before promoting it to production.

Node Types

Feather workflows support four node types, each serving a distinct role in a conversation graph:

Agent node

An LLM-powered step. The agent receives instructions, the current conversation context, and any attached tools and knowledge bases. It generates a response and determines the next edge to follow based on the outcome.

Action node

A deterministic, code-like step that executes a specific API call or data transformation without LLM involvement. Use action nodes for reliable, repeatable operations like looking up an order status or sending a confirmation email.

Handoff node

Transfers the conversation to a human agent queue. Execution of the workflow pauses while the conversation status moves to waiting_for_human. The workflow resumes (or closes) based on your configured resume policy.

Approval node

Pauses execution and creates an approval request for a human reviewer. The workflow branches based on the reviewer’s decision — one edge for approved, another for rejected. Use approval nodes to gate high-stakes actions like issuing refunds or modifying account data.

Node configuration

Each node type accepts different configuration fields:
FieldDescription
instructionsThe system-level guidance for this specific step (appended to the agent’s base system prompt)
tool_refsOptional override of which tools are available in this node only
knowledge_base_refsOptional override of which KBs are searched in this node only
exit_conditionsArray of conditions that define which edge to take when the node completes
FieldDescription
tool_idThe tool to invoke deterministically
input_mappingJSONPath expressions mapping conversation context to tool input fields
output_mappingJSONPath expressions mapping tool output to conversation context variables
on_errorEdge to follow if the tool call fails
FieldDescription
queue_idThe human agent queue to route to
handoff_messageOptional message shown to the human agent on pickup
resume_on_returnWhether to continue the workflow after the human returns control (true) or close the conversation (false)
FieldDescription
approval_promptThe question shown to the human reviewer
timeout_hoursHow long to wait for a decision before taking the timeout_edge
approved_edgeNode to transition to on approval
rejected_edgeNode to transition to on rejection
timeout_edgeNode to transition to if the timeout elapses

The Revision Model

Workflows follow the same revision model as agents:
StageDescription
DraftThe workflow revision is editable. You can update instructions and recompile as many times as needed.
CompiledThe compiled_graph has been generated. The revision is still in draft but ready to be attached.
AttachedThe workflow revision has been attached to an agent revision. It cannot be modified while attached.
If compilation fails, check the compilation_errors array on the revision. Common causes include ambiguous edge conditions, circular references between nodes, and missing tool IDs. Fix the instructions and recompile.

Compilation

Calling POST /v1/workflows/revisions/{revision_id}/compile kicks off the async compilation process. You should poll the revision until compilation_status is no longer pending:
GET https://api-sandbox.featherhq.com/v1/workflows/revisions/{revision_id}
compilation_statusMeaning
pendingCompilation is queued or in progress
completedcompiled_graph is populated and ready
failedCompilation encountered errors; see compilation_errors
Once compilation completes, Feather populates compiled_graph with the full node and edge definitions. You can inspect this field to verify the structure before attaching the workflow to an agent revision.

The Playground

Before attaching a workflow to a production agent revision, use the workflow playground to run interactive test sessions:
POST https://api-sandbox.featherhq.com/v1/workflow/playground/sessions
The playground creates an isolated session tied to a specific workflow revision. You submit turns and observe how the workflow traverses nodes, which edges it follows, and what each node returns. Playground sessions are not counted as production live conversations and do not affect end user records.
Use the playground to simulate approval and handoff paths by responding as the human reviewer. This lets you validate all branches of your workflow graph before deploying to end users.

Next Steps

Workflows API Reference

Full reference for workflow, revision, compilation, and playground endpoints — including complete request schemas and compiled graph examples.