Skip to main content
The AgentRearrange system enables sophisticated multi-agent orchestration through custom flow patterns. Define how agents communicate using simple syntax: -> for sequential execution and , for concurrent execution.

When to Use

  • Flexible workflows: Mix sequential and parallel execution
  • Dynamic routing: Tasks need different paths through agents
  • Complex coordination: Multiple agents with custom relationships
  • Adaptive workflows: Flow changes based on task requirements
  • Team awareness: Agents need context about team structure

Flow Syntax

  • agent1 -> agent2: Sequential execution (agent2 runs after agent1)
  • agent1, agent2: Concurrent execution (both run simultaneously)
  • agent1 -> agent2, agent3: Combined (agent1 first, then agent2 and agent3 in parallel)

Basic Example

Complex Flow Patterns

Fan-Out Pattern

One agent distributes to multiple agents:

Fan-In Pattern

Multiple agents converge to one:

Multi-Stage Pipeline

Key Parameters

str
default:"AgentRearrange"
Name for the agent rearrange system
List[Agent]
required
List of agents to orchestrate
str
required
Flow pattern defining agent execution (e.g., “agent1 -> agent2, agent3”)
int
default:"1"
Maximum number of execution loops
bool
default:"False"
Enable agents to know their position in workflow
OutputType
default:"all"
Output format (all, final, list, dict)
Any
default:"None"
Optional memory system for persistence
bool
default:"True"
Log every flow step and agent transition. This defaults to True, so a fresh AgentRearrange is noisy out of the box — pass verbose=False for quiet runs.
bool
default:"True"
Persist workflow state. Defaults to True.
bool
default:"False"
Record an ISO timestamp on every conversation message.
bool
default:"False"
Attach a unique id to every conversation message.

Methods

run()

Execute the defined flow with a task.

batch_run()

Process multiple tasks in batches.

concurrent_run()

Run multiple tasks concurrently.

run_async()

Asynchronous task execution.

run_stream() / arun_stream()

Stream tokens as agents execute, in flow order. Sequential segments (A -> B) stream one agent at a time; parallel segments (A, B) interleave tokens from concurrent agents fairly.
Pass with_events=True to receive structured agent_start / token / agent_end event dicts instead of (agent_name, token) tuples.
max_loops > 1 and custom_tasks are not supported in streaming mode. Use run() for those.

explain()

Print or return the resolved execution plan for the current flow. It validates the flow, then lists every step in order and marks each as sequential or parallel. No agents or LLMs are invoked, which makes it cheap enough for CI smoke tests and pre-flight checks.
bool
default:"False"
When True, return the plan as a string. When False, print it and return None.
Optional[str]
The plan string when return_str=True; otherwise None.
explain() validates the flow first and raises if it is invalid — the same error run() would raise.

Team Awareness

Enable agents to understand their position in the workflow:
With team awareness, agents receive context like:
  • “Agent ahead: agent1”
  • “Agent behind: agent3”
  • Sequential flow structure information

Use Cases

Content Creation Pipeline

Software Development

Market Analysis

Dynamic Flow Management

Change Flow at Runtime

Add/Remove Agents

Sequential Awareness

Agents can understand their workflow position:

Advanced Features

Custom Tasks for Specific Agents

Output Formatting

Best Practices

Flow Design: Start simple and add complexity as needed. Test with “agent1 -> agent2” before complex patterns.
  1. Clear Flow Logic: Ensure flow makes sense for your task
  2. Agent Naming: Use descriptive names for clarity in flow definitions
  3. Validate Flow: Use validate_flow() before production
  4. Team Awareness: Enable when agents benefit from position context
  5. Start Simple: Begin with sequential, add concurrency where beneficial
Flow validation happens at runtime - ensure all agent names in flow exist in the agents list

Flow Validation

Construction only checks that flow is a non-empty string — it does not verify that every agent name in the flow is registered. Call validate_flow() explicitly (or explain(), which calls it internally) to catch typos before running:
run() will also raise a similar ValueError at execution time if it reaches a step referencing an unregistered agent, so validation happens automatically before any agent work is wasted — just not at construction time.