AI-Ops kit для операційного відділу компанії

В одному абзаці

Операційний відділ середньої компанії раніше витрачав більшу частину робочого дня лише на те, щоб відповісти на одне бізнесове питання: вручну зшивав докупи дані з CRM для продажів, служби підтримки, трекера задач розробників, аналітичного сховища, платіжної системи, BI-звітів і автоматизацій, які все це між собою з’єднують. Цей набір замінює біганину між системами однією розмовою. Оператор питає людською мовою; потрібний скіл (у Claude Code так називають готову інструкцію під один тип задач) підбирається сам; три субагенти-спеціалісти паралельно шукають відповідь; запис для аудиту з’являється сам, і пам’ятати про нього не треба. Разом це 15 корпоративних скілів, що дістають до 6 систем, і 3 субагенти, зібрані самотужки приблизно за 3 тижні. Тепер вони передані команді як завершений каталог із чіткими правилами, а не шухляда одноразових скриптів.

Проблема мовою бізнесу

Дані відділу живуть у восьми різних місцях, і в кожного свій логін, своя мова запитів і свої примхи. Будь-яке справжнє бізнесове питання – чому це число різне на двох дашбордах? де застрягло повернення грошей цьому клієнту? що в мене насправді в роботі перед нарадою? – змушує зазирнути у дві-три з цих систем і вручну звести відповіді докупи. До появи набору на таке зведення йшло кілька сесій і години часу. Оператори, які не мали власного способу працювати зі ШІ, просто передавали питання інженерам, а ті ставали вузьким місцем навіть для рутини.

Чим це відрізняється від «просто поставити кілька MCP»

Більшість команд, які прикручують ШІ до операційки, зупиняються на MCP-конекторах: поставили конектор до CRM, поставили конектор до чату, віддали Claude паролі й ключі – і сподіваються на краще. Одному користувачеві з простими питаннями цього вистачає; другого користувача чи першого аудиту така схема вже не витримує. Цінність набору – не в окремому скілі, а в трьох субагентах-спеціалістах, яким головна сесія роздає роботу. Питання, яке треба розглянути з кількох боків, не тягнеться в одній довжелезній розмові: Claude паралельно відправляє на пошуки аналітика сховища, агента CRM і агента служби підтримки; кожен підвантажує лише ті довідники, що стосуються його ділянки, і кожен повертається зі звітом. Саме завдяки цій паралельності набір працює як тямущий аналітик, а не як бот, який довго думає й забуває, про що ви питали. І головне: жоден субагент не отримує нових доступів – кожен має рівно ті права, що вже є в оператора.

Ще два рішення, завдяки яким набір безпечно віддати всій команді, менш помітні. Перше: паролі й ключі ніколи не проходять через модель. Кожен скіл бере свій ключ доступу із системного сховища паролів (keychain) у момент запуску й використовує його локально, тож якщо завтра запис сесії кудись витече, жоден секрет не витече разом із ним. Серед тих, хто вбудовує ШІ в операційку, про цей прийом сьогодні говорять найменше. Друге: на початку файлу з інструкціями кожного скіла стоїть блок RACI – так велить шаблон, а не добра воля автора. Тож коли через пів року скіл дасть хибну відповідь, хто за нього відповідає, буде записано у файлі, а не в чиїйсь пам’яті.

Через розділення читання й запису скілів, які треба підтримувати, стає вдвічі більше, і це слушне заперечення. Але таке розділення окупається двічі: завдяки автоматичним перевіркам (лінтеру) заготовка скіла на запис коштує майже нічого, а гарантія «оператор не може випадково змінити робочу систему» – саме те, що дозволило набору вийти за межі одного ноутбука й дійти до команди.

Три питання за одну сесію

Три буденні питання оператора, одне за одним. Кожне стосується іншої ділянки бізнесу, і кожне агент доводить до кінця: розбирається, вирішує, виконує, перевіряє. Кожен сценарій закінчується рядком success. Привітання праворуч лишається на місці, поки ви гортаєте сторінку, а кожна сцена нижче підхоплює наступне завдання, щойно доходить до середини екрана.

Каталог

Для кожної системи є пара скілів: один читає, другий змінює дані, і той, що змінює, завжди має всі додаткові запобіжники з таблиці вище. Над ними стоять три службові скіли: один створює заготовки нових скілів, другий допомагає новому операторові почати роботу, третій оновлює датовані довідки всередині інших скілів.

На трьох субагентах – warehouse-analyst, crm-agent, desk-agent – і тримається цінність набору. Кожен із них – спеціаліст, який лише читає: підвантажує тільки свої довідники, працює у власному окремому контексті, щоб не захаращувати головну розмову, і повертає знахідки головному агентові. Жоден не отримує нових прав – кожен працює в межах доступу, який уже має оператор. Ще три конектори – до платіжної системи, командного чату й допоміжної бухгалтерської системи – уже продумані, але свідомо не ввійшли в першу версію. Додати будь-який із них тепер – механічна робота зі службовим скілом, а не задача на проєктування. Архітектура готова.

Одна перевірка на вході в каталог

Кожен новий скіл чи субагент проходить цей список, перш ніж його приймуть. Механічні пункти перевіряє лінтер, решту – люди, які переглядають зміни.

1. Корисний щонайменше двом людям – помічники для однієї людини лишаються особистими, поза корпоративним набором.
2. Має названого власника – блок RACI на початку файлу інструкцій, без винятків.
3. Відповідає шаблону – усі обов’язкові розділи на місці, жодних позначок TODO, а коли вмикати скіл, описано звичайною мовою.
4. Безпечний за замовчуванням – спершу лише читання; жодна незворотна операція не відбудеться без підтвердження.
5. Без секретів – це перевіряють лінтер і окреме завдання в CI, яке шукає секрети.
6. Без конфліктів назв – назва у форматі area-verb у каталозі одна-єдина.
7. Описано, що робити при збої – як поводиться скіл, коли API повертає помилку, сплив термін доступу чи на вхід прийшли пошкоджені дані.

Правило лінтера, що захищає команду, спершу лише попереджає і стає жорсткою забороною тільки тоді, коли кілька справжніх скілів успішно з ним попрацювали в реальній роботі. Правила ростуть разом із каталогом, а не біжать попереду нього: свою суворість вони заслуговують, а не проголошують.

Журнал аудиту у двох реченнях

Кожен скіл, що звертається до однієї з робочих систем, обгорнутий у

@telemetered(
  skill="warehouse-read",
  operation="query",
  outcome_map={0: "ok", 1: "error", 2: "auth_expired"},
  extras=lambda result, args: {"sql_preview": args.sql[:200]},
)
def cmd_query(args): ...

– він записує, який скіл запустився, у якій системі, з якими параметрами, чим закінчився і скільки тривав, і відправляє ці записи в центральне сховище логів. Довіру до нього тримають дві властивості: відправка не плодить дублікатів (сесія, що втратила з’єднання на півдорозі, пізніше повторить спробу, але жоден запис не прийде двічі) і нічого не гальмує (якщо сховище логів недоступне, записи чекають у локальній черзі, а сесія оператора працює далі).

Для бізнесу це повна історія того, хто, коли й про що питав ШІ, у якій системі і з яким результатом. На ній тримається довіра до набору, коли ним користуються масово, і з неї почнеться будь-яка майбутня розмова про відповідність вимогам (комплаєнс).

Чого більше не буває

Користь від набору найкраще видно з того, що перестало відбуватися: оператори більше не стоять у черзі до інженерів із рутинними питаннями, а відповіді приходять уже зведеними й уже записаними. Оператор, який працює з набором щодня, сказав це краще за будь-яку метрику: «Тут нічого не треба налаштовувати; він сам робить усе, що може, а коли йому справді потрібен я, це один простий крок зі зрозумілою інструкцією. Кожна відповідь гарно структурована – усе розкладено по поличках». Це і є вся мета задуму, тільки словами користувача: механізму не видно, видно судження, і операторові ніколи не доводиться думати, як усе влаштовано всередині.

~3 тижні. Одна людина. 15 скілів, 3 субагенти, 6 систем. Відповідь, яку раніше цілий день збирали з кількох систем, тепер готова за хвилини: зведена, записана й достатньо безпечна, щоб довірити набір усій команді.

Цей кейс – про архітектуру й підходи. Конкретних постачальників, адреси серверів і самого клієнта свідомо не названо; тут важить устрій системи – одна розмова поверх багатьох систем із правилами, яким команда може довіряти, – а не те, у кого що купували.