Quick Start
1
Simple Usage
2
With Configuration
User Interaction Flow
Configuration Levels
Routing Options
API Reference
Conditions Module
Routing conditions module
Task-Level Routing
A team of tasks routes itself: setisStart and nextTasks (or a decision table) and the graph, not the list order, decides what runs.
process: 'workflow' turns on the graph. Without it, a team walks the task list in order.
Follow a fixed path
isStart picks the entry point; nextTasks picks what runs after.
Pass tasks as plain objects.
import { Task } from 'praisonai' is the workflow-step class ({ name, execute }) and does not accept these routing fields — Team reads isStart, nextTasks, taskType, and routing directly off the object.Branch on a condition
when gates thenTask and elseTask. {{previous_output}} holds the last result.
Route on a decision
AtaskType: 'decision' task reads a decision field from its answer and follows the routing table. The target 'exit' ends the run.
condition is the older name for routing — same table. The model often wraps JSON in a ```json fence; the fence is stripped before decision is read, so {"decision":"approve"} and its fenced form route the same way. A decision that matches nothing ends the run. Cycles are bounded by maxIter.Best Practices
Set a default agent
Set a default agent
Always have a fallback for unmatched requests.
Use clear keywords
Use clear keywords
Distinct keywords for each route prevent confusion.
Keep routes simple
Keep routes simple
Start with keyword matching, add complexity only if needed.
Pick the smallest routing tool
Pick the smallest routing tool
nextTasks for a fixed path, when for a yes/no branch, a decision table for many outcomes.Related
Handoffs
Transfer conversations
Teams
Multi-agent teams

