Cohere Proposes 'Provisional Duplication': Managing Enterprise Agent Sprawl Through Competition
As enterprise AI agent platforms become more prevalent, employees find it easier to build and deploy agents to support their own work. However, this decentralized creation introduces a new management challenge: how to track what agents have been built across the organization. In a blog post published on October 15, 2026, Cohere presents a counter-intuitive view: the increase in the number of agents (proliferation) does not necessarily lead to chaos. It should only be termed 'agent sprawl' when the process for managing agents fails to keep pace with their growing numbers.
The article first distinguishes between 'proliferation' and 'sprawl'. Those closest to a workflow are often best placed to determine how it could be streamlined by an agent, making decentralized experimentation valuable. Furthermore, an agent that isn't being used doesn't consume tokens simply because it exists, meaning pure quantity growth doesn't directly equate to high operational costs. The real pain point lies in a lack of visibility, which makes it difficult for teams to find and reuse existing agents and harder to govern access to enterprise data and systems.
Currently, enterprises typically manage growing agent estates through centralized, federated, or hybrid delivery models, increasingly using agent registries to maintain a shared view. These methods share a common preference for avoiding duplication, encouraging teams to default to reusing existing solutions. While reducing overlapping options lowers monitoring and governance burdens, Cohere argues that treating duplication as an absolute taboo can suppress innovation. If the mere existence of a workable agent means no alternatives should be built, organizations forfeit the opportunity to discover solutions that are cheaper, more reliable, or better suited to the task.
To address this, Cohere proposes an alternative approach: allow agent variants to compete. In this model, duplication is treated as provisional rather than permanent. If a team has a credible reason to believe it can improve on an 'incumbent' agent, it should be permitted to build a 'challenger' variant. However, the continued use of the challenger depends on whether it demonstrates a meaningful advantage over the incumbent.
This competitive model requires a time-bounded, evidence-based comparison. Specific metrics will depend on the use case but could include measures such as reliability, token use, latency, and task performance. For example, consider a bank's commercial lending division where a central team has built a finance agent that drafts credit memos. A lending team handling routine annual reviews might build a challenger designed for the same tasks using a smaller, cheaper model and an additional cross-checking step. For 30 days, both agents draft memos for representative cases, and the bank compares them on four measures: how many figures trace correctly to source documents, how heavily credit officers edit each draft, token cost per memo, and time to first draft.
Once enough evidence is collected, the organization decides whether the challenger should replace the incumbent or be retired. If the challenger proves better suited to a part of the workload, both agents might remain as distinct alternatives. The key is to pair variation with selection pressure. By making agent creation easy but persistence conditional on performance evidence, enterprises can preserve the benefits of continuous experimentation without sliding into uncontrolled agent sprawl.
Fontes:cohere.com