Патерн Supervisor Agent: контроль політик і ризиків

Суть патерна

Supervisor Agent - це патерн, у якому окремий агент контролює виконання: перевіряє запропоновані дії, застосовує правила і вирішує, чи можна продовжувати.

Коли потрібен: коли критичні дії треба окремо схвалювати за політиками перед продовженням.

Замість того, щоб безумовно довіряти виконавцю, Supervisor:

• перевіряє кожну критичну дію
• порівнює її з політиками
• повертає рішення: схвалити, доопрацювати, заблокувати або ескалювати
• фіксує причину рішення в логах

Проблема

Уяви, що агент-виконавець виконує задачу в проді та має доступ до інструментів.

Він пропонує технічно валідну дію, яка порушує політику:

• лист не тій аудиторії
• SQL-запит із ризиком зміни даних
• витрати понад бюджет
• доступ до чутливих даних без потрібного обсягу доступу

Технічно можливий крок не завжди є дозволеним або безпечним для бізнесу.

Без окремого контролю це може пройти прямо у виконання.

Наслідки:

• інциденти в проді
• порушення безпеки та комплаєнсу
• непередбачені фінансові втрати
• слабкий аудит і складний післяінцидентний розбір

У цьому й проблема: виконавець може запропонувати дію, яка "працює технічно", але є неприйнятною за політиками.

Рішення

Supervisor додає шар контролю політик між пропозицією дії і виконанням.

Аналогія: це як технічний рев'ю перед запуском у прод. Виконавець пропонує крок, а наглядач перевіряє, чи він безпечний і допустимий. Тільки після цього дію можна виконувати.

Ключовий принцип: Спочатку перевірка і рішення наглядача, потім виконання.

Виконавець пропонує дію, а supervisor-policy повертає:

• схвалити
• доопрацювати
• заблокувати
• ескалювати

Керований процес:

1. Спостереження: отримати пропозицію дії від виконавця
2. Оцінка: перевірити за політикою + станом середовища виконання
3. Рішення: схвалити/доопрацювати/заблокувати/ескалювати
4. Застосування: виконати, повернути на правку або зупинити
5. Логування: зафіксувати рішення і причину

Це дає:

• менший ризик небезпечних дій до виконання
• неможливість обійти політику
• контрольовану ескалацію до людини
• прозорий аудит рішень

Працює добре, якщо:

• виконавець не має прямого обходу шару виконання
• policy перевіряє намір + runtime-контекст
• рішення supervisor реально примусово застосовуються
• високоризикові дії не схвалюються автоматично

Модель може "хотіти" виконати крок одразу, але саме supervisor-policy визначає, чи дія взагалі дозволена.

Як працює

Supervisor не виконує бізнес-задачу сам.

Він контролює, чи можна виконувати наступний крок, перевіряючи:

• безпека
• бюджет
• доступи
• комплаєнс
• stop conditions

У коді це виглядає так

proposal = worker.next_action(context)

decision = supervisor.review(
    action=proposal,
    budget_state=budget_state,
    policy=policy,
)

if decision.type == "approve":
    result = execute(proposal)
    context.append(result)
elif decision.type == "revise":
    context.append(f"Supervisor feedback: {decision.reason}")
elif decision.type == "escalate":
    wait_for_human_approval(proposal)
else:
    stop(reason=decision.reason)

Supervisor не замінює Worker Agent. Він додає перевірку між планом і виконанням.

Як це виглядає під час виконання

Goal: оформити повернення коштів клієнту

Пропозиція від Worker (worker proposal):
- refund 5000 USD
- send confirmation email

Supervisor:
- policy check: auto-refund дозволено лише до 1000 USD
- рішення: ескалювати (escalate), потрібне підтвердження людини

Human approval (часткове схвалення / approve with changes):
- approved_refund_amount: 800 USD
- comment: "Схвалюю повернення лише в межах 800 USD"

Виконання (execution):
- refund 800 USD (сума з рішення людини)
- send confirmation email

Статус: виконано

Коли підходить — і коли ні

Підходить

Не підходить

Бо Supervisor додає додатковий крок перевірки і може сповільнювати виконання.

Чим відрізняється від Guarded-Policy

Коротко: Supervisor - наглядовий шар для складних рішень.

Guarded-Policy - це автоматичний барʼєр за правилами.

Коли використовувати Supervisor (vs інші патерни)

Використовуйте Supervisor, коли потрібен нагляд і policy-check перед фінальним результатом або ризиковою дією.

Короткий тест:

• якщо потрібно "перевіряти політики, комплаєнс і ризики" -> Supervisor
• якщо потрібно "лише керувати порядком кроків" -> Orchestrator Agent
• якщо потрібно "автоматично блокувати/переписувати дії ще до виконання" -> Guarded-Policy Agent

Як комбінувати з іншими патернами

• Supervisor + ReAct: Supervisor перевіряє кожний Act-крок перед запуском інструменту.
• Supervisor + Routing: контролюється не лише дія, а й те, кому саме задача була маршрутизована.
• Supervisor + Orchestrator: політики і ліміти застосовуються до кожної паралельної гілки, а не тільки до фінального результату.

Коротко

Переваги та Недоліки

FAQ

Q: Чи замінює Supervisor інфраструктурні дозволи (RBAC, ACL)?
A: Ні. Це додатковий логічний контроль. Базові технічні обмеження мають залишатись в інфраструктурі.

Q: Що робити, якщо Supervisor надто часто блокує корисні дії?
A: Уточнюють політики: додають винятки, рівні ризику та правила підтвердження людиною для сірих сценаріїв.

Q: Чи може Supervisor бути єдиною точкою відмови?
A: Так, якщо не передбачити резервний сценарій. Тому зазвичай додають timeout, безпечну політику за замовчуванням і режим плавної деградації.

Що далі

Supervisor контролює, щоб окремі агенти не виходили за межі політик.

А що робити, коли кілька агентів мають взаємодіяти між собою над спільною задачею?