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