A Team of 6 AI Agents: How We Build Multi-Agent Systems and Where We Hit Snags
One bot can’t handle a complex process. It picks up a five-step task, keeps the first two steps in mind, loses the thread by the third, starts making things up on the fourth, and delivers a result on the fifth that you end up redoing by hand. We hit this wall over and over until we split the work across several agents with clear roles. Here’s how our team of six agents is structured - and where we got burned.
Why six and not one
A complex task isn’t one big request - it’s a chain of different operations. Find data, write a draft, verify facts, record the result in a system, assess whether it’s good enough. Each operation demands its own skill set, its own tools, and its own focus.
When all of that lands on a single model, it holds all the roles in context at once. Researcher instructions get tangled with editor instructions, intermediate data clogs the window, and by the end of the chain the agent is working with a cluttered head. Quality drops not because the model is weak - we just made it do five things at once.
We build multi-agent systems on the Hermes engine - an agent framework with an orchestrator and subagents. Each agent has its own set of tools, its own access keys, and its own memory. Nobody pokes into someone else’s territory. Standard division of labor, only with specialized agents instead of people.
Could you get by with two or three? Sometimes yes. But as soon as a process includes quality checks, writing to external systems, and final review, roles start conflicting inside a single agent. The reviewer shouldn’t be rewriting, the writer shouldn’t be touching the database, and the one talking to the user shouldn’t drown in technical details. Six roles isn’t a goal in itself - it’s the minimum where each step gets a clean slate.
Who does what
In our working configuration we have six agents: one orchestrator and five specialists.
The Orchestrator holds the conversation with the user and understands the task as a whole. It breaks the task into steps, hands them out to specialists, and assembles the result. It doesn’t do the “grunt work” itself - no searching, no writing, no hitting APIs. Its job is to think about the task as a whole and manage the others. This is the only agent that sees the full picture.
The Researcher finds and gathers information. It goes through sources, pulls out facts, and checks that the data doesn’t contradict itself. It hands the orchestrator not a raw page dump, but a structured body of facts.
The Writer turns the facts into text or material in the needed format. Article, post, email, description - its job is to shape the content to fit the format. It doesn’t verify facts; it works with what the Researcher gathered.
The Editor-Reviewer catches the Writer’s mistakes. Fact-checking, quality, logic, tone. It’s a separate agent specifically because writers are bad at spotting their own errors - same story as with humans. A fresh eye with a clean context finds what the author missed.
The Integrator writes the result to wherever it needs to go. Hits APIs, puts a record in the database, sends it to the right service. These are the team’s hands - the agent that touches external systems.
The Evaluator is the final check. It looks at the finished result and compares it against the criteria: does it match what the user asked for, are there any obvious failures. If something’s off, the task goes back for rework, not to the user. The last filter before delivery.
How they hand off work
The Orchestrator is the single decision point. It receives the task, breaks it into steps, and hands them to specialists. From there, agents pass work down the chain: Researcher gathers - Writer formats - Editor reviews - Integrator records - Evaluator confirms. We call this transfer a handoff.
There’s a shared task state that agents refer to: what’s already done, what’s at which step, what result is expected at the end. At the same time, each agent has its own clean context. The Researcher doesn’t see the Writer’s draft; the Writer doesn’t need the Integrator’s logs. Each one gets exactly what it needs for its step, and nothing extra.
That’s the whole point. Not one agent with bloated memory, but several with a narrow focus and strict result passing between them.
The Orchestrator doesn’t launch all six agents every time. If the task is simple, it can take a short path: Researcher and Writer, no full pipeline. Who gets called is its call - it looks at the task and assembles the chain for it. So six agents isn’t a rigid pipeline that everything gets pushed through the same way - it’s a set of roles the Orchestrator uses to build the right route each time.
The pitfalls we hit
It sounds clean, but the first builds worked poorly. Here are five problems we stepped on, and what we did about each.
Context overflow. The shared context bloated. One agent’s results bled into another’s, the window filled up, agents lost focus and started confusing what was wanted of them. The fix - strictly cut memory by role. Each agent only sees its own slice: the Researcher gets the request and sources, the Writer gets the gathered facts, and so on down the chain. No common pot where everything gets dumped.
Broken handoffs. Details got lost in transfers between agents. The Writer would hand off a result as free-form text, the Editor would interpret it differently, and the output wasn’t what was intended. The fix - a strict transfer format. An agent doesn’t hand off “here’s what I wrote, figure it out” - it passes a structured result with fields the next agent will definitely understand. We eliminated free-form text between agents.
Token cost. Six agents consume more than one. Obvious, but the early runs were surprising. The fix - don’t put an expensive model on every role. Simple tasks like formatting or distributing steps go to cheap models, while heavy reasoning goes to expensive ones. Plus we cache what repeats, so we don’t pay twice for the same thing.
Duplicate work. Agents were doing the same thing or going in circles: the Researcher gathered data the Writer then gathered again, the Evaluator sent tasks back for rework without a clear reason. The fix - clear ownership boundaries. Each agent knows where its zone starts and where it ends, and the Orchestrator stays the single point that decides who does what next. No freelancing in someone else’s territory.
Hard to debug. When something broke, it wasn’t clear which of the six was at fault. The result was bad, but which step it went wrong at was a mystery. The fix - log every step and every Orchestrator decision. We keep a trace across the full chain: what the agent received as input, what it handed off as output, why the Orchestrator sent the task there. With a full trail, diagnosing a failure takes minutes, not hours.
What this gives in practice
This architecture isn’t theory - it runs in our products.
An AI Secretary handles document management by voice. A person dictates an instruction, and the agent team parses it, formats the needed document, checks it, and puts it in the system. One bot can’t do that - too many different steps from parsing the meaning to writing to the database.
The AI Content Factory is a pipeline of agents that turns a news item into a ready set of materials. The Researcher gathers context around the news, the Writer prepares the article, the Editor proofreads it, the article spawns posts for different platforms, and the Integrator prepares banners. News item in, finished package out. Without division into roles, this pipeline would choke at the very first link.
Where to start
If you have a process that one bot can’t handle - it’s a candidate for a multi-agent system. The sign is simple: the task consists of steps that differ in nature, and each one needs its own focus.
The right starting point is not six agents at once, but breaking the process into roles. Where is the data gathering, where is the creative part, where is the review, where is the write-to-system step. Once the roles are clear, the architecture assembles itself.
We build these systems for specific tasks - from process breakdown to a working agent pipeline. Describe what one bot can’t handle for you, and we’ll look at how to break it down: puramind.ai#contacts.