Agent Authority Boundaries в 2026: где заканчивается право агента решать самому

Короткая версия

Хорошие authority boundaries в 2026 обычно определяют:

1. Какие решения агент принимает сам
2. Какие решения требуют approval
3. Какие решения всегда остаются человеческими
4. Как authority зависит от risk и context
5. Как boundary проверяется в runtime

Что особенно важно

• authority и capability — разные вещи;
• confidence не заменяет полномочность;
• boundary должен зависеть от action class, а не только от модели;
• у спорных кейсов должен быть ясный escalation path.

Почему capability не равен authority?

1. Authority нужно моделировать отдельно от tool access

Полезно различать:

• can observe;
• can recommend;
• can prepare action;
• can execute with approval;
• can execute autonomously.

Так система не прыгает сразу от ability к full autonomy.

2. Boundary должен учитывать тип решения

Например:

• low-risk formatting change;
• customer-visible communication;
• money movement;
• policy exception;
• cross-tenant or compliance-sensitive action.

Эти классы почти никогда не требуют одинаковой authority.

3. Boundary должен быть runtime-check, а не только документ

Полезно проверять:

• risk class;
• required approval state;
• actor type;
• degraded mode;
• evidence sufficiency.

Так authority enforcement не зависит от памяти команды.

4. Authority boundary должен быть понятен reviewer-ам и операторам

Иначе типовые проблемы такие:

• reviewer не понимает, что агент уже мог сделать сам;
• агент эскалирует слишком много;
• оператор override-ит там, где не должен;
• incident postmortem не может найти policy mistake.

5. Что особенно часто ломают команды

Capability implies authority

Доступ к tool воспринимается как право решения.

Confidence implies authority

Высокая уверенность модели заменяет policy.

No action classes

Все решения считаются одинаковыми.

Boundary not enforced

Политика есть, но runtime не проверяет её.

No escalation ownership

Непонятно, кому передавать boundary-crossing case.

6. Какие метрики полезны

Полезно считать:

• actions blocked by authority policy;
• boundary-crossing attempts;
• approvals required by action class;
• over-escalation rate;
• incidents involving authority mismatch;
• manual overrides of authority checks.

Пример authority policy

authority:
  refund_under_20:
    autonomous: true
  refund_over_20:
    autonomous: false
    requires_approval: true

Простой boundary check

def can_decide(case):
    return case["action_class"] == "low_risk" and case["approval_state"] == "not_required"

Практический совет: зрелая agent system отдельно отвечает на два вопроса: "умеет ли агент это сделать?" и "имеет ли он право это решить?".