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"
Number of times the whole flow runs per run() call. Values below 1 are treated as 1.
bool
default:"False"
Add the step-by-step flow structure to the shared conversation at the start of each run
OutputType
default:"all"
Output format, for example "all", "final", "list", "dict" or "str-all-except-first". An unknown value raises ValueError at construction.
Any
default:"None"
Accepted for backwards compatibility and stored, but never read. Use persistent_memory=True on individual agents instead.
bool
default:"False"
Log every flow step and agent transition. Pass verbose=True while debugging a flow.
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. Each call starts a fresh shared conversation, so a reused instance does not carry the previous task’s transcript.

batch_run()

Process multiple tasks in batches. Batches run one after another, the tasks inside a batch run concurrently, and each task runs on its own clone of the flow. Results come back in input order.

concurrent_run()

Run multiple tasks concurrently. Each task runs on its own clone of the flow, so tasks never share a conversation. Results come back in input order.

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:
Every agent in a single-agent step is told its neighbours as a system turn, for example "Sequential awareness: Agent ahead: agent1 | Agent behind: agent3", whether or not team_awareness is set. With team_awareness=True, the shared conversation also starts with the full sequential flow structure, so every agent sees the whole pipeline.

Use Cases

Content Creation Pipeline

Software Development

Market Analysis

Dynamic Flow Management

Change Flow at Runtime

Add/Remove Agents

agents is a plain list. Look an agent up by agent_name rather than indexing it with a name, and update the flow with set_custom_flow() after removing an agent it references.

Sequential Awareness

Agents can understand their workflow position:

Advanced Features

Custom tasks for specific agents

run() accepts a custom_tasks dict, but the current implementation splices the custom task text into the flow as if it were an agent name. A run with custom_tasks raises ValueError: either the agent name is not found in the flow, or the spliced text is “not registered” when its step is reached. Put per-agent instructions in each agent’s system_prompt instead.

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() does not validate the whole flow first. It raises a similar ValueError only when it reaches the step that references the unregistered agent, so every earlier step has already run. Validate up front to avoid wasting that work. set_custom_flow() validates the new flow immediately and keeps the old one if the new one is invalid.