How to build an AI agent team that produces one deliverable instead of five transcripts

Five capable agents with no structure produce five transcripts, not one deliverable

Building one AI agent stopped being hard a while ago. Wire a model to a few tools, write its instructions, and it can research a market or fix a failing test on its own. The trouble starts at agent number two. Once work has to travel between agents, the job is no longer prompt engineering. It becomes org design: who owns what, who reports to whom, and where results land. It also covers what the team remembers next week, and what any of it is allowed to touch.

The naive version fails the same way every time. Put five agents in one shared chat, give them a goal, and they will praise each other's answers while the token bill grows. I have seen it often enough to treat it as a rule. A team of agents with no structure turns into noise.

The most complete do-it-yourself (DIY) walkthrough I have read is this OpenClaw tutorial on building an AI agent team. It sets up one coordinator, five specialists, and Discord as the place they all talk. Then it keeps going into the parts most tutorials skip: cost routing, security, and keeping the team alive overnight. What follows is that build, in the order I would hire humans. I add my own opinions where they differ. At the end I cover what changes when you hire the finished shape instead of assembling it.

Pick roles the way you would write job descriptions

Roles come before agents. Decide what jobs exist before you configure anything. A starter team that covers most delivery work is one coordinator over four specialists: a researcher, a builder, a reviewer, and a writer. The same structure works whether the team ships code, content, or support answers. Only the specialist titles change.

What defines a role is its refusals, not its abilities. Any capable model can do a bit of everything, and that is the problem. A reviewer is useful because it never edits what it reviews, so its findings stay findings. A coordinator is useful because it never does the work itself, so it always has attention left to route. An analyst is useful because it asks its clarifying questions before writing a line. A role with no boundary is only a prompt. A team of roles with no boundaries is one agent copied five times.

Two smaller decisions matter more than you would expect. First, name the agents like people rather than like services. The OpenClaw guide uses names such as Scout and Maya instead of research-agent-01, and it is right. Names make delegation targets clear and logs easy to read. Second, start with three roles, not eight. Every agent you add is one more connection the coordinator has to manage. Hire a new role when you keep making the same hand-off by hand. That hand-off clearly belongs to someone.

The coordinator delegates, and that is the whole job

You talk to one agent. It reads a plain-language request, decides which specialists the task needs, and hands the pieces down. It watches progress and gives you one answer at the end. Raw specialist output stays in the background. You get the deliverable.

The failure mode is drift. A coordinator that starts researching or coding "just this once" becomes an overloaded generalist with a fancy title, and the specialists sit idle. So put the refusal in its role file in plain words. This agent delegates, monitors, and combines results. It never does the work itself. The tutorial gives its coordinator a short decision guide for triage, covering which task goes to whom and what counts as done. That is the right amount of process to write down.

Then cap everything, because a delegation graph with no limits gets expensive fast. Cap how many pieces of work the coordinator hands out per turn. Cap how deep a chain of hand-offs can run. Cap review cycles as well. Builder to reviewer and back is useful for about three passes. After that the loop should go to a human instead of repeating forever. Each cap looks pointless until the day it saves you, and that day comes.

Bounded channels beat a group chat

Communication is where DIY teams either get disciplined or fall apart. The OpenClaw setup gives every agent three channels of its own: one for output, one for logs, one for memory. On top of that sit shared channels for decisions, learnings, and agent-to-agent chatter. Discord already solved search, threading, storage, and phone notifications. Borrowing a chat platform beats writing your own coordination database, and I think that trade is obvious. A database you write yourself works on day ninety, not on day one. Plain, well-tested infrastructure wins.

The part I would defend hardest is the status vocabulary. Agents report in three words: done, stuck, or handoff. The narrow vocabulary is the point. The DIY community keeps arguing about this. One side wants strict procedural guardrails. The other side wants free-form agent collaboration. You can read the argument in threads like this one about a nine-agent team. Everything I have run says bounded wins. Free-form chatter drifts into agreement spirals, while bounded messages force every exchange to carry a decision. Reach needs the same limit. An agent should talk to its manager and its own reports, not sideways to whoever seems interesting. If any agent can message any other, you have rebuilt the group chat with extra steps.

Memory is what makes week two cheaper than week one

A context window is scratch space. It disappears when the run ends. A team built on scratch space starts every morning by learning the basics again: which repository, which conventions, what the client decided last Tuesday. The fix is two layers of durable memory with different audiences.

The shared layer belongs to the team: decisions made, conventions adopted, repository facts, client context, and lessons that cost something to learn. Every agent reads it on spawn, so a specialist starts a task already knowing what the team knows. The private layer belongs to each agent: its own working state, half-finished pipelines, notes that would be noise to anyone else. The OpenClaw build does this with shared memory channels plus a private markdown file per agent. It reports that agents get measurably better at recurring work, because each run inherits what the last one learned.

Three rules keep memory useful instead of letting it fill with things nobody needs. Write facts, not transcripts. One line saying the default branch is main beats a pasted conversation. Cap the size, and delete old entries before you write new ones, so stale facts drop out instead of piling up. And keep every entry easy to inspect, because sooner or later an agent will remember something wrong. Fixing it should be a one-line edit, not a long search.

Route models by role, or the invoice becomes the architecture

Running every agent on a frontier model is the most expensive way to avoid thinking about roles. Two jobs genuinely earn premium reasoning. The coordinator earns it because routing mistakes spoil everything downstream. The builder earns it because bad code costs more to find than to write. Research, monitoring, and first drafts run fine on mid-tier models, since a human or a reviewer checks that work anyway. The OpenClaw guide estimated roughly 80 percent savings from this split alone when it was published. My own experience says that rough size is right.

The same logic applies inside a single role. Reasoning effort is a setting you choose per task. A reviewer thinking hard about a risky diff is money well spent. The same reviewer thinking hard about a README is not.

Beginners always ask about cost. This is not free. You pay per token, you pay for a machine that stays on, and you pay in evenings spent on plumbing. What a well-routed team buys you is a cost per deliverable low enough to compare seriously against human hours. Cheap is achievable. Free is not.

Always on is what separates a team from a demo

A team that only works while your laptop lid is open is a demo. The real version runs on infrastructure that stays up. Three mechanisms keep it moving while you are away. Heartbeats check every half hour that each agent is alive and that work in progress is moving. Scheduled jobs do the recurring work nobody should be prompting by hand. That means a morning brief compiled before you wake up, or a competitor scan every few hours. Event triggers respond to the world, such as a mention, a threshold crossed, or an error in the logs.

This is the step where a DIY build quietly becomes an operations job. Process supervision, restarts after crashes, a server someone patches, alerts when an agent goes silent. None of it is hard, all of it is permanent, and the tutorial deserves credit for saying so out loud. The payoff is real. You stop driving the team and start reviewing its output, which is what the whole build is for.

Deny by default, then scale with disposable workers

Security for an agent team is one principle applied everywhere: deny by default, allow by exception. No agent gets shell access except the builder, and the builder gets an allowlist. Node, git, and the package manager, not a blank terminal. Credentials live in environment variables, never in config files that end up committed. Each agent's session is isolated, so a compromised specialist cannot read the coordinator's memory or a teammate's context. And somebody has to read the audit trail. Review the session logs once a week and look for commands nobody expected. It is cheap, and it catches problems you would otherwise find much later.

Scaling is only safe after that hardening. The tutorial's scaling move is worth copying: interns. Not every job deserves a permanent hire. Temporary agents start for one task and run in parallel, ten of them summarizing ten articles at once. Then they get deleted. You get horizontal scale without a standing roster to maintain. Interns stay safe because they inherit the same deny-by-default posture as everyone else, plus a cleanup step that actually runs.

Run one real deliverable through the team before you grow it

Before adding a sixth role, trace one real task from start to finish. Say the request is to research three competitors and ship a landing page. The coordinator splits it up. The researcher pulls competitor patterns and the writer turns findings into copy. The builder assembles the page, and the reviewer checks it for responsiveness and accessibility. The coordinator hands you one finished thing, and the working-out stays in the background channels. One request, four specialists, one answer is the plainest example of AI orchestration I can give you. If that trace runs clean, the team is real.

When it stalls, the fixes are ordinary, and that is good news. A silent agent means checking status and respawning it, not redesigning the system. Weak output almost always traces to a vague role file, context that never got passed, or a model tier below the job. When everything works but slowly, the cause is usually the coordinator checking in too often. Raise specialist autonomy and cut the check-ins. Diagnose in that order and you will rarely need a fourth theory.

How this shape comes prebuilt in Aldena

I went through this build enough times that I eventually made it the product, so treat this section as an ad. Everything above maps onto something you configure in Aldena rather than build yourself.

You hire roles instead of writing them. The agent roster ships a set of named roles with the refusals already built in. Vera the analyst asks her clarifying round before writing a spec. Magnus the engineering manager delegates the build and opens the pull request but never writes code. Argus the reviewer reports findings and never edits. When the roster runs out, you define a custom agent once. Any room can then hire its own copy. A room is one workspace with its own team and its own server.

The coordinator layer is the org chart, a canvas that holds the reporting lines. You drag agents onto it and draw a line from each one to its manager. That wiring is the whole orchestration setup. Reach follows the lines. An agent can hand work only to its direct reports and report only to its own manager, never sideways. The caps I told you to build come installed. An agent can hand out only a few pieces of work per turn. A chain of hand-offs can only run so deep before it stops. The room's one checkout is protected by a role instruction rather than a cap. Delivery managers hand work to one report at a time, so nobody fights over that checkout. The lines light up while work moves along them, so you watch a misrouted hand-off happen instead of reconstructing it from logs.

Memory comes in the same two layers, with the caps enforced. Each agent keeps a limited number of private entries, each room keeps a larger shared set, and every entry is short on purpose. A Memory tab in room settings lists every entry with its author, so a wrong fact is a one-line correction. Details are on the agent memory page. Model routing is per agent too. You pick each agent's model and reasoning effort one by one. Usage is metered against one prepaid balance, at the rates published on the model pricing page.

The always-on problem goes away because a team lives in an isolated room with a dedicated server that stays up. That server is billed by the hour, at a few cents an hour. The current sizes and rates are on the pricing page. Inside the room, agents clone the repository, run commands, and execute the test suite. Agents schedule their own recurring work, and a Scheduled tasks tab shows everything on the books with an off switch per task.

And the security posture is the approval gate, a rule per tool that decides what may run without you. Every tool an agent can call runs under a policy you set per room: allow, ask, or deny. On ask, the run pauses and shows you the exact call before it happens. Asking you a question is the one tool that can never be switched off. Engineering work ends at a fixed gate. The work arrives as an open pull request. Merging is a gated tool like any other write, and the delivery role is told never to merge its own request. Finished output lands where your team already works, in whichever accounts that room is connected to. GitHub, Jira, and Google Drive, to name three.

There is a wider argument for running agents this way, as staff under a control plane rather than scripts under a scheduler. I make it separately in the AI workforce platform post.

Build it if you want the lessons, hire it if you want the output

The DIY path is legitimate. Build it if you want to own every layer, learn how coordination actually fails, or work under constraints no product anticipates. The OpenClaw tutorial is the best free curriculum I know. A framework can carry some of the plumbing if you would rather not start from raw loops. I compare those options in the AI agent frameworks post. The coordination patterns go deeper than one article, and I work through them in AI agent orchestration.

But be honest about what you are signing up for. The agents are the easy 20 percent. The channels, the memory cleanup, the model routing, the heartbeats, the permission matrix, and the weekly log review are the other 80 percent. They recur forever.

Either way, the first step is identical. Pick three roles. Give them boundaries stated as refusals. Run one deliverable you actually need through the team, and judge the result by the hand-offs, not by the demo. In Aldena that first step takes a few minutes. Open a room, hire an analyst, a developer, and a reviewer. Then hand the top of the chart one real ticket. Grow the team the way you would grow a human one, only when the work asks for it.