Представьте себе разработчика, который вместо «GET /users» пишет: «Ну покажи уже, сколько у нас клиентов, я домой хочу» — и это… работает. Звучит как шутка из чата тимлида, но именно туда сейчас и движется реальная архитектура корпоративных систем.

Десятилетиями мы подстраивались под софт. В 80‑х учили grep и ls, потом заучивали REST‑эндпоинты, в 2010‑х прятались за SDK. Логика была одна: машины дают строго формализованные функции, люди обязаны говорить на их языке. С появлением мощных LLM ситуация разворачивается: теперь интерфейсом становится наш язык, а код учится понимать намерения.

Язык вместо эндпоинтов

Модель вроде GPT не просит вас помнить billingApi.fetchInvoices(customerId=…). Вы говорите: «Покажи все счета “Ромашке” с января и выдели просроченные», — модель сама разруливает: что такое «Ромашка», где лежат счета, какие сервисы дергать и как собрать ответ.

Эту идею аккуратно оформляет Model Context Protocol (MCP) — абстракция, которая дает моделям три ключевые вещи:

  • Открытие возможностей: не фиксированный список функций, а каталог «что вообще умеет компания».
  • Интерпретацию намерений: сопоставление фразы человека с нужными инструментами.
  • Оркестрацию: последовательные вызовы, фильтры, преобразования — без участия пользователя.

Инженеры Akamai уже называют это переходом к «языко‑ориентированной интеграции», а академические работы по агентным воркфлоу подчеркивают: архитектура API для людей и архитектура API для агентов — это две разные архитектуры.

Архитектура, заточенная под намерения

В MCP‑подходе ключевой вопрос меняется с «какой метод вызывать?» на «какие намерения вообще возможны?». Отсюда новые требования:

  • Capability‑метаданные: нормальные описания «что делает сервис» человеческим языком.
  • Семантическая маршрутизация: выбор нужного инструмента по смыслу запроса.
  • Контекстная память: чтобы «сделай как в прошлый раз, но для Европы» имело смысл.
  • Guardrails: аутентификация, логирование, разграничение прав и аудит, чтобы разговорчивый агент не оказался слишком любопытным.

Без этого язык как интерфейс превращается в лотерею: либо модель промажет по системе, либо вы отдаете ей слишком много власти без контроля.

Новые роли и старая проблема «слишком много софта»

Для предприятий MCP — не про игрушечные чат‑боты. Это ответ на хаос из сотен внутренних систем. Пользователю не нужно знать ни схем, ни параметров, ни очередности вызовов — он формулирует цель. В маркетинге это уже видно: простая фраза «дай выручку за прошлый квартал по регионам и отметь аномалии» заменяет SQL, выгрузки и Excel‑макросы.

Из этого вырастают новые профессии:

  • Онтологические инженеры — задают «словари вселенной» компании.
  • Архитекторы возможностей — разбивают бизнес на четкие capability‑поверхности.
  • Специалисты по агентам — регулируют поведение, тестируют сценарии, настраивают безопасность.

У России тут отличный задел: сильная школа математики и системного инжиниринга исторически учит мыслить категориями моделей и онтологий, а не только CRUD‑таблицами. Именно такие специалисты нужны, чтобы MCP‑слой работал не на слайдах, а в проде.

Что делать сегодня

Практический чек‑лист для руководителей:

  1. Считайте естественный язык интерфейсным слоем, а не дополнительной «фичей».
  2. Опишите бизнес‑воркфлоу, которые безопасно отдать на язык (поддержка, аналитика, поиск).
  3. Проинвентаризируйте существующие сервисы: какие возможности можно оформить как capabilities.
  4. Запустите пилот MCP‑уровня на одном домене — например, triage обращений клиентов.
  5. Стройте вокруг этого управление и аудит: логи, доступы, метрики качества.

Интерфейсы уже сменили CLI, затем API, затем SDK. Следующий слой — естественный язык, а MCP становится тем каркасом, который позволяет компаниям не утонуть в этой свободе. Вопрос «какой API вызвать?» постепенно превращается в архаизм. Гораздо важнее другое: «чего мы на самом деле хотим добиться — и готовы ли мы доверить это своим системам?»