Агентный лок-ин: почему AI-агенты привязывают вас к вендору

За последний год почти каждый крупный вендор представил своего агента: OpenAI показала Operator и режим agent-действий в ChatGPT, Anthropic выпустила Claude с инструментом Computer Use, Google встраивает агентские сценарии в Gemini, Microsoft строит Copilot Studio и агентов внутри Microsoft 365. Все они умеют примерно одно: не просто отвечать текстом, а выполнять цепочки действий — открывать приложения, заполнять формы, вызывать инструменты, дергать корпоративные системы. И почти у всех есть общая черта, о которой в презентациях говорят меньше всего: агент живёт внутри экосистемы вендора и тянет вас туда же.

Это и есть агентный лок-ин — привязка не на уровне отдельной модели, которую можно поменять за пару строк в конфиге, а на уровне рабочих процессов, коннекторов и памяти агента. Проблема не новая по своей природе, но у агентов она глубже, чем у обычных API языковых моделей.

Чем лок-ин на агентах отличается от лок-ина на модели

Ещё год-два назад сменить поставщика LLM было относительно просто. Вы дергали HTTP-эндпоинт, получали текст, а промпты и логика жили в вашем коде. Появились слои-абстракции вроде LiteLLM и роутеров, которые позволяли переключать GPT на Claude или открытую модель, меняя одну переменную.

С агентами так не выйдет. Агент — это не только модель. Это ещё и:

• набор инструментов и коннекторов к вашим системам (почта, CRM, база, браузер);
• формат описания этих инструментов, специфичный для платформы;
• память и состояние сессий, где хранится контекст пользователя;
• механизм оркестрации — как агент планирует шаги, вызывает подагентов, обрабатывает ошибки;
• слой безопасности и разрешений, привязанный к аккаунту вендора.

Когда вы построили рабочий процесс на Copilot Studio или на агентах внутри одной облачной платформы, переезд означает переписывание коннекторов, перенос памяти, повторную настройку прав и повторное тестирование всех сценариев. Стоимость переключ也^* растёт не линейно, а с каждым добавленным инструментом.

^* Стоимость переключения (switching cost) — совокупные затраты времени, денег и рисков, которые вы понесёте при переходе с одного поставщика на другого. Чем она выше, тем сильнее лок-ин.

Где именно вас держат

Проприетарные форматы инструментов

У каждого вендора свой способ объявить агенту, какими инструментами он может пользоваться. Anthropic и часть индустрии продвигают открытый Model Context Protocol (MCP) — стандарт подключения внешних источников и инструментов к модели. Но реализация MCP-серверов и глубина поддержки у разных платформ различаются, а часть вендоров держит собственные закрытые механизмы коннекторов, которые работают только внутри их продукта.

Память и состояние

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

Оркестрация мультиагентных систем

Когда несколько агентов делят задачу между собой, логика их взаимодействия описывается инструментами платформы. Перенести такую систему к другому вендору — это фактически спроектировать её заново.

Раньше вы выбирали модель. Теперь вы выбираете экосистему — и это решение с гораздо более длинным хвостом последствий.

Сравнение подходов вендоров

Ниже — грубая карта того, как устроена привязка у крупных игроков. Конкретные возможности и названия продуктов меняются часто, поэтому детали сверяйте с официальной документацией.

Общий вывод из таблицы: чем плотнее агент вплетён в остальные продукты вендора (почту, диск, облако), тем удобнее он в моменте и тем дороже потом уезжать.

Что можно сделать, чтобы не запереться

Полностью избежать привязки не выйдет — она обратная сторона удобства. Но снизить её реально.

1. Отделяйте логику от платформы. Держите описание бизнес-процессов, промпты и правила в своём коде или конфигах, а не только в интерфейсе вендора.
2. Предпочитайте открытые протоколы. Там, где выбор есть, коннектор через MCP переносится легче, чем закрытый механизм платформы.
3. Экспортируйте память регулярно. Уточните у вендора, что именно попадает в экспорт, и храните копию у себя.
4. Считайте стоимость переключения заранее. На этапе пилота прикиньте, сколько будет стоить переезд к конкуренту через год.
5. Тестируйте на двух вендорах. Если критичный процесс работает хотя бы у двух поставщиков, вы сохраняете рычаг на переговорах о цене.

Кому это пригодится, а кому нет

Стоит серьёзно закладываться на защиту от лок-ина, если вы:

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

Можно не переживать, если вы:

• используете агента для личных задач или разовых экспериментов;
• автоматизируете один-два простых сценария, которые несложно перенастроить с нуля;
• уже стандартизированы на одной экосистеме (например, весь офис в Microsoft 365) и переезд в принципе не рассматриваете.

Лок-ин — не всегда зло. Иногда глубокая интеграция даёт такую экономию времени, что осознанная зависимость оправдана. Плохо, когда за неё платят по незнанию.

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