IT-команда выпускает бота для службы поддержки. Он работает, и людям он нравится. Через полгода HR-отделу требуется помощник по адаптации, и поскольку новым сотрудникам нужны ноутбуки и программное обеспечение, этот бот должен также взаимодействовать с ServiceNow. Затем операционному отделу требуется что-то, что открывает инциденты, когда срабатывает мониторинг в 3 часа ночи.

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

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

В этой статье мы проследим за одним IT-агентом в двух сценариях повторного использования и рассмотрим, что делает Redpanda Agentic Data Plane на каждом этапе.

Для тех, кто не знаком: Redpanda Agentic Data Plane — это унифицированный уровень управления, который опосредует доступ, информацию и надзор, необходимые агентам для выполнения реальной работы в вашей организации. Прочитайте, что такое агентная плоскость данных (agentic data plane), чтобы узнать больше.

Начните с IT Assist Agent

IT Assist Agent выполняет две вещи, о которых постоянно просят сотрудники:

Сообщает об инцидентах
Заказывает товары из каталога услуг

Вы говорите ему: «Мой VPN постоянно отключается» или «Мне нужна лицензия Figma» в Teams, и он берет на себя взаимодействие с ServiceNow. Он также выполняет поиск по базе знаний, что предотвращает появление некоторых тикетов до того, как они будут открыты.

По сути, это один агент с тремя субагентами: по одному для инцидентов, каталога и базы знаний. Оркестратор считывает запрос и передает его нужному субагенту.

В Redpanda Agentic Data Plane все это является конфигурацией, а не кодом. Агент управляется Redpanda, поэтому вы пишете системный промпт, выбираете модель и подключаете инструменты, а Redpanda Agentic Data Plane запускает его и ведет запись каждого выполнения. Каждый субагент получает свои собственные инструкции и свои собственные MCP-серверы (Model Context Protocol).

Часть ServiceNow обеспечивается управляемым MCP-сервером ServiceNow, который охватывает инциденты (создание, обновление, перевод, добавление рабочих заметок), поиск по базе знаний и процесс каталога: поиск элемента, чтение формы запроса и отправка заказа (search_catalog_items, get_catalog_item, submit_catalog_request). Redpanda размещает этот сервер, а учетные данные ServiceNow хранятся в хранилище секретов Redpanda. Агент их никогда не видит.

Здесь важны два аспекта управления, поскольку именно они делают этого агента безопасным для последующего совместного использования. Во-первых, Redpanda Agentic Data Plane авторизует каждое действие от имени человека, общающегося с агентом, поэтому агент может делать только то, что мог бы сделать сам сотрудник. Во-вторых, политики доступа могут разрешать или запрещать отдельные инструменты MCP для пользователя, группы или агента, и они применяются вне модели. Креативный промпт не сможет «убедить» систему выполнить вызов инструмента, который блокирует политика.

Повторное использование №1: адаптация сотрудников

Теперь HR-команде нужен помощник по адаптации для новых сотрудников и их менеджеров. Новым сотрудникам нужно видеть свои задачи с 1-го по 90-й день, которые хранятся в Workday, а также находить политики и страницы команд в SharePoint. Им также нужны ноутбук, доступ к ПО и помощь, если VPN не подключится в их первое утро.

Последняя часть — это уже работа IT Assist Agent, поэтому HR-команда просто вызывает его, вместо того чтобы создавать заново. Для всего остального команда создает двух собственных специалистов: HR Tasks Agent для Workday и Docs Agent для SharePoint.

Каждый агент Redpanda публикует «карточку агента» по известному URL, в которой перечислены его навыки и объясняется, как пройти аутентификацию. HR-команда создает свой оркестратор адаптации на любом фреймворке, который предпочитает, и регистрирует его в Redpanda Agentic Data Plane как самоуправляемого агента. Регистрация требует заранее указать, каких агентов и инструменты может вызывать оркестратор, включая IT Assist. С этого момента оркестратор считывает карточку IT Assist и отправляет ему запросы через A2A (протокол Agent2Agent). IT продолжает владеть и улучшать IT Assist. HR-команде никогда не нужно изучать ServiceNow.

Workday и SharePoint — это новые системы, и ни одна из них сегодня не имеет управляемого типа MCP в Redpanda Agentic Data Plane. Есть два пути. Управляемый тип OpenAPI берет спецификацию OpenAPI 3.0 и генерирует один инструмент MCP на операцию без написания кода. Или, если команда уже использует сервер MCP для любой из систем, Redpanda Agentic Data Plane может выступить в качестве фронтенда и применить те же аутентификацию, политики и наблюдаемость, которые применяются ко всему остальному.

Что мне нравится в этом дизайне, так это то, что адаптация не ждет, пока новый сотрудник поздоровается. Когда Workday регистрирует наем, событие попадает в топик Redpanda. Конвейер Redpanda Connect подхватывает его и вызывает оркестратор через процессор a2a_message, поэтому новый сотрудник получает приветственное сообщение, а менеджер — чек-лист до первого дня, без необходимости кому-либо вводить промпт.

Разговоры об адаптации полны персональных данных, и Redpanda Agentic Data Plane позволяет каждому управляемому агенту решать, сколько данных хранить. Полные транскрипты, только метаданные или вообще ничего. Команда может отслеживать время и использование токенов для операций, не сохраняя содержание разговоров.

Идентификация сохраняется по всей цепочке. Поскольку MCP-сервер ServiceNow настроен на User OAuth, ServiceNow видит нового сотрудника как запрашивающую сторону, а не как учетную запись бота, и одобрения менеджеров работают так же, как и до создания агента.

Повторное использование №2: сортировка оповещений без окна чата

Рассмотрим операционную команду. Инструменты мониторинга создают штормы оповещений. Инструменты MDM (управление мобильными устройствами) помечают ноутбуки, которые вышли из соответствия требованиям. Никто не хочет копировать все это в чат.

Триггером здесь является событие. Конвейер Redpanda Connect считывает оповещения из топика с помощью входного адаптера redpanda и передает каждое из них агенту по сортировке (снова самоуправляемому) через a2a_message. Агент по сортировке сворачивает шторм дубликатов в одну проблему, запрашивает у Docs Agent соответствующий регламент (runbook), а затем просит IT Assist Agent открыть инцидент в ServiceNow и связать затронутый элемент конфигурации из CMDB (база данных управления конфигурациями). Результат возвращается в топик, например, ops.incidents.created, откуда его забирают инструменты для дежурных и дашборды.

IT Assist понятия не имеет, что его вызвал конвейер, а не человек, и ему это не нужно. Те же инструменты, те же политики. Единственное отличие — идентификация. Поскольку за запросом не стоит человек, вызов выполняется под собственной сервисной идентификацией конвейера, поэтому вы предоставляете этой идентификации ровно то, что нужно для сортировки. Инструменты для инцидентов — да. Заказы из каталога — нет.

Создавайте один раз, компонуйте многократно

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

Владение остается за командой, которая знает предметную область. IT владеет IT Assist. Команда People владеет агентами HR Tasks и Docs. Теги для каждого агента позволяют распределять расходы на LLM по командам или средам, поэтому не возникает споров о том, в чей бюджет засчитываются вызовы ServiceNow от бота для онбординга.

Когда IT выпускает IT Assist v1.4, его получают все пользователи, и никому больше не нужно менять ни строчки кода. А поскольку определения агентов можно управлять через GitOps с помощью rpk ai apply, изменения в общем агенте проходят проверку, как и любые другие изменения в продакшене.

Ограничители (guardrails), политики доступа и бюджеты находятся на шлюзе и применяются к каждому проходящему через него вызову. Бюджеты устанавливаются для каждого агента. Как только агент достигает своего лимита на период, шлюз отклоняет его следующий запрос к LLM до сброса периода, а перед этим срабатывает пороговое предупреждение.

Наблюдаемость делает повторное использование безопасным

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

Redpanda Agentic Data Plane фиксирует происходящее на двух уровнях. Транскрипты предоставляют доступ к просмотру каждого запуска агента только для чтения: каждый промпт, ответ и вызов инструмента, а также использование токенов, статус, длительность и временную шкалу, по которой можно перемещаться. Ниже находятся трассировки OpenTelemetry с выборкой 100%.

AI Gateway и каждый управляемый агент и сервер MCP автоматически записывают данные в топик redpanda.otel_traces в неизменяемом логе Redpanda. Самоуправляемые агенты, такие как оркестратор онбординга, экспортируют свои спаны в конечную точку OTLP (OpenTelemetry Protocol) среды, используя соглашения OpenTelemetry GenAI. Все это попадает в одно место, и вы можете проанализировать отдельный вызов инструмента MCP с полной временной шкалой, повторно запустить выполнение для оценки или материализовать все данные в таблицы Apache Iceberg™ для долгосрочного хранения.

Таким образом, команда онбординга может проследить за диалогом в IT Assist и увидеть, что запрос в Figma превратился в RITM0012345 и ожидает одобрения менеджера, а инцидент с VPN был открыт от имени конкретного нового сотрудника. Это больше, чем просто удобство. Повторная отправка заявок в каталог ServiceNow небезопасна, так как второй вызов создает второй запрос, который кому-то придется отменять. Возможность подтвердить, что первый вызов прошел успешно, прежде чем кто-либо попытается сделать это снова, избавляет от реальной необходимости исправлять ошибки.

Для конвейера оповещений те же записи служат аудиторским следом. Каждый автоматизированный тикет отслеживается до оповещения, которое его вызвало, — именно это потребуют показать такие стандарты, как ISO/IEC 42001 и EU AI Act.

Создайте своего первого (повторно используемого) агента

Выберите то, что постоянно переделывают несколько команд. Для многих компаний это IT-запросы, но для вас это могут быть поиск клиентов или статус заказа. Создайте это один раз как управляемого агента, опубликуйте его карточку и позвольте следующей команде вызывать его, а не копировать.

Чтобы попробовать, ознакомьтесь с этими ресурсами: