Skip to main content
Agents can route user requests to the most appropriate specialist automatically.

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: set isStart 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

A taskType: '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

Always have a fallback for unmatched requests.
Distinct keywords for each route prevent confusion.
Start with keyword matching, add complexity only if needed.
nextTasks for a fixed path, when for a yes/no branch, a decision table for many outcomes.

Handoffs

Transfer conversations

Teams

Multi-agent teams