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_iterover (both classes have it), - maps
max_retry_limit→max_retriesonly when you changed it (otherwise the team keeps its own default of5, sinceExecutionConfig.max_retry_limitdefaults to2), - emits a
UserWarningnamingMultiAgentExecutionConfigand listing every field with no team-level counterpart (e.g.code_execution,max_rpm).
- Right — team-level config
- Wrong — single-agent config
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_itercarries over (both classes have it).max_retry_limitmaps to the team’smax_retries— but only when you explicitly changed it. Otherwise the team keeps its own default of5(becauseExecutionConfig.max_retry_limitdefaults to2).- A
UserWarningnamesMultiAgentExecutionConfigand lists every field that has no team-level counterpart (e.g.code_execution,max_rpm), so you can see exactly what was ignored. - Passing
MultiAgentExecutionConfigstays silent.
- Wrong shape (single-agent config)
- Right shape (team-level + per-agent)
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 —
MultiAgentExecutionConfigCommon Patterns
Pattern 1 — Long-running research workflow
Pattern 2 — Conservative limits for cost control
Best Practices
Tune max_iter per task complexity
Tune max_iter per task complexity
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.max_retries for fault tolerance
max_retries for fault tolerance
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.Monitor with hooks
Monitor with hooks
Pair
MultiAgentExecutionConfig with MultiAgentHooksConfig to log when retries happen. This helps diagnose why tasks hit their retry limit in production.Related
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)

