One Agent or Many: When a Subagent Earns Its Own Context
Default to one agent loop with skills and tools; split only when an eval or a hard time budget says so
Operator recipe for deciding how many agents a job needs. Two October 2026 sources point the same way from opposite ends. Anthropic’s Applied AI team reports that across several enterprise deployments "a single agent with skills frequently outperformed both the one-prompt-for-everything design and the subagent design on quality, and often at a lower cost and latency per task", and warns against "the agent architecture becoming a copy of their org chart" (Claude blog, 22 Oct 2026). It keeps subagents for three cases: measurable degradation from context bloat, parallel tasks that need fresh, discardable context windows, or a single agent that "struggles to select appropriate tools". Microsoft Research’s open-source Agensh harness shows the other side: with no central orchestrator and a six-hour budget, the Pandoc test-pass rate rose "from 33.89% with 1 agent to 50.94% with 128 agents and 55.06% with 1,024 agents" (README, 24 Oct 2026). Those figures are the publishers’, not Institute metrics. The rule: one loop by default, more agents when the clock binds and the work splits cleanly, and an eval behind every change.
Core Workflows (5)
Each workflow represents a critical business function. Click any workflow to see detailed automation architecture.
Start with one loop, not an org chart
Led by: Main AgentRun one model and one context window in a tool loop, with turn and cost budgets and write gates set in the harness. Anthropic describes the target as "One model and one context window running an open-ended tool loop, with limits (turn and cost budgets, write gates) set in the harness." Do not give each function its own agent by default; that copies the org chart and adds handoffs.
Put procedure in skills and actions in tools
Led by: Main AgentMove a specialist’s know-how into a skill that loads only when needed, and its API calls into tools grouped by user intent. Anthropic notes that "once you exceed 30-50 tool definitions in the system prompt, tool choice tends to degrade", so use tool search with deferred loading. Put hard checks and per-user permissions inside the tools, which return a plain refusal the model can read.
Split only for a reason you can measure
Led by: OwnerKeep or add a subagent only when one of three conditions holds: context bloat measurably degrades the main loop; independent tasks run in parallel with fresh context that can be thrown away; or one agent cannot pick the right tools or carries conflicting instructions. When you split, divide by context, not by problem type, so each subagent needs little from the rest and hands back a compact result.
Use many agents when the time budget binds
Led by: OwnerWhen a large job must finish inside a fixed window and splits into claimable sub-tasks, a peer team can buy progress. In Agensh, agents "discover and claim sub-tasks, share findings, verify results and merge progress asynchronously, without a central orchestrator", over a shared repository and message channel. Across the five hardest ProgramBench tasks the mean final pass rate went from 19.31% with 1 agent to 28.78% with 128. The paper reports pass rates, not cost, so budget for spend that grows with the number of agents.
Eval every fold, and run each task more than once
Led by: Eval OwnerBuild a small end-to-end eval first; Anthropic says "Even a set of 10 golden examples is enough to start." Fold or split one agent at a time and compare which tasks flipped, not just the score. In Anthropic’s support-agent test a fold cut latency but broke a passing process, and "a break like this one only showed up in one run out of two", so run each task at least twice and include a task for every chain of agents that runs together in production.