Каталоги навыков и MCP-серверов: чтобы команда не строила одно и то же дважды

За две недели вышло несколько новостей об одном: как хранить инструкции и подключения для AI-инструментов, чтобы вся команда брала одну проверенную версию. Camunda выпустила каталог одобренных блоков, Workato показал MCP-сервер, который обновляет себя сам, HubSpot и Google разложили навыки по полочкам. Для владельца бизнеса вопрос простой: у кого в компании лежит «как мы делаем вот это» и кто отвечает, когда это меняется.

Что вышло

Camunda 21 октября описала Catalog в Camunda Hub на примере вымышленного банка. У организации один каталог, в него центр компетенций публикует проверенные блоки: запрос в кредитное бюро, проверка личности, проверка по санкционным спискам, уведомление клиента. Команды берут блок из меню в редакторе процессов и добавляют свои шаги до и после. Жизненный цикл блока живёт в git: коммит, проверка, версия, CI публикует в каталог. Центр компетенций видит, какой проект на какой версии, и перед выводом блока из оборота знает, кого это заденет. Выходит с Camunda 8.10.

Workato 20 октября рассказал про свой MCP-сервер для Google Workspace. Семь приложений Google (Gmail, Drive, Calendar, Docs, Sheets, Slides и Contacts) доступны через один инструмент с двумя помощниками вместо семи серверов с десятками описаний в контексте модели. Больше тысячи действий лежат на стороне сервера и подбираются по фразе без модели в цепочке. Раз в день сервер обходит каталог Google с описанием всех эндпоинтов, новую возможность прогоняет в песочнице на тестовом аккаунте, а потом три модели в ролях судьи, несогласного и арбитра решают, выпускать её или нет.

HubSpot 14 октября опубликовал разбор, чем отличаются навыки, плагины и MCP-коннекторы в Claude. Формула простая: коннектор это доступ к внешнему сервису, навык это процедура словами, плагин это упаковка для всей команды. Навык без коннектора работает, но не видит живые данные.

Google 13 октября обновил сроки запуска навыков: навыки в приложении Gemini раскатываются с 13 октября до середины ноября, а навыки в Workspace, обещанные к 12 октября, отложены без новой даты. Это к вопросу, стоит ли строить рабочий процесс команды на функции, у которой ещё нет даты.

Red Hat 16 октября объявила о выходе MCP-шлюза в составе Connectivity Link 1.5: изоляция шлюза и серверов между командами, сессии без состояния, поддержка промптов и ресурсов, ограничители для MCP. Это корпоративный масштаб, но суть та же: кто-то должен управлять тем, к каким инструментам у агента есть доступ.

Зачем это бизнесу

Возьмём прокат автомобилей с тремя менеджерами. У каждого свой шаблон договора в Word, свой текст письма клиенту и своя памятка, что проверять при возврате машины. Когда меняется цена страховки, её правят в одном шаблоне из трёх. Это и есть «построить одно и то же трижды», только без AI.

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

Как это у меня

В PDR-компании в США, где я с 2021 года технический партнёр, проекты мы согласуем втроём: собственник, второй постоянный разработчик и я. Дальше у каждого проекта свой владелец. Второй разработчик ведёт AppSheet, за мной сервер, сеть, телефония, API и сайт. Каталога как продукта у нас нет, но принцип тот же: у каждой части есть человек, который отвечает за её версию.

Правила для инструментов, которые помогают мне в коде, удобно держать рядом с кодом, в том же репозитории, как и документацию. Тогда они переходят заказчику вместе с кодом и базой, и систему может подхватить другой разработчик. На своём сайте в октябре 2026 года я добавил llms.txt и страницу фактов для AI-ассистентов, чтобы ассистент не придумывал, что я делаю и на каких условиях. Цифр по эффекту у меня нет.

Среди заказов на Upwork вокруг Google Sheets в 2021–2025 годах была и совсем прикладная версия каталога: перенос готовых шаблонов таблиц в новые, с 2022 по 2025 год. Шаблон это тот же проверенный блок, и вопрос всегда один: какая версия правильная.

Workato и Camunda я у себя не проверял. Самообучающийся MCP-сервер я бы ставил только с журналом: что и когда он добавил сам и кто это посмотрел.

Что я бы сделал

Начал бы с перечня: какие инструкции, шаблоны и подключения команда использует каждый день.

У каждой записи назначил бы владельца и место хранения: для технических вещей git, для инструкций команде общий документ с историей изменений.

Разделил бы доступ и процедуру, как в разборе HubSpot: подключение к CRM и правило «как мы оформляем заявку» меняются с разной скоростью.

Новую запись пропускал бы через проверку на реальной заявке, как Workato гоняет канарейку в песочнице. Раз в квартал смотрел бы, что в каталоге никто не использует, и убирал.

Связанные материалы

Как описать правила процесса для сотрудников и инструментов, я разбирал в статье Бизнес-логика: правила, статусы и права. Подход: AI в процессе, где результат можно проверить и автоматизация процесса от заявки до следующего действия. Кейсы: технический партнёр PDR-компании в США и Google Sheets и Apps Script: заказы на Upwork. Из обзоропо той же теме: как я делю работу с AI-агентом, почему я строю на бесплатных инструментах и что я разрешаю агенту на боевом сервере. Раньше: где у готового коннектора начинается логика процесса. Если инструкции и шаблоны вашей команды живут в трёх местах, расскажите, какие меняются чаще всего. Обсудить задачу.