AI Agent Teams: When One Agent Is Enough
Learn when to use a single AI agent or a team, how delegation and review work in osFoundry, and what to check before trusting the result.
AI Agent Teams: When One Agent Is Enough
At 7:40 on a Tuesday morning, Priya needs to answer a question her director expects by lunch: does a four-day workweek maintain productivity? A chatbot can spit out a confident paragraph fast. But if the same model finds the numbers and decides whether they hold up, there's no independent check on how it reasoned.
Priya needs a process: find relevant trials, extract the data, and send unsupported claims back for verification. That's exactly the kind of structure an AI agent team is meant to provide. But it's not automatically "better" than using one agent. More agents usually means more coordination, more review steps, and more opportunities for the workflow to get stuck.
In osFoundry, a desktop app for running AI work on your machine, Single agent and Agent team give you two ways to start. The practical choice depends on the work - its complexity, how expensive an error would be, and whether independent review is worth the extra steps. This guide explains how the two modes differ, how a team session works, and how to choose a setup that's useful without turning into busywork.
How do a single agent and an agent team differ?
A single agent has one defined role and a set of instructions. You give it the task, and osFoundry assigns it an ID so you can jump back into its sessions and see what it did. This works best when the job is consistent and your instructions cover the rules that matter.
For example, a single agent can turn meeting notes into action items using a fixed format. If you tell it not to invent owners or deadlines, it can label missing details as missing instead of filling gaps with guesses. You set that up once, then reuse the agent rather than pasting the same instructions into every new chat.
An agent team adds an orchestrator and a roster of specialized agents. The orchestrator breaks the work into a plan, assigns steps, and combines results. Depending on the task, some agents can work at the same time, while others wait on prerequisites. A separate reviewer can check a member's work before it's included in the final response.
The key distinction isn't "one model versus several models." It's the shape of the work. A team makes roles, handoffs, and review points explicit. That can make complex work easier to inspect, but it also adds coordination overhead. The roster isn't a fixed workflow - the leader decides the order based on the plan.
In osFoundry, both options show up under Agents and use a similar session interface. With a team, the central conversation is with the leader; member activity appears in session views like Handoffs and Sub-agents. The session history keeps messages, handoffs, and review verdicts, so you can see how a result was assembled instead of only seeing the final answer.
That history is helpful, but it doesn't automatically mean the answer is correct. A review step tells you the work went through the workflow; it doesn't prove the reviewer had the right evidence or caught every mistake. Treat the team's process as an audit trail - useful for scrutiny, not a replacement for judgment.
How does an agent team session work?
A team session starts with a goal and a group of agents. In the New team session window, you can start from an existing team (like a Deep Research Team) or pick your members and choose who leads before creating the session. Once created, the team is locked for that session's lifetime, so it's worth picking the roster up front.
You send the task once in the leader's chat. The leader makes a plan, assigns steps, and coordinates dependencies. In a research task, for example, one member might search for studies while another extracts figures from sources. The data researcher may need to wait until the search specialist returns relevant material. Parallel work can save time when steps are independent, but dependencies still run in order.
Follow the work, not just the final answer
The main conversation shows the leader's combined response. Other parts of the session are there to make the process visible:
- Sub-agents shows what each member was asked to do, the tools it used, and the result.
- Handoffs records who passed work to whom.
- Team mail and Email show communication between participants in the session.
- Proposals collects suggested changes to files or settings. A proposal doesn't apply automatically - you still have to accept it.
- Files gives you a place to review the materials used during the session.
The Agent session panel gives each member a card. You can check that member's task, tool calls, and output, along with the reviewer's verdict. If a reviewer sends something back, the member can rework it before the leader uses it. In Priya's example, a productivity figure comes back because it lacks a source, date, and metric. The revised result can then be checked and approved.
That targeted check matters more than a generic instruction to "be accurate." It makes the workflow spell out what evidence a claim needs. A good final response might include a source for every row, note where studies disagree, and list what the research didn't cover. Those details help a reader understand both the conclusion and its limits.
A team session can also include success criteria. They start as unmet, then get marked complete as work progresses. The session ends when the criteria pass or when the configured round limit is reached. That's useful when "finish the task" is too vague. For a release package, criteria might require a draft, a change audit, and a completed approval summary.
The interface also includes options like Cards or Graph view, a run selector, and controls such as Pause. Those are operational details, but they affect whether a team is actually manageable - you need to know where the task is, what it depends on, and when you need to step in.
When should you use one agent instead of a team?
Use one agent when the task is bounded, repeatable, and governed by stable rules. Reformatting notes, drafting in a consistent tone, or converting a known input into a defined output are good fits. The point of a single agent is keeping instructions around and avoiding repeated setup - not splitting work that doesn't need splitting.
A team becomes more useful when the task has distinct parts, different tool needs, or a real reason to separate production from review. Research that involves finding studies, extracting data, checking sources, and synthesizing disagreements naturally breaks into stages. A release process might need one agent to draft notes, another to audit changes, and a reviewer to check documentation or QA summaries.
A practical decision test
Before you pick, ask these four questions:
- Can you describe the task as one clear transformation? If the input and expected output are stable, start with one agent.
- Are there genuinely independent workstreams? Use a team when different roles can move forward without just duplicating each other.
- Would an independent check change your decision? If an unsupported statistic (or a missed release issue) would have real consequences, a separate review step may be worth it.
- Can you inspect the output and intervene? If you can't evaluate what you're seeing or supply missing context, adding agents may make things harder to supervise - not safer.
Every extra role comes with a cost. A team may require more model calls, more time, and more attention to untangle conflicting outputs. It can also create false confidence if a reviewer accepts something that looks plausible without checking evidence. Use a team when the division of labor addresses a specific risk - not when a larger roster just sounds impressive.
A good default is to start with one agent for repeatable, low-risk work. Move to a team when you can name the parts that need separate ownership or the checks a single pass can't realistically provide. If you can't explain what each member is doing, the roster is probably too large.
| Work pattern | Starting point | Why |
|---|---|---|
| Repeated formatting or drafting with fixed rules | Single agent | Consistent instructions handle most of the work |
| Research requiring multiple sources and evidence checks | Agent team | Search, extraction, and review can be separated |
| One-off task with unclear requirements | Human clarification, then an agent | Delegation can't fix an undefined goal |
| Release preparation with several review responsibilities | Agent team | Distinct outputs and ownership are easier to track |
How do you run a team session with appropriate oversight?
Start by writing the outcome in terms someone else could verify. "Research the four-day workweek" is broad. "Summarize relevant trials, report each productivity figure with its source and measurement period, identify conflicting evidence, and list gaps" gives the leader something concrete to plan around.
Then choose the team based on the work - not the other way around. A research roster might include a search specialist, a researcher, an analyst, and an academic researcher. The roles only help if responsibilities are clear and outputs are checkable. Before you create the session, look at the roster and confirm the leader is a good fit. In osFoundry, the orchestrator is the default leader, but you can assign that role to another member before starting.
Define review criteria before execution
A reviewer needs more than "check the answer." For a research task, require a source, publication or collection date, and a clear definition for every reported figure. For a release, define what changes must be audited and what makes an approval packet complete. Criteria should be observable - either the evidence is present or it isn't.
During execution, follow the handoffs and check returned work when the risk warrants it. If a reviewer rejects something, look at the reason. A rejection without a useful explanation can turn into a loop; a rejection tied to missing sources or undefined metrics gives the worker a clear path to correct the issue. You can also respond in the leader's chat to clarify priorities or pause the session while you review.
Use Proposals as a controlled change process. Agents can suggest edits to files or settings, but they shouldn't quietly change configuration. Accept changes only after you've checked what they alter and whether they should apply beyond the current task. Also, keep durable agent instructions separate from one-off requests unless you actually mean to change the agent's future behavior.
Finally, review the final answer against the original criteria. Confirm that evidence supports the claims, disagreements are represented fairly, and important gaps are labeled. The session history can help you trace a claim to a member and handoff, but you're still responsible for deciding whether the result is fit for the intended use.
What are the limits of agent teams?
A team adds structure, but it doesn't erase uncertainty. Agents can share the same mistaken assumption, rely on weak sources, or produce outputs that look independent while pulling from the same flawed evidence. A separate reviewer reduces one kind of risk only if the check is meaningful. Role labels alone don't create independence.
Coordination has a cost too. Every handoff is a chance for lost context, delays, or disagreements. If the leader's plan is poor, adding more members can multiply the confusion. In many cases, a small team with clear responsibilities is easier to inspect than a larger roster where people overlap.
The session setup also has boundaries. The team is fixed for the lifetime of a session - if you need a different group, start a new session. You can adjust members and the leader before you press Create, which makes the preflight decision important. Goals and round limits can help bound the work, but they don't guarantee the criteria are meaningful or that an agent will solve a hard problem within the limit.
The product's session setup also mentions Local and Isolated execution options, describing them as running on your machine with your keys and chat history local by default. That's helpful operational context, but it shouldn't replace your organization's own data-handling review. Check the current configuration, connected tools, and applicable policies before processing sensitive information. "Local" should be understood in the context of the actual execution environment and the integrations you turn on.
Key takeaways
- Choose one agent for clear, repeatable work with stable instructions.
- Choose a team when independent tasks or a real review requirement justifies coordination.
- Define evidence and success criteria before execution, not after an answer starts to look convincing.
- Treat handoffs and reviewer verdicts as inspectable process records, not automatic guarantees of correctness.
- Keep human approval in the loop for consequential decisions and configuration changes.
Conclusion
An agent team is worth using when the work can be divided into clear responsibilities and an independent check genuinely improves the result. For repeatable tasks with fixed rules, a single agent is usually the better starting point. Pick the smallest setup that handles the work's real complexity and risk.
In osFoundry, the practical advantage of a team isn't a more "elaborate" answer. It's that you can inspect plans, handoffs, member outputs, review verdicts, and proposed changes. Set clear criteria, keep human oversight where the stakes are high, and add agents only when each role has a job you can explain.