Short answer
Swarm chaos is what happens when every integration gets promoted to an 'agent': N separate contexts, N duplicated tool surfaces, an unmanageable context budget, and no way to tell which component owns a failure. The fix is not fewer capabilities - it is separating CAPABILITY (a stable name for what the system can do) from IMPLEMENTATION (who currently does it), and stopping the habit of calling every service an agent.
PRIMARY SOURCE RESULT: Ernesta Labs studied three open repositories that implement this separation in different places. Agency Agents (msitarzewski) provides small focused specialist implementations with distinct roles, meant to be composed rather than run as autonomous peers. Agent Reach (Panniantong) provides a capability-provider abstraction with health checks and fallback, so a worker failing to use X does not prove X does not exist. Comet MCP (hanzili) packages deep web research behind the Model Context Protocol as a callable capability - a provider, not a second brain.
The architecture these converge on: an authenticated tool/action estate, a specialist selection layer, selectively loaded specialist implementations, model routing behind stable role names, browser capability behind a provider, and provider health with failover. Ernesta Labs runs exactly this structure in production. That it runs is implemented and verified; that it outperforms a simpler stack is NOT YET PROVEN.
The failure mode: swarm chaos
Start with the demo everyone is shipping: a fleet of specialized agents. A research agent, an email agent, a CRM agent, a browsing agent, a scheduling agent - each with its own window, its own prompt, its own tools, its own vendor contract. It looks like a system diagram from a conference keynote. In production it behaves like a room full of people shouting over each other: five contexts that each hold a copy of the plan, five tool surfaces with overlapping permissions, five places where a failure can hide, and zero places where responsibility is assigned.
The deeper failure is naming. When every integration is called an 'agent', you lose the two distinctions that make tool systems debuggable: what the system can do (capability) versus who currently does it (implementation), and what a component is responsible for versus what it merely observed. Swarm chaos is not caused by having many tools. It is caused by promoting every tool to a peer of the reasoning loop.
The counter-pattern already exists in mature engineering. Your application does not call a 'Postgres agent' or a 'Stripe agent'; it holds a capability - durable storage, payment processing - behind an interface with implementations that can be swapped. Agent systems need the same discipline applied to a messier substrate, and they need it more urgently, because agent implementations are currently the fastest-replacing parts of the stack: model vendors, tool providers, and MCP servers turn over monthly, and a prompt hard-wired to any of them is migration debt taken on by accident.
What the sources actually are
PRIMARY SOURCE RESULT: this article draws on three open repositories, not papers, so the claims here are about what the codebases provide - not about benchmark results. Agency Agents (github.com/msitarzewski/agency-agents) offers a library of small, focused specialist implementations, each with a distinct role and compact instructions, intended to be composed by a host rather than to run as autonomous peers. The interesting property is the shape: specialists are swappable units with a defined contract, not mini-CMOs with their own agendas.
PRIMARY SOURCE RESULT: Agent Reach (github.com/Panniantong/agent-reach) implements a capability-provider abstraction: capabilities are named, bound to one or more providers, and served with health checks and fallback between providers. Its core insight is captured in our article 19 takeaway - 'the worker cannot use X' does not prove X does not exist. A capability layer keeps the existence of a capability independent of whether any single provider is reachable, healthy, or configured at this moment.
PRIMARY SOURCE RESULT: Comet MCP (github.com/hanzili/comet-mcp) packages deep web research behind the Model Context Protocol: the host agent invokes a research capability, and a Comet-backed browser session does the fetching and synthesis. It is a browser capability provider. The repo is deliberately narrow - one capability, one provider, one protocol boundary - which is exactly why it composes into a larger estate without becoming the architecture itself.
None of the three repositories publishes a controlled study. That is not a knock on them - infrastructure code rarely does - but it fixes the epistemic status of this article: the evidence is architectural, the convergent working implementations of a separation pattern, plus our own engineering experience adopting it. Anyone who presents these repos as proof that capability separation improves outcomes is selling something.
Capability is stable; implementation is replaceable
The first rule all three sources share: name capabilities, not vendors. 'Web research', 'send email', 'read the CRM', 'control a browser' are capabilities - slow-changing nouns your system design can be built around. Comet MCP, a specific search API, or a specific browser runtime is an implementation - a fast-changing part you should be able to replace in an afternoon when the provider is down, deprecated, or outbid.
Agent Reach makes the pattern concrete: a capability has a name and one or more providers; providers have health; on failure the capability can fall back to another provider, and the caller never learns which provider answered. This is the same shape as a database driver or a payment gateway, and it has the same payoff - swapping an implementation is a configuration change, not a redesign.
The second rule follows immediately: do not call every service an agent. A specialist that receives a task, does bounded work, returns a result, and holds no authority is a tool with good ergonomics. Calling it an agent is not harmless marketing; it changes your incident analysis, because you will start asking 'what did it decide?' about components that do not decide anything, and you will route around the reasoning layer - the one place decisions are actually recorded - when something goes wrong.
Selective specialist loading and the context budget
Agency Agents' contribution is the specialist estate: a set of focused implementations with distinct roles, loadable as needed. The reason this matters more in agent systems than in classic software is the context budget. In a REST stack, adding a service costs a connection pool. In an agent stack, naively adding a specialist costs permanent tokens: every tool description, every role instruction, every output schema rides in the context of the reasoning loop that might call it.
This is how context explosion kills swarms. Ten specialists with full schemas and instructions, all resident, all the time, means the reasoning model spends attention on plumbing instead of the task - and the agent-rot arithmetic (article 3) says degradation compounds with trajectory length, so you are taxing exactly the dimension where reliability is already bleeding. Selective loading is the remedy: the planner sees capability names and one-line descriptions; full instructions, schemas, and sub-contexts load only when a capability is actually invoked.
LABS INTERPRETATION: selective loading is not an optimization, it is a reliability mechanism. A resident tool surface is a permanent tax on every reasoning step; a selected tool surface is a per-task cost paid only where it earns its keep. The specialist estate works precisely because specialists are cheap to keep around when they are not resident - the library exists, but the context does not contain it until the selection layer asks for it.
Routing, provider health, and failover
Model routing is the same pattern applied to inference. A thin routing layer keeps stable role names - 'the reasoning model for sales tasks', 'the cheap model for extraction' - and lets the implementations behind those names change: a new model version, a cheaper tier for routine steps, a different vendor during an outage. Prompts and specialists reference the name, never the implementation. When the name survives a vendor switch, the switch is a routing-table edit.
Provider health closes the loop. A capability without health data degrades silently: requests queue, latency climbs, results thin out, and the reasoning layer papers over it by retrying - the fallback-accumulation failure that monitoring work (article 23) flags as a decay signal. A capability with health data and failover fails loudly at the capability boundary and routes around the bad provider instead.
Agent Reach's health-and-fallback shape is the inspiration for our failover design; we do not claim to have adopted the repository wholesale. What we adopted is the boundary: a capability table, providers, health probes, failover order, and one non-negotiable rule - the reasoning layer is never told which provider served a request. The moment prompts know the provider, they start depending on the provider's quirks, and replaceability dies. Provider identity is telemetry for operators, not context for models.
Responsibility, evidence, and authority boundaries
Specialists create a responsibility assignment problem that swarms pretend not to have. When five components touch a customer record, who is responsible for the record being right? The unhelpful answer is 'the swarm'. The useful answer names one owner per responsibility: the reasoning layer owns decisions, the tool estate owns actions, the capability layer owns dispatch, and evidence - what actually happened - is written by the action at execution time, not remembered by the model afterwards.
Authority is a sharper boundary than responsibility. A browser capability provider may retrieve pages; it may not decide what to buy. An email capability may send a drafted message; it may not originate policy about who gets emailed. These are the same authority rules we developed in the memory-trust work (articles 15, 17, 18), applied to providers: evidence can flow up from implementations; goals, permissions, and policy cannot.
Keeping authority at the reasoning layer is also what makes the estate auditable. Every effect has a caller, every caller has a decision record, and no effect originates inside a provider. A swarm without this property cannot answer the basic production question - 'who did this?' - with anything better than a committee of chat windows.
Limitations - stated honestly
First, the evidence is architectural, not empirical. No controlled study exists - in these repositories or anywhere we know of - showing that capability-shaped estates reduce failure rates versus simpler agent stacks. The sources are working implementations of a pattern; our own adoption experience is engineering observation, not a benchmark.
Second, repository maturity varies. These are open projects with individual maintainers; we run none of them as critical-path production infrastructure, and we do not attest to their reliability under load. A builder adopting any of them should evaluate maintenance activity, test coverage, and license independently. What we recommend adopting is the pattern; whether to adopt the specific code is a separate decision we do not make for you.
Third, our estate measurements are internal and task-specific. Selective loading cut resident tool surface substantially for our task mix; that number does not transfer to yours, and we are not publishing it as a benchmark. Fourth, capability separation adds indirection - a registry, health probes, routing tables - which costs engineering time and can obscure failures behind abstraction if observability is not built alongside it from day one.
Why builders care, and what we would - and would not - build
Why builders care: every month brings new model vendors, new tool providers, and new MCP servers. If your prompts are hard-wired to implementations, every one of those events is a migration project. If your estate is capability-shaped, they are configuration diffs. That difference compounds, and it decides whether a provider outage is a page-at-3am event or a silent failover you read about in the morning log review.
LABS INTERPRETATION: the interesting thing about the swarm-versus-estate question is that production infrastructure has already answered it. Storage, payments, identity - the parts of the stack that survived contact with real operations - all sit behind capability interfaces with replaceable implementations and health-checked providers. The agent tooling wave is young enough that vendors still sell the swarm, but the same convergence pressure applies, and these three repositories are early evidence of it arriving.
LABS RECOMMENDATION: build the estate in five moves. One: enumerate capabilities as stable names - actions, not vendors. Two: stand up a tool registry with selective specialist loading, so only invoked capabilities cost context. Three: put model routing behind stable role names and treat vendor choice as a routing-table value. Four: add health probes and explicit failover per capability, and never leak provider identity into prompts. Five: write authority boundaries into the registry - what each capability may do, and what it may never originate: goals, permissions, policy.
What we would not implement: no autonomous peer agents with equal authority over shared state - that is the swarm shape, and it makes responsibility unassignable. No provider-to-provider calling, because chaining inside the estate recreates the swarm one level down and defeats the audit trail. No per-provider prompt tuning: a prompt that only works against one provider's quirks is migration debt you have already taken on. And no capability without an owner - an estate entry nobody is responsible for is a future incident with a name attached in advance.
CASE STUDY - NIKO: one estate, five roles, no swarm
Ernesta Labs runs NIKO - the sales system behind sellwithniko.com - on exactly the estate structure described above, with five named roles. Composio serves as the authenticated tool/action estate: the registry of connected capabilities and their credentials. NEXUS is the specialist selection layer: it maps a task to the capabilities and specialists that task needs, and only those load. Agency Agents supplies the specialist-implementation pattern: bounded workers with focused instructions, invoked by selection rather than resident. OmniRoute is the model routing layer: stable role names for reasoning and routine work, with model implementations behind them. Comet is the browser capability provider - research behind a capability call - and Agent Reach's health-and-fallback shape inspired provider failover across the estate.
The behaviors we can honestly report as implemented: capability routing is live, meaning a task's specialist set is selected per task rather than resident; routing tables and provider failover exist; and swapping an implementation behind a capability has not required prompt changes. What we have not demonstrated: that this structure reduces failure rates versus a simpler stack - there is no controlled comparison, and we do not claim one. The failover path has been exercised in testing, not in a full production outage. Autonomy stays at the reasoning layer: no specialist holds authority, and no provider calls another provider.
STATUS: IMPLEMENTED for the capability/implementation separation, selective specialist loading, routing, and failover; VERIFIED that the estate runs in production for NIKO's sales work; benefit over simpler designs NOT YET PROVEN.
The role audit: classify your estate in an afternoon
Take your current agent stack and list every external thing it touches: models, APIs, MCP servers, scripts, browsers. For each entry, answer three questions. One - is it a capability (a stable name for what the system can do), an implementation (a current way of doing it), or an 'agent' (a peer that decides)? Two - could you swap it tomorrow without editing a prompt? Three - if it went down at 3am, would the system fail loudly at a boundary, or degrade silently somewhere inside a reasoning loop?
Then run three concrete checks. Swap test: replace one implementation with a stub or an alternative for one capability, and count how many prompts or config files you must edit; anything over one is coupling. Context test: paste the full tool surface your reasoning model sees at rest - every description and schema - into a token counter, and divide by the model's context window; if resident tools exceed roughly ten percent for a single task type, you have no selective loading. Failover test: block one provider's network access during a real task run and watch where the failure surfaces - at a capability boundary with health telemetry (pass), or as retries and eventually hallucinated success inside the loop (fail).
Score one point per pass. Under two points means your estate is a swarm wearing a system-diagram costume, and the next provider outage will tell you so first. The whole audit takes an afternoon with no new tooling - and the findings are usually structural rather than subtle.
What remains unknown
- Whether capability-shaped estates measurably reduce failure rates versus simpler monolithic agent stacks - no controlled comparison exists that we know of, including for our own estate.
- How well cheap health probes predict provider usefulness: a provider can be 'healthy' and still return poor results, and we have no validated metric for output quality at the capability boundary.
- Where the right boundary sits between 'one specialist with more context' and 'two specialists with a handoff' - selective loading trades context cost for handoff complexity, and no published guidance covers the trade-off.
- Maintenance economics: registry and routing indirection is young in agent contexts, and whether its observability overhead stays proportionate as estates grow past tens of capabilities is unproven in our system and in the sources.