---
title: "How to Build an Agent Team That Is Not Just One Agent Wearing Three Hats"
description: "Everyone is building agent teams now, and most of them are one prompt with role labels. Here is what actually separates a team of agents from an expensive way to call the same model repeatedly, and how to staff one."
image: "https://foundrysoft.co/api/og?type=article&title=How+to+Build+an+Agent+Team+That+Is+Not+Just+One+Agent+Wearing+Three+Hats&cat=Insights+%2F%2F+Architecture&rt=12+min+read&au=Varun+Raj+Manoharan&dt=2026-08-30"
url: "https://foundrysoft.co/blog/building-your-own-agent-team"
---

Insights // Architecture 2026-08-30 12 min read

# How to Build an Agent Team That Is Not Just One Agent Wearing Three Hats

Everyone is building agent teams now, and most of them are one prompt with role labels. Here is what actually separates a team of agents from an expensive way to call the same model repeatedly, and how to staff one.

![Varun Raj Manoharan](https://foundrysoft.co/images/about/founder.webp)

Varun Raj Manoharan Founder & Principal Engineer

AI Agent Teams Multi-Agent Systems Agentic AI Agent Orchestration Enterprise AI

## Key takeaways

-   A role label in a prompt is not a team member. The test is whether each agent has different tools, different data access, and a different definition of done.
-   Teams earn their cost when subtasks genuinely need isolation: separate context, separate permissions, or genuine parallelism. Otherwise you are paying several times over for one agent's work.
-   Shared context is the hard problem, not orchestration. Agents that agree on what a customer or an order means produce coherent output; ones that do not produce confident contradictions.
-   Give every agent in the team its own identity and its own scoped credential. A team sharing one service account is one agent with extra steps and a larger blast radius.

Somebody showed me an agent team last month. Five agents: a researcher, a planner, a writer, a critic, and a coordinator. It worked, sort of, and cost about nine times what a single agent cost for the same output.

When we pulled it apart, all five agents had the same tools, the same data access, and the same model. The only difference between them was a sentence at the top of each prompt saying what they were. It was one agent, called five times, with the outputs of each pass fed into the next.

That is not a team. It is a very expensive chain of thought.

Agent teams are the phrase of this season, helped along by tools that put agents in your chat channels as named members, and by every framework shipping a supervisor pattern. Some of the enthusiasm is warranted. Most of the implementations I look at would work better and cost a fifth as much as one agent with a good loop.

Here is how I try to tell the difference, and how to build one when it is genuinely the right call.

## The test for whether you have a team

Three questions, and you want a yes to at least one.

**Do the agents have different tools?** Not different instructions about which tools to prefer. Actually different toolboxes. If the researcher can search and the writer cannot, and the writer can publish and the researcher cannot, you have specialisation with a boundary. If everyone has everything, the roles are decorative.

**Do they have different data access?** This is the strongest reason to split, and the most overlooked. An agent that reads untrusted external content should not be the same agent holding write credentials to your internal systems. Splitting them means an injection in the reader lands in a process that cannot do anything with it. That is a real architectural boundary and it justifies the extra cost on its own.

**Do they run at the same time on independent work?** Genuine parallelism, where four agents each take a different document and none of them needs the others' results. This is where teams pay off on wall-clock time.

If the answer to all three is no, you have a single agent and a prompt sequence, and you should build it that way. It will be cheaper, easier to debug, and easier to explain to whoever asks why the bill went up.

## Why the naive team costs so much more

The arithmetic catches people out, so it is worth spelling out.

A single agent working a twelve-step task carries its context forward. Each step adds to the window, and each model call re-sends what has accumulated. That is already superlinear, which is why a twelve-step task does not cost twelve times a one-step task.

Now split it across five agents with a coordinator. The coordinator holds its own context and grows it. Each specialist gets briefed, which means the coordinator writes a summary, which is a model call. Each specialist reports back, which the coordinator reads and adds to its context. Handoffs between specialists mean the same information gets serialised, summarised, and re-read several times.

You have not just multiplied the calls. You have added a translation layer between every pair of participants, and translation is where both the tokens and the errors accumulate.

None of that is an argument against teams. It is an argument for having a reason.

## Shared context is the actual hard part

Orchestration gets all the attention because it is the part frameworks solve. Supervisor patterns, handoff primitives, routing. Those are fine and largely a solved problem.

What is not solved is agents agreeing on what things mean.

Your CRM has a notion of customer. Your billing system has a different one. Your support tool has a third, and it includes people who never bought anything. A human moving between those systems reconciles this without noticing. Two agents, each grounded in a different system, will both be confident and will disagree, and the disagreement will not surface as an error. It will surface as an output that is subtly wrong in a way that reads fine.

The mitigations are unglamorous. Define the shared entities once, in a place both agents read from, rather than letting each one infer them from whatever system it happens to be looking at. Pass structured references rather than prose summaries between agents, so an order is an identifier and not a description that the next agent has to re-resolve. And when two agents disagree, make that a detectable event rather than something the coordinator smooths over, because a detected disagreement is a useful signal and a smoothed one is a silent failure.

This is the part that determines whether a team produces coherent work, and it is almost never where teams spend their engineering effort.

## Staffing the team

When a team is warranted, the shape that has worked for us is fewer agents than people expect, with sharper boundaries than people expect.

Start with two. A gatherer that reads, searches, and has no write access at all, and an actor that has the write credentials and works only from structured output the gatherer produced. That split alone buys you the security boundary and covers a surprising share of real workflows.

Add a third only for genuine parallelism. If the gathering work is naturally divisible, four documents, six suppliers, ten records, fan out identical workers rather than inventing different personas. Identical parallel workers are easy to reason about, easy to retry individually, and do not need a translation layer between them.

Add a reviewer only if it has something the others do not. A critic agent using the same model, the same context, and the same tools mostly agrees with itself. A reviewer that checks output against a different source, a policy document, a schema, a calculation done a second way, is doing real work. The distinction is whether it has independent grounds to disagree.

Resist the coordinator until you need it. Two or three agents can hand off directly. A coordinator becomes worth its cost when routing is genuinely dynamic, when you cannot tell in advance which specialist a task needs.

## Every agent gets its own identity

This is the piece that most teams skip and that I would now treat as non-negotiable.

If your five agents share one service account, you have one security principal. The isolation you think you built is a diagram, not a control. An injection into any of them acts with the full permissions of all of them, and your audit log shows one identity doing everything, which means you cannot reconstruct who did what.

Per-agent identity with a scoped credential is what makes the boundaries real. The reader gets read access to the sources it needs and nothing else. The actor gets write access to a narrow set of operations, with hard limits in code rather than instructions. The audit trail records which agent took which action, which is the difference between a debuggable incident and a shrug.

It also makes the delegation question answerable. When the actor takes an action because the reader told it to, on behalf of a user who asked for something, you want a record that can be walked backward. Systems that cannot do that get very awkward the first time somebody asks why a thing happened.

## What breaks, in practice

Four failure modes I see repeatedly in agent teams, roughly in order of frequency.

**Context contamination through handoffs.** Agent A's summary loses something Agent B needed, and B proceeds confidently on incomplete information. This is the most common and hardest to detect, because nothing errors. Structured handoffs with defined fields help more than better prose.

**Goal drift compounding.** Each agent's interpretation of the task drifts slightly from the last one's, and by the fourth handoff the work is adjacent to what was asked. Restating the original objective verbatim at each hop, rather than passing forward an evolving description, fixes most of this.

**Circular delegation.** Agent A asks B, which asks C, which asks A. Funny once, expensive in production. Bound the delegation depth in code.

**The team hiding a single point of failure.** Everything routes through one coordinator whose failure kills the run, and whose context window is the real constraint on how long the team can work. The team is only as long-running as its longest-lived context.

## How to decide, concretely

If I were being asked whether to build a team for a specific workflow, the sequence would be:

Build the single agent first. Actually build it. Most workflows I have been told need a team do not, and finding that out costs a week rather than a quarter.

If it fails, work out why. If it failed on context saturation, splitting may genuinely help, because separate agents have separate windows. If it failed on tool confusion, having too many tools available at once, splitting helps for the same reason. If it failed on accuracy for a specific subtask, a specialist with narrower scope helps. If it failed because the task was ambiguous, a team will fail at it too, more expensively.

Split on the boundary that caused the failure, not on the job titles a human org chart would use. Researcher, writer, editor is a human structure inherited from how people organise, and it maps poorly onto what agents are actually bad at.

Then measure again: cost per completed task, and quality on the same eval set. If the team is not clearly better on at least one and not much worse on the other, go back to the single agent. That comparison is the whole decision and it is remarkable how rarely anyone runs it.

## The part worth being enthusiastic about

I have been mostly discouraging, so let me be clear about where teams genuinely win.

The security split is real and I would use it even when a single agent would work. Untrusted input goes to a component that cannot act. That pattern is worth the overhead every time.

Parallelism on divisible work is real and the wall-clock difference is large. Ten documents processed by ten workers finishes in the time of the slowest one.

And specialisation with different data access is real. An agent grounded in your policy documents and an agent grounded in your customer records will each be better within their domain than one agent trying to hold both.

Those three, and mostly not the five-persona writers' room. That configuration looks like a team and behaves like an expensive monologue.

We build both kinds and we have opinions about which one you need, usually after a week of looking at the workflow. If you are staring at an agent team design and wondering whether it is worth the cost, [that is a good conversation to have before you build it.](https://foundrysoft.co/services)

#### Related reading

[Build Your Own Agent Workspace Before You Buy One

Buzz, Grok Bot, and every major suite are racing to own the room your agents work in. The shape they are converging on is copyable in about two weeks on infrastructure you already run, and doing that first tells you what you actually need.

Agent Workspace AI Agent Teams ACP

](https://foundrysoft.co/blog/build-your-own-agent-workspace)[Grok Build Runs Eight Subagents in Git Worktrees. That Detail Is the Whole Product.

xAI's terminal coding agent fans out to eight parallel subagents, each in its own git worktree, behind a plan you approve first. The worktree isolation is the part worth copying whether or not you use Grok Build.

Grok Build xAI Coding Agents

](https://foundrysoft.co/blog/grok-build-cli-parallel-subagents)[Buzz Puts Your Agents in the Channel. Here Is What That Actually Changes.

Block shipped Buzz in July: an Apache-2.0, self-hostable workspace on Nostr where every participant, human or agent, is a keypair. It is pre-1.0 and genuinely interesting, and the interesting part is not that it looks like Slack.

Buzz AI Agent Teams Nostr

](https://foundrysoft.co/blog/buzz-block-agents-as-teammates)

#### Next Article

[

AI Voice Agents Answer the Phone Now. What That Actually Does to Your Support Org.

](https://foundrysoft.co/blog/voice-agents-support-org-economics)

Available for new projects

## Let's build something great.

Have a project in mind? We are an elite software and AI development studio ready to bring your ideas to production. Let's talk about your roadmap.

Start a Project [See our work](https://foundrysoft.co/work)

```json
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "FoundrySoft",
  "url": "https://foundrysoft.co",
  "logo": "https://foundrysoft.co/logo.svg",
  "description": "FoundrySoft builds production-grade software and AI systems for US companies, from an India-based team of senior engineers.",
  "sameAs": [
    "https://github.com/foundrysofthq",
    "https://www.linkedin.com/company/foundrysoft",
    "https://www.instagram.com/foundrysoft/"
  ]
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "FoundrySoft",
  "url": "https://foundrysoft.co"
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "How to Build an Agent Team That Is Not Just One Agent Wearing Three Hats",
  "description": "Everyone is building agent teams now, and most of them are one prompt with role labels. Here is what actually separates a team of agents from an expensive way to call the same model repeatedly, and how to staff one.",
  "url": "https://foundrysoft.co/blog/building-your-own-agent-team",
  "mainEntityOfPage": "https://foundrysoft.co/blog/building-your-own-agent-team",
  "image": [
    "https://foundrysoft.co/images/blog/building-your-own-agent-team.webp"
  ],
  "datePublished": "2026-08-30",
  "dateModified": "2026-08-30",
  "keywords": "AI Agent Teams, Multi-Agent Systems, Agentic AI, Agent Orchestration, Enterprise AI",
  "author": {
    "@type": "Person",
    "name": "Varun Raj Manoharan"
  },
  "publisher": {
    "@type": "Organization",
    "name": "FoundrySoft",
    "logo": {
      "@type": "ImageObject",
      "url": "https://foundrysoft.co/logo.svg"
    }
  }
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://foundrysoft.co/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://foundrysoft.co/blog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "How to Build an Agent Team That Is Not Just One Agent Wearing Three Hats",
      "item": "https://foundrysoft.co/blog/building-your-own-agent-team"
    }
  ]
}
```