The Agent Team That Found More and Failed
In a small Orbyt trial, the team found more evidence but resolved fewer briefs. I use that failure to define what a task must pass before I add agents.
Key findings
- I separate recurring ownership roles from the architecture used for one task.
- I count coordination, retries, synthesis, and internal verification inside the total budget.
- I use an independent final evaluation because an internal verifier is part of the candidate.
- I keep failures, elapsed time, resource use, and human review visible before choosing.
Key measurements
| Measure | Value | Source and date |
|---|---|---|
| Agent configurations in the cited Google Research evaluation | 180 | January 28, 2026 · Google Research: Towards a science of scaling agent systems |
On September 17, 2026, Orbyt ran one agent against a research team on six competitor briefs for a hypothetical feature. The team produced 16 accepted findings against the single agent's 9. It resolved no briefs; the single agent resolved one. The team cost $16.98 at list price against $7.84.
I did not retain it. That was the declared rule. The field note reports those results.
More accepted findings did not mean more accepted work. Agent count comes later.
I look at the task's dependencies, the state workers must share, and the independent check that decides whether the final answer is usable. I would keep a team only if it passed a decision rule set before I saw its output.
That trial was small. It covered one hypothetical feature, and an agent did the substantive review. Human minutes were not measured, so the trial's human time clause remained unmet. There are no observed customer outcomes.
The public field note reports the verdict and repository evidence paths. It does not directly link the frozen briefs, reports, and verdict records for a reader to audit. Those paths are not public proof.
Which dependency determines the shape?
My agent organization gives recurring work an owner. It does not make every task inside that organization a team task.
I start with the decisions the task requires. I mark which can proceed independently, which wait on an earlier answer, and which require edits to the same state.
I would compare these three arrangements as candidates, not as a ranking.
| Arrangement | When I would test it | What I would check |
|---|---|---|
| One agent | Decisions share context and proceed in sequence | Missed coverage and unchallenged assumptions |
| Manager with specialists | Subtasks separate but need one final decision | Lost caveats and coordination cost |
| Parallel workers with separate verification | Independent searches may add coverage | Repeated sources mistaken for independent evidence |
If a fixed calculation or deterministic transformation can do the job, I would put ordinary software in the baseline too. A new worker needs a job. A new personality is not enough.
What does the research actually support?
In its January 2026 account, Google Research (opens in a new tab) describes 180 evaluated configurations. Coordination helped some parallel tasks and hurt sequential ones in those settings. The accompanying paper (opens in a new tab) later reported 260 configurations across six benchmarks in its April revision. That gives me a hypothesis. It does not tell me which arrangement wins in my repository.
Anthropic's research-system account (opens in a new tab) describes a lead agent delegating parallel investigations and combining them. It also reports substantial token cost and difficulty when workers need tightly shared context. I take its costs seriously. It is no speed promise for my work.
I have already seen a selection rule agree with itself and miss the real task. In my account of the self-improvement ceiling, the page generator and sitemap used the same incomplete list. They matched. Internal checks passed. Requested pages returned 404.
The shared list was the blind spot. Agreement between checks using one source did not establish coverage. In my outside review account, I wrote, "I still did not apply it to the machinery itself." That is why I require evidence outside the arrangement being judged.
What would pass a supplier assessment?
Here is a synthetic supplier assessment. Every supplier, document, field, price, and date in this example is invented. It is an acceptance specimen. No purchase or run happened.
The invented buyer requires single sign-on, deletion of primary data and backups within 30 days of termination, and an annual price no higher than $20,000. I freeze the invented source packet as dated October 1, 2026.
| Invented source | Invented fields |
|---|---|
| Alder capability sheet section 2 and order form section 1 | Single sign-on: yes. Annual price: $18,000. |
| Alder data terms section 4 | Primary data deleted in 14 days. Backups deleted in 60 days. |
| Birch capability sheet section 2 and order form section 1 | Single sign-on: yes. Annual price: $19,000. |
| Birch data terms section 4 | Primary data and backups deleted in 21 days. |
I would accept an answer only if it checks all three buyer requirements for both suppliers, cites the invented document and section for each finding, disqualifies Alder because 60 days exceeds 30, and recommends Birch on this packet. A missing term must be called unknown. Unknown is not a pass. If the evidence needed to check Birch is absent, the correct result is no recommendation.
An answer can cite every document, discuss the $1,000 price difference, and still fail: "Alder is cheaper, so choose Alder." That answer fails. It ignores the backup deadline. Citations and tradeoffs do not repair the omission. The buyer's requirement, not the agents' agreement, decides acceptance.
How would I choose before seeing results?
I have not run this supplier comparison. For an illustrative test, I would freeze six invented packets using the same kind of acceptance rule, with each packet's own disqualifying term. I would compare one agent with a manager and specialists, one attempt per packet for each arrangement. Each attempt would have a $10 model and tool cap and a 15 minute deadline. These are invented thresholds. No result has been measured.
Accepted packets would be my primary measure. I would keep the team only if it passed at least two more of the six packets than the single agent, spent no more than $10 extra in total model and tool cost across all six, and required no more than 10 extra human review minutes. A timeout or an answer missing a required term would fail its packet. If the team tied, improved by only one packet, or crossed any limit, I would keep the single agent. The rule is set first. I cannot move the benefit or cost line after seeing results.
I would give each candidate the same frozen documents, model version, tools, permissions, and final rubric wherever possible. I would isolate their working stores.
I would record the instructions unique to the manager and specialists. A better brief or an extra retrieval tool changes more than coordination.
The $10 cap would apply to the entire arrangement, including manager, workers, retries, synthesis, and its own verifier. I would predeclare the six packets and the stopping rule, keep failed attempts, and let an independent reviewer judge final artifacts with the arrangement label hidden where practical. The internal verifier is a candidate component. It cannot grade itself.
This example does not establish that six packets are enough to generalize to other buyers. It shows a bounded rule. A real decision would need the real buyer's requirements and a sampling plan that fits the stakes.
What would I count after the run?
I would keep a record of every attempt, including refusals and failures.
| Measure | What I would record |
|---|---|
| Acceptance | Pass or fail under the frozen rubric, with the reason |
| Source fidelity | Unsupported claims, missing terms, and traceable evidence |
| Resource use | Model and tool cost across every worker, retry, and verifier |
| Elapsed time | Task start to accepted result or declared stop |
| Human work | Review, clarification, repair, and integration minutes |
| Failure behavior | Timeouts, incomplete handoffs, and conflicting findings |
I would report human minutes separately from API spend unless I had declared a rate for converting them. I would calculate cost per accepted packet from the whole batch cost, including failed attempts. If nothing passes, I would report zero accepted packets, not invent a cost per success by dividing by zero. I would keep raw outcomes. An expensive rescue must remain visible.
When would I make the team smaller?
I would inspect the critical path when workers keep repairing one another's assumptions. A manager that approves every small step can turn a parallel plan into a queue. More findings may improve coverage without shortening the path to an accepted answer. My trial showed a version of this: more accepted findings, and fewer resolved briefs.
I would check evidence independence too. Several agents citing the same mistaken document have produced agreement, not corroboration. A separate reviewer needs a way to challenge the answer with source material, not only the workers' summaries. Verification Is the New Literacy makes the same demand of the final artifact.
I would not remove a required authority boundary just to improve throughput. A specialist may need narrower permissions, and a reviewer may need distance from the builder. The permissions model and the outside review loop explain why those roles can be worth their cost. I compare only arrangements that preserve the required boundaries.
Swarms Demo. Legions Ship. asks who owns the result. Here I am deciding how that owner arranges one task. One owner remains accountable. That owner can supervise one agent, several workers, or a deterministic process.
What to do Next
I would choose one recurring task with a real acceptance condition, write the disqualifying failures, and map its dependencies. Then I would compare the simplest capable baseline with one plausible alternative under a declared budget and stop rule. The Test Suite Became Orbyt's Only Living Specification. is my reminder that an acceptance rule must say what fails, not merely what sounds good.
For the invented supplier comparison, the team would need two additional accepted packets within the cost, time, and review limits I set above. I have not run that test. Until an actual comparison clears a declared rule, I would keep the simpler arrangement and write down what evidence would change my decision.
Related reading:
- Swarms Demo. Legions Ship. on who owns coordinated work.
- I Manage AI Agents Now, Not People on recurring roles beyond one task.
- Verification Is the New Literacy on checking the artifact against outside evidence.
- The Test Suite Became Orbyt's Only Living Specification. on writing a check that can reject an answer.
I would add agents only when the task's acceptance rule justifies their full cost.
Methodology
Engineering guide based on Google Research's January 28, 2026 account and linked scaling-agent-systems paper, Anthropic's June 13, 2025 research-system account, Orbyt's September 17, 2026 single-agent-versus-team field note, and published Orbyt material on roles, permissions, verification, and outside evidence. The supplier-assessment task, comparison sheet, and selection rule are proposed methods. No new architecture benchmark was executed.
Limitations
Published benchmark and vendor-system results do not establish performance for Orbyt or another deployment. The three candidate arrangements are not an exhaustive architecture taxonomy. Prompts and coordination mechanisms can differ between candidates and must be recorded. The proposed comparison produces task-specific evidence; no architecture winner, cost saving, or statistical certainty is claimed here.
Sources
- I Manage AI Agents Now, Not People Retrieved October 3, 2026.
- Google Research: Towards a science of scaling agent systems (opens in a new tab) Retrieved October 3, 2026.
- Towards a Science of Scaling Agent Systems: research paper (opens in a new tab) Retrieved October 3, 2026.
- Anthropic: How we built our multi-agent research system (opens in a new tab) Retrieved October 3, 2026.
- A Single Agent and a Research Team on Equal Ceilings Retrieved October 3, 2026.
- AI Builds AI. I Found the Ceiling. Retrieved October 3, 2026.
- 391 Yeses and Not One No. Retrieved October 3, 2026.
- Codex Accuses. Claude Convicts. Retrieved October 3, 2026.
- Swarms Demo. Legions Ship. Retrieved October 3, 2026.
- Verification Is the New Literacy Retrieved October 3, 2026.
- The Test Suite Became Orbyt's Only Living Specification. Retrieved October 3, 2026.
Common questions
When should a task use one agent instead of a team?
I start with the task's dependencies and required authority boundaries. For the synthetic supplier test, I would keep the team only if it passed at least two more of six packets within the declared cost and review limits. Ties and smaller gains keep the single agent.
What makes an architecture comparison fair?
I would freeze the requirements, packets, and exact acceptance rule before execution. Each arrangement would get the same evidence, tools, permissions, and independent final review where possible. I would also record its unique instructions, total budget, failures, and stopping rule. That record is needed to attribute any gain to coordination.
How should the cost of multi-agent work be measured?
I would count the manager, workers, retries, synthesis, tools, and internal verifier across the whole arrangement. I would keep human review minutes separate from model and tool spend. Failed attempts belong in the batch cost per accepted result. If nothing passes, I would report zero accepted packets and no cost per success.
Related research
- Governing an agent leadership team Sep 2026.
- I Ran 830 Agents in One Long Horizon Session. Jul 2026.
- My C-Suite of Agents Named Themselves. Jul 2026.
Follow the work.
I write these while the Machine runs. Get the next one wherever you already read.




