How to build a team of AI agents: 9 stages from first agent to production crew.

Most people who try to build a “team of AI agents” end up with one agent talking to itself in five tabs. 9out of 10 multi-agent projects never make it out of demo mode.

The agents don’t share context, don’t divide work, don’t know what the others are doing. This is the 9-stage roadmap that turns that mess into a crew that actually coordinates.

Follow my Substack to get fresh AI alpha:

movez.substack.com

An AI agent team sounds simple: a few agents, each with a job, working together on something one agent could not finish alone. In practice, the moment you try it, you discover the problems no demo ever shows.

What works is structure. The 9 stages below are the structure - built from Anthropic’s own engineering writing on the Claude Agent SDK, the patterns in their multi-agent research blueprint, and what teams shipping real agent systems in 2026 do differently from the ones still stuck in demo mode.

Three tiers: get one agent right, get them coordinating, get the whole crew production-ready.

9 stages. 3 tiers. One crew that finishes work while you sleep.

Part 1 · The Single Agent

01. Define the agent loop

The most common mistake before stage one even begins: confusing a smart chatbot with an agent. A chat is a turn.

An agent is a loop - the model receives a goal, picks an action, runs it, observes the result, and decides what to do next. It keeps going until the goal is done or the loop hits a stop condition.

Everything else in this article assumes you have a real loop in code. Pseudo-code makes the shape obvious:

Notice what is in there: an approval gate, a logging hook, and a clear stop condition. If your “agent” is one big prompt that asks the model to do everything in one shot, you do not have an agent - you have a long completion. Everything later in this article needs a real loop to build on.

Pro tip: The stop condition matters more than people think. A loop with no clear end will burn money. Common stop conditions: goal achieved, max iterations reached (typically 30–50), explicit user halt, error threshold exceeded. Always set max_iterations. A runaway agent is worse than a slow one.

02. Engineer the context. Write, Select, Compress, Isolate.

Context is the most expensive and most fragile part of an agent. Most agent failures - the ones that look like “the model is dumb” - are actually context failures: the model never had what it needed, or it had too much and got distracted, or what it had was stale.

The four operations that matter, from Anthropic’s own engineering writing:

• Write - what gets added to context at each step. Be deliberate. Every line costs tokens and attention.
• Select - what to pull from memory or files. Retrieval, not dumping.
• Compress - when context fills up, summarize older parts while keeping decisions intact.
• Isolate -subagents work in their own context window so the main thread stays clean.

In practice this means a structured context object, not free-form string concatenation. Here is the shape a working agent context takes:

The biggest single win here is isolating subagent context. When the main agent delegates research to a subagent, the subagent gets a fresh window with only the task and relevant files. It returns a summary, not its raw transcript. The main agent never sees the noise. This single pattern is why subagents work at all.

03. Write tools the model picks correctly

Without typed tool schemas the model improvises message formats, argument structures, and permissions for every call.

That improvisation is where most production failures come from. Not because the model cannot call the tool, but because it guesses the wrong format, sends the wrong arguments, or does something it should not have permission to do.

A typed schema converts the task from “guess how to call this” into “fill in these fields.” And it lets the harness enforce rules the model cannot bypass:

The fields beyond basic types are what make it production-grade: preconditions are what must be true before the call runs. side_effects tell downstream readers what will happen. requires_approval routes the call to a human checkpoint. blocked_targets are hard constraints the harness enforces no matter what the model decides.

Part 2 · The Coordination Layer

04. Spawn subagents with isolated context.

A subagent is not a copy of the main agent. It is a specialist with its own context, its own toolset, and often its own model. When the orchestrator decides “this part is research,” it spawns a research subagent - gives it only the relevant goal, lets it use only the relevant tools, runs it on a cheaper model like Haiku, and waits for a summary back. The main thread never sees the raw research.

In the Claude Agent SDK this is the Task tool. In code, the call looks like this:

1> spawn_subagent(
2    role="research",
3    model="claude-haiku-4-5",
4    goal="find every API endpoint in src/ that lacks auth",
5    tools=["grep", "read_file"],
6    return_format="summary + file list"
7  )
8
9▲ subagent_a  starting in isolated context…
10  - scanning 142 files
11  - 11 endpoints flagged
12✓ done · returned 1.2K-token summary, full transcript not loaded into parent

The subagent’s return_format field matters more than any prompt. If you let subagents return free-form text, the orchestrator drowns.

Force structured returns - a summary string plus a list of facts, a list of files, a list of findings. The orchestrator then composes those structured returns into the next decision without reading the noise.

05. Design the orchestrator. Plans, delegates, never executes.

The orchestrator is the agent at the top of the tree. Its only job is to plan, delegate, and gather. It does not write code, run queries, or talk to APIs directly — if it does, it pollutes its own context with details that belong inside subagents. The orchestrator stays light so it can keep the whole task in view.

A working orchestrator has three loops nested inside the main agent loop:

1def orchestrator_loop(goal):
2    plan = make_plan(goal)                  # step 1: PLAN
3    results = []
4
5    for step in plan:
6        subagent = pick_specialist(step)    # step 2: DELEGATE
7        result   = run_subagent(subagent, step)
8        results.append(result)
9
10        if plan_needs_revision(result):
11            plan = revise_plan(plan, result) # adapt mid-run
12
13    return synthesize(results)             # step 3: GATHER

The orchestrator is usually the most capable model (Opus, in 2026). The subagents under it are often Sonnet or Haiku.

This is where the cost math works: the expensive model runs the plan, the cheap models run the work. A crew on this pattern can run 5–10x the tasks of a single-Opus setup at lower total cost.

06. Build a shared task list.

Without shared state, your “team” is parallel solo work. Two subagents start on the same step. One finishes a step nobody knows about. The orchestrator forgets what was assigned to whom. The fix is a single shared task list that every agent reads from and writes to - not as a creative document, but as a structured file.

1{
2  "goal": "Add auth to all unprotected endpoints",
3  "tasks": [
4    {
5      "id": "t1",
6      "description": "Find unprotected endpoints",
7      "status": "done",
8      "assignee": "subagent_a",
9      "result": "11 endpoints in src/routes/*.ts"
10    },
11    {
12      "id": "t2",
13      "description": "Add JWT middleware to each",
14      "status": "in_progress",
15      "assignee": "subagent_b",
16      "depends_on": ["t1"]
17    },
18    {
19      "id": "t3",
20      "description": "Write integration tests",
21      "status": "pending",
22      "assignee": null,
23      "depends_on": ["t2"]
24    }
25  ]
26}

Three things make this work that pure memory does not: explicit assignees mean two agents never pick the same task.

Explicit dependencies stop subagents from running steps whose inputs are not ready. Explicit status lets the orchestrator check progress without reasoning over transcripts.

**

Part 3 · The Production Crew

07. Add memory, durability, and sandboxing.

A demo agent forgets the moment the session ends. A production crew remembers what it should and forgets what it should. The three things to wire in, in order:

• Memory - a structured store the agent writes to deliberately. Not the conversation log; that is too noisy. A separate file or DB row per fact, decision, or convention worth keeping. memory/decisions.md, memory/conventions.md, memory/known_failures.md. The next session loads these explicitly.
• Durability - every step writes its action and result to disk before moving on. If the process crashes mid-loop, the next start reads the trajectory and resumes. Without this, a 50-step task that fails at step 47 starts from zero. This is the single most ignored detail in agent engineering.
• Sandboxing - agents run in a container or restricted subprocess with no access to anything not explicitly granted. No reading your home directory because someone’s prompt drifted. No writing outside the project folder. The sandbox is the wall between “agent that helps you” and “agent that costs you something.”

1# Decisions log
2
3## 2026-05-22
4- chose JWT over session cookies (mobile clients drive this)
5- auth lives in src/auth/, never duplicated per route
6- all endpoints under /api/admin require role check, not just login
7
8## 2026-05-29
9- adopted shared task list pattern (state/tasks.json)
10- orchestrator on Opus, subagents on Sonnet/Haiku
11- max_iterations = 30 per loop, hard cap enforced by harness

08. Wire evals and trajectory checks.

Most teams change their agent system and have no idea whether the change helped or hurt. They run it twice on a familiar task, it “feels better,” and they ship. Six weeks later they have a system that performs worse than the original on cases they forgot to check. Evals fix this.

Three layers of measurement that a production crew needs:

• Eval set - 20–100 frozen tasks with known good outputs. Run them after every meaningful change. Track pass rate over time.
• Trajectory checks - not just “did it finish,” but “did it call the right tools in roughly the right order.” A correct answer through a wrong path is a future regression.
• CI regression gates - the eval set runs automatically on PRs. If pass rate drops below a threshold, the PR is blocked. Same discipline as code tests.

1{
2  "id": "auth_refactor_001",
3  "input": "Add JWT auth to all unprotected /api/* endpoints",
4  "expected": {
5    "endpoints_protected": 11,
6    "files_touched": ["src/auth/jwt.ts", "src/routes/*.ts"],
7    "tests_added": "at least one per endpoint",
8    "no_changes_to": ["src/db/", "src/email/"]
9  },
10  "trajectory_must_include": [
11    "grep_for_unprotected_endpoints",
12    "read_existing_auth_module",
13    "apply_middleware_to_each_endpoint",
14    "run_tests"
15  ],
16  "max_iterations": 30
17}

The trajectory_must_include list is the secret weapon. Two agents can produce the same answer through wildly different paths - one safe, one one bad approval away from disaster.

Trajectory checks catch the unsafe path before it ships. Pair this with anonymous logging of real production runs and you build the eval set automatically from cases that already happened.

09. Ship with permissions and human checkpoints.

The last stage is the one that lets you sleep at night. A permissions file declares what the crew can do without asking, what needs human approval, and what is never allowed at all. The harness reads this file before every tool call.

The model cannot bypass it because the rule lives outside the model.

1## Always allowed (no approval needed)
2- read any file in the project directory
3- run tests
4- create branches
5- write to memory/ and skills/ directories
6- create draft pull requests
7
8## Requires approval
9- merge pull requests
10- deploy to any environment
11- delete files outside of memory/working/
12- install new dependencies
13- modify CI/CD configuration
14
15## Never allowed
16- force push to main, production, or staging
17- access secrets or credentials directly
18- send HTTP requests not in the approved domains list
19- modify permissions.md (only humans edit this file)
20- disable or bypass pre_tool_call hooks
21
22## Approved external domains
23- api.github.com
24- registry.npmjs.org
25- pypi.org

This file is the single most important artifact in the whole production stack. It is the difference between an agent crew you can leave running overnight and one you have to babysit. Write it before you spawn your first subagent, not after the first incident.

§ The mistakes that keep crews stuck in demo mode

• No real loop. A long prompt with “think step by step” is not an agent. No iteration, no observation, no recovery.
• Free-form context. Stuffing the window with everything you have. The model gets distracted and misses what mattered.
• Untyped tools. Free-text arguments and no preconditions. The model guesses, sometimes wrong, sometimes destructively.
• Subagents without isolation. When subagents share context with the orchestrator, you get five chatty agents instead of one focused team.
• Orchestrator that executes. The lead agent writing code itself, drowning in details its specialists should be handling.
• No shared task list. “Team” collapses into parallel solo work with duplicated effort.
• No durability. A 50-step task crashes at step 47 and starts over from scratch. Money burned, time wasted.
• No evals. “Better” is a vibe. Six weeks later you cannot explain why anything works or fails.
• No permissions file. Speed without a safety net. One bad approval away from a real incident.

Conclusion:

A team of AI agents is not more model. It is more structure.

Everything in this roadmap is plumbing. None of it is exotic. None of it requires a frontier model the rest of the world does not have. The teams shipping real multi-agent systems in 2026 are using the same models everyone else can use. What they have that demo-stuck teams do not is nine stages of structure between the agents.

If you have read this far and tried multi-agent setups before, the answer to “why did it not work” is probably in here. Pick the one stage you skipped - usually shared state or permissions - and add it tomorrow. Then the next. A crew that ships is built in stages, not in one weekend of vibes.