Ваш следующий инженер по интеграциям может оказаться ИИ-агентом
Разработчик, который сейчас отлаживает вашу интеграцию с API, вероятно, делает это не в одиночку. Он использует совместное программирование с Claude в Cursor, или просит Copilot объяснить вашу схему аутентификации, или поручает ChatGPT разобрать формат полезной нагрузки вебхука. Их помощник на основе ИИ пытается понять вашу платформу — и в большинстве случаев он действует вслепую.
Это проблема невидимого пользователя. Самая быстрорастущая категория потребителей знаний о вашей платформе — это не люди, просматривающие справочный центр. Это ИИ-агенты, работающие от имени человека — и они не видят большую часть того, что вы создали.
Как мы оказались здесь, не заметив этого
За последние восемнадцать месяцев кое-что изменилось, и большинство B2B-платформ все еще этого не замечают.
Разработчики перестали читать документацию так, как она была задумана. Старый рабочий процесс — открыть документацию в новой вкладке, найти нужный endpoint, прочитать параметры, вернуться в редактор и написать код — уступает место более быстрому методу. Разработчик, работающий в Cursor, задает вопрос: «как работает аутентификация сессии в этом API?» и ожидает точного ответа, не покидая редактор. Архитектор решений просит Claude сравнить возможности геозон у трех платформ и ожидает обоснованный ответ, а не вымысел.
Люди по-прежнему принимают решения. Но они делегировали поиск знаний ИИ-агентам. И эти агенты сталкиваются со стеной: большая часть знаний о платформе скрыта за интерфейсами, рассчитанными на человеческое восприятие. Статические справочные центры. Страницы Swagger, требующие браузера. PDF-файлы, которые нужно скачивать. Чат-боты, доступ к которым возможен только на определенном URL.
Знания существуют. Но они недоступны инструментам, которые все чаще их потребляют.
Протокол, который меняет ситуацию
Model Context Protocol — MCP — появился в Anthropic в конце 2024 года как стандартный способ для инструментов ИИ напрямую обращаться к внешним источникам знаний. Через несколько месяцев его поддержала OpenAI. Затем последовал Google. К концу 2025 года MCP был передан в Linux Foundation через Agentic AI Foundation при поддержке всех крупных AI-лабораторий.
Скорость внедрения о многом говорит. Это не была функция одного вендора, а реакция индустрии, осознавшей, что ИИ-агентам нужен стандартизированный способ получать авторитетную информацию — не путем сканирования веб-страниц и не опираясь на данные обучения, которые могут быть устаревшими на месяцы, а напрямую, в реальном времени, из самого источника.
Для платформ MCP меняет вопрос доступности. Если ваш API сделал вашу функциональность программируемой, то MCP делает ваши знания программируемыми. Теперь ИИ-агент может обращаться к вашей документации с той же прямотой, с которой скрипт вызывает ваш API — при условии, что вы сделали эти знания доступными через протокол.
Большинство платформ пока этого не сделали.
Знания как компонуемый слой
Существует концепция дизайна, которая позволяет предсказать, какие платформы безболезненно адаптируются к этому сдвигу, а какие столкнутся со сложностями.
В Navixy мы придерживаемся принципа компонуемой телематики — представления о том, что платформа должна быть набором модульных взаимосвязанных блоков, а не монолитным приложением. API для программного доступа. Вебхуки для обработки событийных сценариев. White-label интерфейсы для кастомизации партнерами. Каждый слой расширяет охват платформы, не требуя от пользователей оставаться внутри экосистемы вендора.
MCP — это продолжение той же логики, но применительно к самим знаниям.
Представьте это в виде уровней. Традиционная телематическая платформа дает вам UI для работы, API для разработки, и справочный центр для обучения. Первые два доступны машинам — другое ПО может ими пользоваться программно. Третий — нет. Это веб-сайт, рассчитанный на человеческое чтение.
MCP превращает этот третий уровень во что-то, к чему может обратиться ИИ напрямую. Документация перестает быть местом, куда нужно идти, и становится живым, компонуемым ресурсом — доступным там, где выполняется работа, и в любом инструменте, который используют люди.
Мы уже это внедрили. Вся документация Navixy — справочник по API, руководства по интеграции, описание возможностей платформы — доступна через MCP для Claude Desktop, Cursor и любых совместимых инструментов. Разработчик, подключающийся к нашему сервису трекинга, получает параметры endpoint прямо в своем редакторе. Маркетинговая команда партнера, проверяющая описание функционала, получает ответ на основе документации прямо в своем редакторе. Сервисный инженер, отвечающий на технический вопрос клиента, получает авторитетный ответ без переключения вкладок.
Но самое интересное не в том, что мы сделали. Важно то, как это высвечивает выборы в архитектуре.
Проблема монолитных знаний
Платформы, спроектированные так, чтобы контролировать весь пользовательский опыт, сталкиваются со структурной сложностью при обеспечении доступности ИИ — и это та же самая сложность, с которой они сталкиваются при расширении API, настройке вебхуков и предоставлении возможностей партнерам.
Когда ваша архитектура предполагает, что пользователи будут работать только в вашем интерфейсе, структура знаний оптимизирована под этот интерфейс. Справочный центр организован для людей, которые просматривают категории. Документация структурирована по меню продукта. Поиск адаптирован под человеческие запросы через браузер.
Сделать такие знания доступными для ИИ невозможно просто «прикрутив» дополнительную функцию. Необходимо раскрыть внутренние структуры знаний для внешнего потребления, к которому они не были приспособлены. Это архитектурное изменение, и для монолитных платформ оно обходится дорого — не потому что технология сложна, а потому что изначальные допущения глубоко укоренены.
Компонуемые платформы не сталкиваются с этой проблемой настолько остро. Там, где архитектура по умолчанию ориентирована на внешнее потребление — когда партнеры используют ваши API, интеграторы расширяют ваши workflows, а white-label внедрения кастомизируют интерфейс — предоставление знаний во внешнем доступе является логичным следствием, а не сменой философии.
Та же закономерность проявляется в API, в интеграции устройств, в партнерских экосистемах. Принятые годы назад архитектурные решения об открытости и модульности приносят всё больше преимуществ в новых контекстах. MCP — просто очередной такой контекст.
Вопрос, который следует задать своей платформе
Если вы TSP и выбираете платформенных партнеров — или вообще, если вы B2B-покупатель, оценивающий технические платформы — добавьте этот пункт в свой список критериев:
Может ли ИИ-агент автономно работать с документами этой платформы?
Не через чат-бот, который ищет в справочном центре. Не через веб-скрапинг, который может выдать устаревшие данные. А через прямой доступ по протоколу к проверенной и актуальной документации.
Ответ на этот вопрос многое расскажет об архитектуре платформы. Те, кто уже сегодня могут сказать «да», изначально были ориентированы на внешнюю доступность. Те, кто не могут — демонстрируют отношение к открытости, которое проявится и во многих других аспектах, от дизайна API до поддержки партнеров и гибкости интеграции.
Разработчик, работающий с ИИ-помощником в IDE, никуда не исчезнет. Архитектор решений, использующий Claude для сравнения платформ, продолжит это делать. Сервисный инженер, который просит ИИ-инструмент найти нужную документацию, тоже никуда не исчезнет. Эти рабочие процессы развиваются еще быстрее.
Платформы, доступные в рамках этих процессов — которые можно обнаружить, запросить и понять средствами ИИ-агентов — получают возрастающее преимущество. Те, которые остаются невидимыми для ИИ-агентов, все больше становятся невидимы и для людей, которым они помогают.
У вашей платформы появилась аудитория, которую вы не планировали. Вопрос в том, встретите ли вы ее.
Документация Navixy доступна через MCP по адресу https://www.navixy.com/docs/~gitbook/mcp — совместимо с Claude Desktop, Cursor и любыми MCP-совместимыми инструментами. Узнайте больше о философии компонуемой телематики, которая делает это логичным развитием, а не просто новой функцией.