How to build a whole team of AI agents to automate a business

The scaling mistake

Whoever gets their first agent working immediately has the same idea: make ten of them, and let them run the whole business.

Then the predictable happens. Ten agents with badly defined scope produce a system where nobody knows who did what, the cost triples, and one's error becomes another's input with no verification in between. You did not build a team. You built an expensive game of telephone.

A team of agents works for the same reasons a team of people works: a clear role, a defined deliverable, someone reviewing and someone answering for the result.

Split by role, not by tool

The first wrong instinct is to split by technology — "the database agent", "the email agent". That produces agents that do not know what they are doing, only how.

Split it the way you would split a human team, by responsibility over a stage of the process. In a services business, for example:

• Triage. Receives everything that comes in, classifies it, identifies the customer, decides where it goes. Reads only, never writes.
• Support. Answers operational questions within policy, queries systems, logs tickets.
• Quoting. Builds the proposal from the price table and the rules, with a defined discount ceiling.
• Collections. Tracks due dates, sends reminders on the approved schedule, escalates whatever passed the limit.
• Content. Produces marketing material out of what the operation generated.
• Auditor. Never talks to a customer. Reads a sample of what the others did, against the policy, and flags deviation.

Notice the last one. It is the one almost everybody forgets and the one that most pays for itself.

The orchestrator is code, not an agent

The temptation is to build a "manager agent" that decides which agent to call. It works in the demo and is expensive and unpredictable in production.

What works: the flow is deterministic code; the agents are the steps. A clear rule decides the routing — if it is a question about an order, it goes to support; if it is a request for a proposal, it goes to quoting. An if is cheaper, faster and more auditable than a model reasoning about obvious routing.

Let the model decide where the decision is genuinely ambiguous. Everything else is flow.

Memory: three layers

An agent with no memory repeats questions and irritates customers. An agent with too much memory leaks context between cases and spends a fortune. Three layers solve it:

Short — the current case, inside the context window. Discarded on closing.

Shared — the state of the business: customer, order, history, tickets. This is not "AI memory", it is your database. Agents query it through a tool, with permissions specific to the role.

Long — what was learned: resolved cases, approved answers, updated policy. It lives in searchable documents, editable by people in operations without going through a developer.

The rule that avoids most of the problems: each agent sees only what its role requires. It holds for people and it holds here, for the same reasons.

Cross-review is what saves you

Compounding error is the cruel arithmetic of multi-agent systems: five steps at 95% accuracy each land around 77% at the end.

What brings that back to an acceptable level:

• Verification by rule, not by model, whenever possible. Value within range, valid tax ID, deadline within the table, required field filled in. Cheap and deterministic.
• A second look by sampling. An auditor agent reviewing part of the output, against written criteria.
• A human stopping point on irreversible steps. Always.

What stays with people

Write this list before switching anything on:

• Exceptions. Anything outside the expected goes to a person, with no creative workaround attempted.
• An angry customer. No exceptions. A complaint mentioning a consumer agency or a lawyer escalates immediately.
• Money above the ceiling. Discounts, refunds, cancellations, payments.
• Anything with legal effect.
• The policy. Who decides what the system may say and do is a person, and that gets reviewed periodically.

A system of agents is judged by what it refuses to do, not by what it manages to do. Refusing correctly is the hardest behaviour to design.

Start with two

Do not build the whole team. Build triage + one executor, measure for a month, and only then add the third.

Each new agent raises the cost linearly and the complexity far less gently. Three well-tuned agents deliver more than ten improvised ones — and that is the difference between a system the operation trusts and one it quietly works around.