Skip to main content
Writing a multi-agent system normally starts with you hand-authoring every agent: a name, a description, a system prompt, a model. AutoAgentBuilder moves that step to the model. You describe the task; it returns the roster.

Overview


Step 1: Install and Import

The builder agent needs a model that supports function calling.

Step 2: Look at the roster before running anything

Set return_dict=True and nothing is constructed — you get plain dicts back.
Typical output:
Notice the builder chose a different model per agent and added an adversarial reviewer on its own. Both come from the default builder prompt.

Step 3: Run the team

Drop return_dict and run() returns constructed agents instead.

Roster size: the one gotcha

max_agents is a ceiling, not a target. The default builder prompt says “fewer is almost always better” and “2–3 agents is the common, correct case,” so a request for five will routinely return three.
max_agents=5 producing a 3-agent roster is the builder working correctly, not a bug. Use num_agents when the count matters.
If the model still returns fewer than num_agents, a warning is logged and the shorter roster comes back. Agents cannot be invented for a task that does not support them.

Complete Example

Every public method makes a fresh LLM call and the builder is not deterministic. Calling build_configs() and then build_agents() designs two different teams. Generate once and reuse the result, as above.

Choosing an architecture

The builder returns a plain list of agents, so it composes with any structure:

Configuration Options


Use Cases

  • Prototyping — get a working team for a new problem in one call, then hand-tune the prompts
  • Dynamic workloads — build a fresh team per incoming request rather than maintaining a fixed roster
  • Roster exploration — generate several teams for the same task and compare decompositions
  • Teaching — read the generated system_prompt fields as worked examples of prompt design

See also