Skip to main content
AutoAgentBuilder is not deterministic. Every call designs a fresh team, which is exactly what you want while exploring and exactly what you do not want in production. This tutorial covers the workflow that gets you both: let the model draft the roster, then take ownership of it.

Overview


Step 1: Understand what varies

Two calls to the same builder with the same task can differ in agent count, names, model assignments, and prompt wording.
This also means build_configs() followed by build_agents() designs two teams — so the roster you printed is not the roster you ran. Always generate once and reuse the result.
For a demo this is harmless. For a system where you need to reproduce yesterday’s output, review prompts before they ship, or explain why a run behaved a certain way, it is not.

Step 2: Draft and freeze

Commit roster.json. It is now a reviewable artifact — a diff shows exactly how the team changed.

Step 3: Edit before building

The configurations are plain dicts, so they are yours to change. This is where the builder’s draft becomes your production roster.

Step 4: Construct and run


Complete Example

Run it twice: the first run calls the builder and writes the file, the second reads it and makes no builder call at all.

Regenerating deliberately

Delete the file, or version it by task:
Keeping one file per task lets you regenerate a single roster without disturbing the others.

Why not just cache in memory?

An in-process cache dies with the process, so a restart silently redesigns the team. Writing to disk gives you three things a memory cache cannot:

Use Cases

  • Production pipelines — the same team on every run, auditable after the fact
  • Prompt engineering — start from a generated draft, refine by hand
  • Cost control — one builder call ever, instead of one per run
  • Compliance — every agent instruction is committed and reviewed before shipping
  • A/B testing — keep two roster files and compare them on the same task

See also