Cohere Proposes Making Duplicate AI Agents Compete for a Place in the Company

On October 15, 2026, Cohere published a post on its corporate blog about what happens when employees start building AI agents themselves and no central team oversees them. The author, principal solutions architect Kasim Patel, describes a familiar picture: agents multiply, nobody has a complete list, teams cannot find what has already been built, and access to corporate data and systems gets harder to control. He calls this state agent sprawl. The company's prescription: don't try to suppress duplicates, make them compete.

The article also serves as a showcase for North 2, Cohere's secure agent platform that runs alongside the customer's data. The text offers no supporting figures, such as the share of duplicate agents or the savings. It is more a framework for thinking than a study.

A growing number of agents is not yet a problem

Patel addresses the main concern up front. The platforms that cause sprawl make experimentation cheap. Employees no longer need to go to a central AI or engineering team every time: the people closest to a process are best placed to see what in it can be automated. A successful agent built by one team may suit another, and in that case the spread of agents shows that people are actively looking for uses.

He treats cost separately. An agent that nobody uses does not consume tokens just by existing. A rising agent count does not necessarily raise the inference bill. The load appears when governance processes fail to keep up with the number of agents. That is when proliferation turns into sprawl.

Three models and a registry

Today companies mostly choose from three setups:

• centralized: a central team builds the agents and is responsible for them. Control is tighter, but the pace of innovation is slower;
• federated: business units own development and operation, while the center provides infrastructure, standards and governance templates;
• hybrid: responsibility is split between the center and the business under shared standards.

In all three cases, an agent registry is increasingly common. It records the owner, usage and access rights, and helps employees find what has already been built. The logic is clear: reuse first, build second. Fewer overlapping options to choose from, fewer agents to monitor and audit.

But a "no duplicates" principle has a cost. If the mere existence of a working agent closes the door on alternatives, the organization will never learn what could be done more cheaply, more reliably or more accurately for a specific task.

Challenger versus incumbent agent

Cohere proposes treating duplication as temporary. If a team has a convincing case that it can improve on the "incumbent" agent, it is allowed to build a "challenger." But the challenger stays in production only if it shows a measurable advantage. That requires a time-limited, data-driven comparison. The set of metrics depends on the use case, and the examples named are:

• reliability;
• token consumption;
• response latency.

In the available portion of the text the list breaks off, so the full set of criteria and the details of the procedure are not disclosed here.

How to apply it in practice

You can test the idea without buying a platform. First, set up a registry with the owner, access rights and usage statistics for every agent. Without it, there is nothing to compare. Second, define in advance what counts as an advantage: for example, fewer tokens per task at the same reliability. Third, set a deadline: a pilot with no end date quickly becomes yet another permanent agent. Fourth, decide what happens to the loser: it is shut down, archived or merged with the winner.

One question the article does not address: who pays for running two agents in parallel during the test, and how to compare them on real data rather than convenient data. These details will determine whether the model becomes a selection tool or just another layer of bureaucracy.