How We Structured a 5-Agent AI Team for Production (30 Days, Real Costs, What Broke)

Most "AI agent team" tutorials stop at the demo. One agent calls another, they chat, the notebook prints a happy answer, and everyone claps. Then you put it in front of real work for a month and the structure you picked on day one decides whether you sleep.

We ran a 5-agent team in production for 30 days. This is the org chart that survived, the one that didn't, the actual dollar figures, and the failures nobody warns you about.

The team we started with (and why it broke)

Our first instinct was the obvious one: one "manager" agent that receives every task and delegates to four "workers." Clean on a whiteboard. A disaster in practice.

The manager became a single point of failure and a single point of cost. Every task round-tripped through it twice — once to plan, once to review — so it burned tokens on work it wasn't doing. When it misread a task, all four workers inherited the mistake. And because everything funneled through one context window, that window filled up and the manager started forgetting the earlier half of long jobs.

Lesson 1: a central manager agent is a bottleneck, not an org chart. It concentrates cost, failure, and context limits in the one place you can least afford them.

One manager agent = one single point of cost, failure, and context overflow.

The structure that survived

We flattened it. Instead of a manager routing everything, we gave each agent a narrow charter and a deterministic router — plain code, not an LLM — deciding which agent gets a task based on its type.

The five roles:

1. Intake — normalizes the incoming request into a structured JSON task. No reasoning, just shape.
2. Planner — turns a task into an ordered list of steps. Only runs for multi-step work; single-step tasks skip it entirely.
3. Executor — does the actual tool calls. The only agent allowed to touch external systems.
4. Verifier — checks the executor's output against the task, independent of the executor. This one earned its keep (more below).
5. Scribe — writes the final structured result and the human-readable summary.

The router is boring on purpose. A single-step task goes Intake → Executor → Verifier → Scribe and never wakes the Planner. That "boring" saved roughly a third of our token spend versus the manager design, because agents that don't need to run don't run.

Lesson 2: replace the manager LLM with a deterministic router. Routing is an if statement, not a reasoning problem. Spending model tokens to decide "which agent" is paying premium prices for work a switch statement does for free.

Narrow charters, a deterministic router, and agents that don't need to run don't run.

The failure nobody warns you about: confident wrong answers

The most dangerous agent isn't the one that crashes. It's the one that finishes, reports success, and is wrong.

Twice in the first week our Executor completed a task incorrectly and marked it done. No error, no exception — just a wrong result with a green checkmark. If we'd trusted the checkmark, that garbage flows straight downstream.

The fix is the Verifier, and the rule that makes it work: the Verifier must be independent of the Executor. Different prompt, and where possible a deterministic check instead of a second opinion — compare against sample ground truth, re-run a calculation in plain code, validate the output against a JSON schema. An agent grading its own homework catches nothing.

Lesson 3: every agent task needs a verification step it didn't produce itself. Free-form "looks good to me" is not verification. Structured output plus an independent check is.

An agent grading its own homework catches nothing. Verify independently.

The costs, actually

Here's the part the tutorials skip.

• Month one bill ran ~4x our estimate — and it wasn't the model being expensive. It was retry loops. An agent hits a transient failure, retries, fails again, retries again, no ceiling. Each retry is a full billable inference. One stuck task quietly ran up hundreds of calls overnight.
• The fix was two lines of policy: exponential backoff and a hard max-retry count. Table stakes, and we learned it the expensive way.
• We also put a hard token budget per task. Each agent gets a ceiling; hit it and the task fails loudly instead of grinding forever. A failed task is cheap. A runaway task is not.

Lesson 4: cost control is a design requirement, not a dashboard you check later. Retry caps and per-task token budgets go in before launch, not after the first scary invoice.

Month one ran 4x — retry loops, no ceiling. The fix: caps wired in from day one.

What we'd never do again

• A manager agent. Covered above. Flatten it.
• Free-form text between agents. Early on, agents passed prose to each other and the next agent had to re-parse it. Every handoff was a chance to misread. We moved to JSON schemas for every inter-agent message. Structured or it doesn't ship.
• Trusting a green checkmark. An agent reporting success is a claim, not a fact. Verify independently.
• Launching without step-level traces. When something broke, "the team failed" told us nothing. Per-step execution traces turned three-hour debugging sessions into three-minute ones. Add them before you need them, because you'll need them at 2am.

The shape that works

Strip it down and the surviving structure is simple:

The surviving shape: narrow agents, a code router, independent verification, cost ceilings.

• Narrow agents, not one god-agent. Specialized roles run more reliably than one LLM doing everything.
• A deterministic router, not a manager LLM. Routing is code.
• Independent verification on every task. The model is one component; the harness around it — verification, budgets, traces, structured output — is the rest of the system.
• Cost ceilings wired in from day one. Retry caps and token budgets before launch.

We got tired of rebuilding this harness for every project, so we packaged it — the router, the verification loop, the per-task budgets, the traces — into one-team. If you're structuring a multi-agent team and don't want to relearn Lesson 4 the way we did, that's what it's for.

The model was never the hard part. The org chart was.

---

Have you run agent teams in production? What did your structure look like on day 30 versus day one? Curious where others landed.