Cohere предлагает заставить дублирующих ИИ-агентов соревноваться за место в компании

Cohere 15 октября 2026 года опубликовала в корпоративном блоге материал о том, что происходит, когда сотрудники начинают сами создавать ИИ-агентов, а центральной команды для контроля над ними нет. Автор текста, старший архитектор решений Kasim Patel, описывает типичную картину: агентов становится много, никто не знает полный список, команды не могут найти уже готовое, а доступ к корпоративным данным и системам всё труднее контролировать. Такое состояние он называет agent sprawl. Рецепт компании: не пытаться подавлять дубли, а заставить их соревноваться.

Статья одновременно служит витриной для North 2, защищённой агентной платформы Cohere, которая работает рядом с данными заказчика. Подтверждающих цифр, например доли дублирующихся агентов или экономии, в тексте нет. Это скорее рамка для рассуждения, чем исследование.

Рост числа агентов ещё не проблема

Patel сразу снимает главное опасение. Платформы, из-за которых возникает sprawl, делают эксперименты дешёвыми. Сотрудникам не нужно каждый раз идти в центральную команду по ИИ или разработке: те, кто ближе всего к процессу, лучше видят, что в нём можно автоматизировать. Удачный агент одной команды может подойти другой, и тогда распространение агентов говорит о том, что люди активно ищут применения.

Отдельно разобран вопрос затрат. Агент, которым никто не пользуется, не потребляет токены только потому, что существует. Рост числа агентов не обязательно увеличивает счёт за инференс. Нагрузка появляется, когда процессы управления не поспевают за количеством агентов. Именно тогда proliferation превращается в sprawl.

Три модели и реестр

Сегодня компании в основном выбирают из трёх схем:

• централизованная: центральная команда строит агентов и отвечает за них. Контроль жёстче, но темп инноваций ниже;
• федеративная: бизнес-подразделения владеют разработкой и эксплуатацией, а центр даёт инфраструктуру, стандарты и шаблоны управления;
• гибридная: ответственность делится между центром и бизнесом под общими стандартами.

Во всех трёх случаях всё чаще появляется реестр агентов. Он фиксирует владельца, использование и права доступа, а сотрудникам помогает находить то, что уже построено. Логика понятна: сначала переиспользуй, потом создавай. Меньше пересекающихся вариантов для выбора, меньше агентов для мониторинга и аудита.

Но у принципа «никаких дублей» есть цена. Если само существование рабочего агента закрывает путь альтернативам, организация не узнает, что можно сделать дешевле, надёжнее или точнее под конкретную задачу.

Претендент против действующего агента

Cohere предлагает считать дублирование временным. Если у команды есть убедительные основания полагать, что она улучшит «действующего» агента, ей разрешают построить «претендента». Но он остаётся в работе только при наличии измеримого преимущества. Для этого нужно сравнение, ограниченное по времени и основанное на данных. Набор метрик зависит от сценария, а в качестве примеров названы:

• надёжность;
• расход токенов;
• задержка ответа.

В доступном фрагменте текста список обрывается, так что полный перечень критериев и детали процедуры здесь не раскрыты.

Как применить на практике

Идея проверяется без покупки платформы. Во-первых, заведите реестр с владельцем, правами доступа и статистикой использования для каждого агента. Без него сравнивать нечего. Во-вторых, определите заранее, что считается преимуществом: например, меньше токенов на задачу при той же надёжности. В-третьих, ставьте срок: пилот без дедлайна быстро превращается в ещё одного постоянного агента. В-четвёртых, определите, что происходит с проигравшим: его отключают, архивируют или объединяют с победителем.

Отдельный вопрос, который статья не освещает: кто платит за параллельную работу двух агентов во время теста и как сравнивать их на реальных, а не удобных данных. Эти детали определят, станет ли модель инструментом отбора или ещё одним слоем бюрократии.