Управління multi-agent системами: координація, дозволи й контроль ескалацій

Ідея за 30 секунд

Multi-agent governance — це runtime-контроль координації між агентами: хто власник підзадачі, хто може делегувати, коли зупиняти handoff-ланцюг.

Коли це потрібно:
коли в одному workflow працюють кілька агентів і є ризик дубльованих дій, конфліктів ролей або неконтрольованого fan-out.

Проблема

Без governance multi-agent система швидко переходить у режим хаосу: агенти делегують одне одному задачі, дублюють виклики і витрачають спільний бюджет без фінального прогресу. У demo це часто виглядає "живо". У production це перетворюється на затримки, зайві витрати і нестабільний результат.

Типові наслідки:

• одна підзадача має кількох власників
• handoff-ланцюг росте без завершення
• shared budget витрачається на дублікати

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

І кожна хвилина без правил координації збільшує ризик каскадного збою між агентами.

Рішення

Рішення — додати централізований policy layer для multi-agent orchestration у runtime. Кожна делегація проходить перевірку: role ownership, handoff limits, shared budgets і approval gate для ризикових дій.

Для runtime потрібна єдина модель outcomes:

• allow
• stop
• approval_required

Типові stop reasons у multi-agent контурі:

• ownership_conflict
• handoff_budget_exceeded
• delegation_depth_exceeded
• shared_budget_exceeded

Це не порада моделі, а примусовий контроль виконання перед кожною новою делегацією.

Multi-agent governance ≠ orchestration

Це різні шари системи:

• Orchestration визначає маршрут задач між агентами.
• Governance обмежує цей маршрут policy-правилами.

Одне без іншого не працює:

• без orchestration немає керованого workflow
• без governance orchestration легко деградує в дублікати, конфлікти і loop-и

Приклад:

• orchestration: planner -> researcher -> writer
• governance: max_handoffs=8, max_depth=3, ownership_lock=true

Компоненти multi-agent governance

Ці компоненти працюють разом на кожному handoff між агентами.

Приклад alert:

Slack: 🛑 Multi-Agent run run_742 stopped: ownership_conflict, handoff=planner -> researcher, task=refund_check.

Як це виглядає в архітектурі

Multi-agent policy layer стоїть у orchestrator runtime loop між плануванням і делегуванням підзадач. Кожне рішення (allow або stop) фіксується в audit log. Це логічний policy-шар у runtime, а не окремий сервіс.

approval_required для ризикових write-дій обробляється окремим approval flow поверх цього контуру.

Кожен handoff проходить через цей flow перед виконанням:

• orchestrator runtime формує наступну підзадачу
• policy перевіряє owner, handoff budget, delegation depth і shared budgets
• allow -> підзадача передається конкретному агенту
• stop -> orchestrator runtime переходить у fallback (single-agent або обмежений режим виконання)
• обидва рішення пишуться в audit log

Приклад

planner делегує refund_check агенту researcher, але ця підзадача вже має owner=billing_agent. Policy повертає stop (reason=ownership_conflict).

Результат:

• делегація не виконується
• run не розростається в дублікати
• у логах видно конфлікт власника і причину зупинки

Multi-agent governance зупиняє інцидент до fan-out, а не після втрати бюджету.

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

У спрощеній схемі вище показано основний flow. Критично: перевірка має працювати централізовано, інакше агенти обходитимуть ліміти через паралельні handoff-и.

Приклад policy-конфігурації:

multi_agent:
  max_agents_per_run: 4
  max_handoffs: 8
  max_delegation_depth: 3
  shared_max_usd: 30
  shared_max_tool_calls: 120
  require_approval_for:
    - billing.refund.create

task = orchestrator.next_task(state)
decision = multi_agent_policy.check(task, state)

audit.log(
    run_id,
    phase="pre_handoff",
    decision=decision.outcome,
    reason=decision.reason,
    owner=decision.owner,
    from_agent=task.from_agent,
    to_agent=task.to_agent,
    depth=state.delegation_depth,
)

if decision.outcome == "approval_required":
    # approve/resume flow логується окремим кроком:
    # approval_required -> approval_granted -> allow
    return stop("approval_required")

if decision.outcome == "stop":
    return stop(decision.reason)

result = orchestrator.delegate(task)

shared_budget.consume(
    usd=result.cost_usd,
    tool_calls=result.tool_calls,
)

post_budget_decision = shared_budget.check()
if not post_budget_decision.ok:
    audit.log(
        run_id,
        phase="post_handoff",
        decision="stop",
        reason=post_budget_decision.reason,
        owner=decision.owner,
        handoff_status=result.status,
    )
    return stop(post_budget_decision.reason)

audit.log(
    run_id,
    phase="post_handoff",
    decision=decision.outcome,
    reason=decision.reason,
    owner=decision.owner,
    handoff_status=result.status,
)

return result

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

Сценарій 1: ownership conflict

1. planner формує делегацію refund_check.
2. Policy бачить, що owner підзадачі вже закріплений за іншим агентом.
3. Рішення: stop (reason=ownership_conflict).
4. Handoff блокується до виконання.
5. Конфлікт фіксується в audit log.

Сценарій 2: перевищення handoff budget

1. Run вже зробив 8 передач підзадач.
2. Наступна делегація перевищує max_handoffs.
3. Рішення: stop (reason=handoff_budget_exceeded).
4. Runtime переходить у fallback mode.
5. Система не входить у нескінченний delegation loop.

Сценарій 3: нормальний керований handoff

1. Runtime формує нову підзадачу з валідним owner.
2. Policy перевіряє всі ліміти: все в межах.
3. Рішення: allow.
4. Делегація виконується і повертається результат.
5. Події pre_handoff і post_handoff пишуться в audit trail.

Типові помилки

• запускати кілька агентів без role ownership map
• дозволяти handoff без ліміту глибини і кількості
• рахувати бюджети окремо для кожного агента, а не shared для run
• не мати fallback при stop
• логувати тільки фінальний результат без історії делегацій
• змішувати orchestration правила і governance правила в prompt

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

Самоперевірка

Швидка перевірка multi-agent governance перед запуском у production:

FAQ

Q: Коли multi-agent підхід дійсно виправданий?
A: Коли підзадачі реально незалежні й мають різну експертизу. Якщо workflow лінійний і короткий, один агент часто простіший і надійніший.

Q: Хто має приймати фінальне рішення: orchestrator чи окремий агент?
A: Краще один відповідальний orchestrator/policy layer. Інакше зростає ризик конфліктів і "пінг-понгу" між агентами.

Q: Чи можна агентам напряму делегувати без policy check?
A: Для production — ні. Кожен handoff має проходити централізовану перевірку ownership, лімітів і бюджету.

Q: Як рахувати бюджет у multi-agent run?
A: Як shared бюджет для всіх агентів разом. Інакше кожен агент окремо "в межах", а сумарно run виходить за ліміти.

Q: Multi-agent governance замінює step limits і rate limiting?
A: Ні. Він доповнює їх: керує координацією між агентами, а step/rate controls керують поведінкою виконання.

Де Multi-Agent Governance у загальній системі

Multi-agent governance — це рівень Agent Governance для orchestrated команд агентів. Разом із RBAC, budget controls, approval, rate limiting і audit він формує контрольований runtime для складних workflow.

Пов'язані сторінки

Далі за темою:

• Огляд Agent Governance — базова модель governance у production.
• Step limits — як зупиняти loop до інциденту.
• Rate limiting для агентів — як контролювати піки зовнішніх викликів.
• Human approval — як підтверджувати ризикові дії.
• Audit logs для агентів — як відновлювати ланцюг handoff-рішень.