Skip to main content
Multi-Agent Execution config controls how many times each task can iterate and how many retries are allowed when tasks fail.
PraisonAIAgents here is a silent alias for AgentTeam, the canonical multi-agent class. AgentManager and Agents are aliases too — see Back-compat class aliases.

ExecutionConfig vs MultiAgentExecutionConfig

Only MultiAgentExecutionConfig is the team-level config. Passing the single-agent ExecutionConfig to the team no longer silently drops fields — it issues a UserWarning, adapts what it can, and names what it ignored. When you pass an ExecutionConfig to AgentTeam(execution=...), the team:
  • carries max_iter over (both classes have it),
  • maps max_retry_limitmax_retries only when you changed it (otherwise the team keeps its own default of 5, since ExecutionConfig.max_retry_limit defaults to 2),
  • emits a UserWarning naming MultiAgentExecutionConfig and listing every field with no team-level counterpart (e.g. code_execution, max_rpm).
Passing the correct class stays silent.
Split the knobs by scope: per-agent settings (code_execution, max_budget, max_rpm, parallel_tool_calls) belong on each Agent(execution=...); team-level orchestration (max_iter, max_retries) belongs on MultiAgentExecutionConfig.
The user sets iteration and retry limits; the workflow stops or retries tasks within those bounds.

ExecutionConfig vs MultiAgentExecutionConfig

Only MultiAgentExecutionConfig is the team-level config. If you pass the single-agent ExecutionConfig to AgentTeam(execution=...), the team adapts what it can and warns instead of silently dropping the rest:
  • max_iter carries over (both classes have it).
  • max_retry_limit maps to the team’s max_retries — but only when you explicitly changed it. Otherwise the team keeps its own default of 5 (because ExecutionConfig.max_retry_limit defaults to 2).
  • A UserWarning names MultiAgentExecutionConfig and lists every field that has no team-level counterpart (e.g. code_execution, max_rpm), so you can see exactly what was ignored.
  • Passing MultiAgentExecutionConfig stays silent.
Split the config by scope: per-agent knobs (code_execution, max_budget, max_rpm, parallel_tool_calls) belong on each Agent(execution=...); team-level orchestration knobs (max_iter, max_retries) belong on MultiAgentExecutionConfig.

Quick Start

1

Simple Usage

2

With Custom Retry Settings


How It Works


Configuration Options

Full list of options, types, and defaults — MultiAgentExecutionConfig

Common Patterns

Pattern 1 — Long-running research workflow

Pattern 2 — Conservative limits for cost control


Best Practices

Simple tasks (classification, extraction) need max_iter=5–10. Complex research or multi-step synthesis tasks may need max_iter=20–30. Start low and increase if tasks don’t complete.
Set max_retries=3–5 for workflows calling external services that may fail intermittently. For offline or deterministic tasks, max_retries=1–2 is usually enough.
Pair MultiAgentExecutionConfig with MultiAgentHooksConfig to log when retries happen. This helps diagnose why tasks hit their retry limit in production.

Multi-Agent Hooks

Intercept task lifecycle events

Multi-Agent Planning

Plan tasks before executing them

Execution Systems

Single-agent execution configuration

Agent Retry

Single-agent retry behavior

Spawn & Announce

Reliable async sub-agent spawn — no hangs, safe sync/async mixing (#4887)