AI-порталAI-портал

Agent Delegation Boundaries в 2026: что агент может делегировать, а что обязан довести сам

Agent delegation boundaries в 2026: как задавать границы делегирования между агентами и subprocess-ами, чтобы система не теряла ответственность, context ownership и контроль над risky tasks.

Agent delegation boundaries в 2026 нужны потому, что multi-agent orchestration быстро размывает ответственность. Главный агент может делегировать поиск, анализ, verification, draft generation или tool execution другим агентам, но без явных границ система теряет контроль: никто уже не понимает, кто владел risky decision, кто отвечает за final state и какой контекст можно было передавать дальше. Делегирование начинает выглядеть как умная архитектура, но operationally превращается в потерю ownership.

Delegation boundary — это правило, которое определяет, какие задачи агент может передать другому агенту или subprocess-у, а какие должен удержать у себя или эскалировать человеку.
Самый вредный anti-pattern - разрешать агенту делегировать всё, что угодно, только потому, что технически он умеет делать handoff.

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

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

  1. Какие задачи можно делегировать
  2. Какие решения неделегируемы
  3. Какой context можно передавать дальше
  4. Кто остаётся owner-ом конечного outcome
  5. Как контролируется nested delegation

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

  • delegation не должен размывать final ownership;
  • risky decisions лучше не передавать бесконечно по цепочке;
  • context sharing должен иметь scope;
  • nested delegation требует budget и limits.
Без техники
Агент делегирует risky кейс дальше, и в конце никто не понимает, кто отвечал за итоговое решение.
С техникой
Search и enrichment делегируются, но final decision ownership остаётся у исходного agent или у human approval path.
ПромптDelegation-boundary intuition
Почему агенту нельзя разрешать бесконтрольное делегирование?
Ответ модели

Потому что вместе с задачей могут потеряться ownership, authority limits и контроль над тем, кто именно принимает важные решения.

1. Делегировать лучше capability-specific work, а не authority

Хорошо делегируются:

  • retrieval and search;
  • synthesis drafts;
  • format conversion;
  • isolated checks;
  • low-risk tool prep.

Плохо делегируются:

  • policy exceptions;
  • final approvals;
  • authority-sensitive actions;
  • escalation ownership;
  • boundary decisions themselves.

2. У delegation должен быть clear return contract

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

  • что именно должен вернуть sub-agent;
  • в каком формате;
  • без каких действий он не имеет права завершать сам;
  • какие assumptions надо явно отметить.

Без return contract handoff быстро размывается.

Если у delegated task нет чётко описанного deliverable и owner-а final decision, это почти наверняка не delegation, а потеря управления задачей.

3. Context boundary не менее важен, чем task boundary

Нужно ограничивать:

  • tenant data scope;
  • sensitive policy context;
  • approval state;
  • temporary capability tokens;
  • irrelevant historical noise.

Иначе delegation несёт не только пользу, но и лишний риск.

4. Nested delegation должен иметь budget

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

  • max depth of delegation;
  • max delegated retries;
  • max sub-agent count per case;
  • max time spent in delegated state.

Это снижает orchestration sprawl.

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

Delegation of final authority

Рискованное решение уезжает слишком далеко от исходного owner-а.

No return contract

Сабагент не знает, где его граница.

Unlimited nested delegation

Цепочка handoff-ов разрастается.

Context oversharing

Вниз уходит больше данных, чем нужно.

Final ownership disappears

Никто не держит outcome end-to-end.

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

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

  • delegation rate by task type;
  • nested delegation depth;
  • cases with lost ownership signal;
  • sub-agent retries;
  • final decisions made after delegated branches;
  • incidents involving over-delegation.

Плюсы

  • Delegation boundaries сохраняют ownership в multi-agent system
  • Помогают безопасно делить работу по capability
  • Снижают orchestration sprawl
  • Ограничивают ненужную передачу sensitive context

Минусы

  • Нужно описывать task classes и return contracts
  • Слишком жёсткие границы могут мешать полезному parallelism
  • Nested delegation сложно наблюдать без хорошей telemetry
  • Часть серых кейсов трудно формализовать заранее

Пример delegation policy

delegation:
  allowed_tasks: [search, enrichment, format_conversion]
  forbidden_tasks: [final_approval, policy_exception_resolution]
  max_depth: 2

Простой guard

def may_delegate(task_type):
    return task_type in {"search", "enrichment", "format_conversion"}

Практический совет: зрелая agent orchestration отдельно отвечает на вопрос "что можно делегировать ради эффективности?" и "что нельзя делегировать без потери контроля?".

Проверьте себя

1. Что особенно важно сохранить при delegation?

2. Какой anti-pattern особенно вреден?

3. Что полезно ограничивать в nested delegation?

Источники

  1. OpenAI Agents SDK - Handoffs
  2. OpenAI Agents SDK - Tools
  3. OpenAI API Docs - Evaluation best practices
  4. OWASP Top 10 for LLM Applications
Предыдущая
Agent Capability Scoping в 2026: как ограничивать, что агенту вообще разрешено уметь
Следующая
Agent Escalation Ownership в 2026: кто отвечает за кейс после того, как агент передал его дальше