Мультиагентная оркестрация

«Multiagent orchestration» (мультиагентная оркестрация) позволяет одному агенту координировать работу других агентов для выполнения сложных задач. Агенты могут действовать параллельно, каждый со своим изолированным контекстом. Это помогает повысить качество результата и может сократить время выполнения.

Не уверены, подходит ли мультиагентная конфигурация для вашей задачи? См. статью когда использовать мультиагентные системы (и когда не стоит).

Передача работы другим агентам

Агент, которого запускает сессия, может передавать работу другим агентам двумя способами. С помощью «subagents» (субагентов) он сам делегирует задачи и читает отчёты каждого субагента. С помощью «dynamic workflows» (динамических рабочих процессов) он пишет рабочий процесс: программу, которая запускает множество агентов в фоновом режиме и объединяет их результаты. Кроме того, он может консультироваться с «advisor» (моделью-советником), выполняя работу самостоятельно.

Вы решаете, что из этого может использовать агент, а агент определяет, когда это использовать. Чтобы направить этот выбор, укажите агенту в его системной подсказке, когда использовать запуск рабочего процесса. См. раздел Укажите агенту, когда использовать запуск. Вы также можете ограничить агента только теми агентами, которых вы перечислите.

При использовании субагентов агент сам определяет, что происходит дальше. Поток субагента остаётся доступным, пока вы его не заархивируете, поэтому агент может отправлять ему дополнительные сообщения. При использовании динамических рабочих процессов Claude пишет программу для оркестрации агентов без прямого участия Claude. Контекст и результаты программно передаются от одного агента к другому, освобождая основной поток сессии для общения с пользователем и проверки одного или нескольких выполняющихся рабочих процессов, чтобы сообщать о ходе работы. Агент не может отправлять дополнительные сообщения в потоки запуска, и сервер архивирует каждый из них к концу запуска.

Всё это настраивается в блоке multiagent определения агента; у этого блока есть type. С типом multiagent_20261001 агент может использовать все три подхода вместе, и вы можете включать или выключать каждый из них. По умолчанию subagents и workflows включены. У subagents и workflows включён параметр inline_agents — настройка для агентов, которых агент или рабочий процесс определяет сам:

{
  "multiagent": { "type": "multiagent_20261001" }
}

Чтобы задать, каких агентов может вызывать агент, см. раздел Предопределённые и встроенные агенты. Чтобы выключить настройку, см. раздел Включение динамических рабочих процессов.

Предопределённые и встроенные агенты

Каждый субагент и каждый агент в запуске рабочего процесса относится к одному из двух видов:

• «Predefined agent» (предопределённый агент): агент, которого вы уже создали и перечислили в блоке multiagent. Он использует собственную конфигурацию: модель, системную подсказку, инструменты, серверы MCP и навыки.
• «Inline agent» (встроенный агент): агент, который не сохранён. Его определяет агент, которого запускает сессия, или рабочий процесс при распределении работы. Он использует модель, инструменты, серверы MCP и навыки этого агента.

Оба вида работают как в subagents, так и в workflows:

subagents.predefined_agents и workflows.predefined_agents — это два отдельных списка. Агент из одного списка не добавляется в другой. По умолчанию оба списка пусты. Запись любого из списков принимает одну из следующих форм:

• {"type": "agent", "id": agent.id} ссылается на ранее созданного агента agent по ID. Если version не указана, ссылка закрепляется за последней версией агента в момент создания агента, в списке которого он указан, или когда обновление отправляет список.
• {"type": "agent", "id": agent.id, "version": agent.version} закрепляет конкретную версию агента.
• agent.id сам по себе, в виде строки, является сокращением для {"type": "agent", "id": agent.id}.
• {"type": "self"} добавляет в список самого агента, чтобы работу могли выполнять его копии. Если сессия была создана с переопределениями конфигурации агента, эти переопределения также применяются к этим копиям. Записи, на которые ссылаются по ID, не затрагиваются.

Правила для этих записей и для агентов, на которых они указывают, применяются к обоим спискам. См. раздел Перечисление субагентов.

Встроенные агенты по умолчанию включены в обеих настройках. Чтобы разрешить только перечисленных вами агентов, задайте для inline_agents значение {"type": "disabled"} в subagents, в workflows или в обоих. Настройке с выключенными встроенными агентами требуется хотя бы один агент в списке predefined_agents. При пустом списке запрос завершается ошибкой 400. При обновлении сервер проверяет настройки в том виде, в каком они будут после обновления.

Следующий агент разрешает только перечисленных им агентов. Он может делегировать работу одному агенту и копиям самого себя, а рабочий процесс может использовать версию 2 другого агента:

{
  "multiagent": {
    "type": "multiagent_20261001",
    "subagents": {
      "type": "enabled",
      "inline_agents": { "type": "disabled" },
      "predefined_agents": ["agent_01J8XkN5uT3vHpLqRfWdY2", { "type": "self" }]
    },
    "workflows": {
      "type": "enabled",
      "inline_agents": { "type": "disabled" },
      "predefined_agents": [
        { "type": "agent", "id": "agent_01Lm4cV8yQ2tNs7XbKdR5h", "version": 2 }
      ]
    }
  }
}

Делегирование субагентам

Что делегировать

Мультиагентная координация лучше всего подходит для сложных задач, которые либо требуют работы в самых разных областях, либо состоят из нескольких чётко очерченных задач, вносящих вклад в общую цель.

Хорошо работающие шаблоны:

• Распараллеливание: одновременно распределяйте независимые подзадачи (поиск по нескольким источникам, анализ отдельных файлов), а агент пусть синтезирует результаты.
• Специализация: направляйте работу агентам с предметно-ориентированными системными подсказками и инструментами, например агенту безопасности или агенту документации, вместо того чтобы наделять одного агента всеми возможностями.
• Эскалация: консультируйтесь с более способным агентом или моделью для части сложных подзадач. Чтобы консультироваться с моделью, предоставьте сессии советника.

Как это работает

Все агенты используют общую песочницу, файловую систему и учётные данные хранилища, но каждый агент работает в собственном «session thread» (потоке сессии) — изолированном по контексту потоке событий с собственной историей разговора. Агент, которого запускает сессия, сообщает о своей активности в «primary thread» (основном потоке), который является потоком событий уровня сессии. Дополнительные потоки создаются во время выполнения, когда он делегирует работу. Запуск рабочего процесса также создаёт потоки.

Поток субагента является постоянным. Агент может отправить дополнительное сообщение субагенту, которого вызывал ранее, и этот субагент сохраняет всё из своих предыдущих ходов.

Какую конфигурацию использует субагент, зависит от того, является ли он предопределённым или встроенным агентом. Переопределения конфигурации агента на уровне сессии применяются к агенту, которого запускает сессия, и к его копиям self. Каждый агент сохраняет собственную историю разговора.

Перечисление субагентов

При определении агента задайте список predefined_agents в subagents в блоке multiagent, чтобы перечислить агентов, которым он может делегировать работу:

ant apply engineering-lead.md reviewer.md test-writer.md

---
name: Engineering Lead
model: claude-opus-5-5
tools:
  - type: agent_toolset_20260401
multiagent:
  type: multiagent_20261001
  subagents:
    type: enabled
    predefined_agents: # ant apply replaces each path with {type: agent, id, version}
      - ./reviewer.md
      - ./test-writer.md
---

You coordinate engineering work. Delegate code review to the reviewer agent
and test writing to the test agent.

---
name: reviewer
model: claude-haiku-5-5
---

You are a code reviewer.

---
name: test-writer
model: claude-haiku-5-5
---

You write unit tests.

Агент также может делегировать работу встроенным агентам, если вы их не выключите. Об этой настройке и о формах, которые принимает элемент списка predefined_agents в subagents, см. раздел Предопределённые и встроенные агенты.

"advisor": {"type": "enabled", "model": "<model id>"} предоставляет основному потоку сессии советника, с которым он может консультироваться посреди хода. Советник — это настройка в блоке multiagent, а не элемент этого списка. См. раздел Предоставление сессии советника.

С этим типом динамические рабочие процессы также включены по умолчанию, поэтому этот агент может планировать крупную работу, которая запускает множество агентов в фоновом режиме. Чтобы выключить их или перечислить агентов, которых может использовать рабочий процесс, см. раздел Включение динамических рабочих процессов.

Следующие правила применяются к агентам, которых вы перечисляете в списке predefined_agents в subagents, а также к агентам, которых вы перечисляете в списке predefined_agents в workflows:

• Закрепление: конфигурация агента, включая список predefined_agents в subagents, фиксируется в виде снимка при создании или обновлении агента. Агенты, на которых есть ссылки, остаются закреплёнными за версиями, определёнными в тот момент, и не получают последующих обновлений своих определений. Обновление, которое не отправляет список, сохраняет уже закреплённые версии. Чтобы делегировать работу более новой версии агента, на которого есть ссылка, обновите агента так, чтобы список predefined_agents в subagents ссылался на эту версию.
• Один уровень: агент может делегировать работу только одному уровню агентов. Ссылка на другого агента, у которого задан multiagent, приводит к сбою запроса на создание или обновление с ошибкой валидации 400.
• До 20 агентов: список predefined_agents в subagents может содержать до 20 уникальных агентов. Ограничение действует для каждого списка отдельно: список predefined_agents в workflows также может содержать до 20 агентов. Агент может вызывать несколько копий каждого субагента в пределах ограничения на количество потоков сессии.
• География инференса: агент и каждый перечисленный вами агент — в списке predefined_agents в subagents или в workflows — должны закреплять одну и ту же географию инференса (inference_geo в model определения агента), либо ни один из них не должен её закреплять. Несоответствие в любом из списков отклоняется с ошибкой валидации 400. Эта проверка выполняется как при сохранении агента, так и когда переопределение при создании сессии изменяет любое из закреплений.

Создание сессии

Создайте сессию, ссылающуюся на агента. Агент по мере необходимости делегирует работу агентам, которых вы перечислили в списке predefined_agents в subagents. Он также может делегировать работу встроенным агентам, если вы их не выключите.

session = client.beta.sessions.create(
    agent=lead_agent.id,
    environment_id=environment.id,
)

Подключение агентов к серверам MCP

Серверы MCP привязаны к агенту: каждое определение агента объявляет собственные серверы и инструменты. У встроенного агента нет определения агента, поэтому он использует серверы MCP и инструменты агента, которого запускает сессия. Учётные данные хранилища привязаны к сессии: vault_ids, переданные при создании сессии, применяются ко всем потокам. Это имеет два следствия для вашей интеграции:

• Для аутентификации серверов MCP включите учётные данные хранилища для каждого сервера MCP, используемого любым из агентов.
• Чтобы ограничить доступ агента, объявите в его определении только те серверы, которые ему нужны. Встроенного агента так ограничить нельзя. Чтобы разрешить только перечисленных вами агентов, выключите inline_agents и в subagents, и в workflows и перечислите хотя бы одного агента в каждом из них. См. раздел Предопределённые и встроенные агенты.

Переопределения конфигурации агента при создании сессии могут заменить серверы MCP агента, которого запускает сессия, и серверы его копий self.

В среде типа limited создание сессии завершается ошибкой 400, если агент или агент, перечисленный вами в списке predefined_agents в subagents или workflows, объявляет сервер MCP, хост которого отсутствует в allowed_hosts. Установка allow_mcp_servers в значение true в сетевых настройках среды отключает эту проверку.

Создайте исследователя, который объявляет сервер MCP GitHub, и агента, который делегирует работу исследователю:

ant apply lead.md researcher.md

---
name: lead
model: claude-opus-5-5
tools:
  - type: agent_toolset_20260401
multiagent:
  type: multiagent_20261001
  subagents:
    type: enabled
    predefined_agents: # ant apply replaces each path with {type: agent, id, version}
      - ./researcher.md
---

---
name: researcher
model: claude-haiku-5-5
mcp_servers:
  - type: url
    name: github
    url: https://api.githubcopilot.com/mcp/
tools:
  - type: mcp_toolset
    mcp_server_name: github
---

Затем создайте сессию с хранилищем, содержащим учётные данные GitHub:

session = client.beta.sessions.create(
    agent=lead_agent.id,
    environment_id=environment.id,
    vault_ids=[vault.id],
)
print(session.id)

В этом примере сервер MCP GitHub объявляет только исследователь, поэтому у агента, которого запускает сессия, нет к нему доступа. vault_ids сессии предоставляют учётные данные GitHub потоку исследователя.

Потоки

У потока сессии каждого агента есть собственный поток событий. Чтобы получать список потоков, прерывать или архивировать их, читать их события и обрабатывать разрешения инструментов в них, см. раздел Потоки сессии.

Динамические рабочие процессы

С помощью динамических рабочих процессов агент может браться за работу из множества частей, например проверку сотен документов или перекрёстную проверку множества источников. Агент пишет «workflow» (рабочий процесс): программу, которая запускает множество агентов по фазам и объединяет то, что они возвращают. Сервер выполняет её в фоновом режиме как «workflow run» (запуск рабочего процесса), пока агент продолжает работать или завершает свой ход. Динамические рабочие процессы включаются и выключаются настройкой workflows в блоке multiagent агента. Агенты запуска могут работать одновременно, поэтому длительная задача может завершиться быстрее, чем если бы один агент выполнял каждую часть по очереди.

• Как начинается запуск: вы описываете работу в user.message. На основе этого агент определяет, начинать ли запуск и когда, поэтому дополнительный вызов API не нужен. Вместо этого вы влияете на решение агента, описывая, когда использовать запуск, в user.message или в системной подсказке агента. (Политики разрешений применяются к инструментам, которые вызывают агенты запуска, а не к началу запуска.)
• Каких агентов он использует: встроенных агентов, которых определяет рабочий процесс, предопределённых агентов, которых вы перечисляете в списке predefined_agents в workflows, или и тех, и других. Если вы никого не перечислите, рабочий процесс определит их всех сам. Встроенный агент использует модель агента, которого запускает сессия. Чтобы запуск мог использовать другую модель для некоторых своих агентов, создайте их как агентов и перечислите в списке predefined_agents в workflows.
• Как за ним следить: события запуска поступают в поток событий сессии, и каждый агент в запуске работает в потоке сессии, который вы можете найти в списке потоков, читать и получать в режиме потоковой передачи. О событиях, прерываниях, ограничениях и о том, что показывают потоки запуска, см. раздел Запуски рабочих процессов.

Включение динамических рабочих процессов

При определении агента задайте для multiagent.type значение "multiagent_20261001" и включите workflows. Для этого типа динамические рабочие процессы и делегирование (subagents) включены по умолчанию. Чтобы использовать только динамические рабочие процессы, добавьте "subagents": {"type": "disabled"}.

Прежде чем изменять multiagent.type существующего агента, ознакомьтесь с разделом о переводе агента на этот тип.

ant apply contract-reviewer.md

---
name: Contract Reviewer
model: claude-opus-5-5
tools:
  - type: agent_toolset_20260401
multiagent:
  type: multiagent_20261001
  workflows:
    type: enabled
---

You review contracts. When you're asked to review more than a few contracts, start a workflow run that reads them in parallel and combines the findings. Review one or two contracts yourself, without a run.

Чтобы рабочий процесс мог использовать уже созданных вами агентов, перечислите их в workflows.predefined_agents. Настройки subagents и advisor указываются в том же блоке multiagent. О том, как перечислить субагентов, см. раздел Делегирование субагентам. О том, как задать советника, см. раздел Предоставление сессии советника. Этот агент позволяет рабочему процессу использовать одного созданного вами агента, перечисляет двух субагентов и имеет советника:

{
  "multiagent": {
    "type": "multiagent_20261001",
    "workflows": {
      "type": "enabled",
      "predefined_agents": [{ "type": "agent", "id": "agent_01Lm4cV8yQ2tNs7XbKdR5h" }]
    },
    "subagents": {
      "type": "enabled",
      "predefined_agents": [
        { "type": "agent", "id": "agent_01J8XkN5uT3vHpLqRfWdY2" },
        { "type": "agent", "id": "agent_01HqR2k7vXbZ9mNpL3wYcT" }
      ]
    },
    "advisor": { "type": "enabled", "model": "claude-opus-5-5" }
  }
}

Каждая настройка включается или отключается независимо:

О том, что указывается в каждом списке, и о том, как разрешить только перечисленных вами агентов, см. раздел Предопределённые и встроенные агенты.

Учитывайте следующее:

• Обновление: обновление, сохраняющее тип multiagent_20261001, изменяет только то, что в нём отправлено:
  • Настройка или поле, которые вы не указали, сохраняют прежнее значение.
  • Настройка или поле, отправленные как null, принимают значение по умолчанию, как и всё, что находится внутри них, независимо от того, что было сохранено.
  • Отправленный вами список predefined_agents заменяет сохранённый список.
  • Настройка, отправленная с другим type, заменяет сохранённую настройку, а поля, которые вы в ней не указали, принимают значения по умолчанию.
  • Каждому отправляемому объекту нужен его type, а включённому advisor нужна его model.
• Отключение: задайте для workflows значение {"type": "disabled"}. Настройка остаётся отключённой, пока обновление снова её не включит. Отправка null включает её, поскольку по умолчанию она включена. То же относится к subagents.
• Существующие сессии: сессия копирует настройку при создании, поэтому последующее изменение агента не меняет уже существующую сессию.
• Агенты, которых можно перечислить: агента, у которого задан multiagent, нельзя указать как субагента другого агента или в списке predefined_agents настройки workflows другого агента. Агент может указать себя в любом из списков с помощью {"type": "self"}, что при чтении возвращается как его собственные id и version.
• Имена инструментов: префикс ant__ зарезервирован. Если у вашего агента уже есть пользовательский инструмент, имя которого начинается с ant__, обновление завершается ошибкой 400, пока вы не отправите tools без этого имени. Создание новой сессии также отклоняется с ошибкой 400, если у её агента или у агента в любом из списков есть такой инструмент. Переименуйте или удалите инструмент в том же обновлении, которое включает динамические рабочие процессы. См. раздел Пользовательские инструменты.
• Бюджет: задайте бюджет сессии при её создании, чтобы ограничить расходы сессии, включая запуски; добавить бюджет к существующей сессии нельзя. Запуски приостанавливаются, когда сессия достигает бюджета, а запуски, приостановленные бюджетом, возобновляются, когда вы увеличиваете или удаляете его, если только они не были также приостановлены прерыванием. См. раздел Стоимость и бюджеты.

Укажите агенту, когда использовать запуск

Включение динамических рабочих процессов даёт агенту возможность начинать запуски рабочих процессов. Агент сам определяет, когда начать запуск. Чтобы направлять этот выбор, добавьте в системную подсказку агента инструкцию, подобную следующей. Агент для проверки договоров из раздела Включение динамических рабочих процессов использует эту системную подсказку:

You review contracts. When you're asked to review more than a few contracts, start a workflow run that reads them in parallel and combines the findings. Review one or two contracts yourself, without a run.

Чтобы адаптировать её, назовите задачи в предметной области вашего агента, которые требуют запуска, и небольшие задачи, которые агент должен выполнять сам. Вы также можете указать, как запуск должен выполнять работу, как в этих примерах:

• Как разделить работу: «В запуске используй одного агента на каждый договор. Затем пусть второй агент проверит каждый договор, а не только те, в которых первый агент что-то нашёл, и поищет то, что первый агент упустил. Всё, что не прошло проверку, переделывается и проверяется снова».
• Что делать при сбое агента: «Сбой одного агента не должен приводить к сбою запуска. Если агенту не удалось прочитать договор, отметь этот договор как не охваченный. Когда запуск завершится, сообщи мне, какие договоры не были охвачены».
• Ограничение по времени: «Установи для запуска ограничение по времени в один час».
• Сначала план: «Прежде чем начать запуск, опиши его фазы и сколько агентов выполняется в каждой из них. Затем дождись моего одобрения». Шага утверждения перед началом запуска нет, поэтому ничто не обеспечивает выполнение этого требования.

Используйте запуски только для задач, которые в них нуждаются, поскольку каждый агент в запуске расходует токены.

Затем создайте сессию с агентом, как с любым другим агентом, и опишите работу в user.message. В этом сообщении вы также можете попросить о запуске.

О событиях запуска, прерывании сессии с открытыми запусками, о том, что меняется, пока запуск открыт, а также о бюджетах и ограничениях см. раздел Запуски рабочих процессов.

Предоставление сессии советника

Включённая настройка advisor в блоке multiagent агента даёт основному потоку сессии советника: модель, с которой он может консультироваться посреди хода для получения стратегических рекомендаций, например чтобы спланировать подход, выйти из тупика или проверить работу перед завершением. По умолчанию настройка отключена. Чтобы включить её, задайте для advisor значение {"type": "enabled", "model": "..."}, которое содержит ровно два поля: type и model:

ant apply backend-engineer.md

---
name: Backend engineer
model: claude-sonnet-5
multiagent:
  type: multiagent_20261001
  advisor:
    type: enabled
    model: claude-opus-5-5
---

You implement backend features end to end. Consult the advisor before major backend design decisions.

В этом примере задаётся только advisor. Две другие настройки, subagents и workflows, сохраняют значения по умолчанию, поэтому обе включены, и агент также может делегировать работу встроенным агентам и начинать запуски рабочих процессов. Для агента, который консультируется с советником и выполняет всю работу сам, задайте для обеих настроек значение {"type": "disabled"}.

Советника нельзя указать в списке predefined_agents настройки subagents или workflows. Включённый advisor резервирует имя anthropic.advisor. Пока он включён, ни один из списков не может содержать агента с именем, буквально равным anthropic.advisor: такой запрос отклоняется с ошибкой валидации 400.

Модель-советник должна соответствовать минимальному уровню возможностей, а собственная модель агента не должна быть более способной, чем её советник; модели с равными возможностями могут составлять пару. Недопустимая пара отклоняется с ошибкой валидации 400 при сохранении агента и повторно при создании сессии. Пара также проверяется в начале каждой консультации: если она больше не допустима, эта консультация завершается сбоем, а сессия продолжается. Допустимые пары соответствуют таблице совместимости моделей инструмента советника.

Советник также доступен как серверный инструмент в Messages API. Вариант для Managed Agents отличается конфигурацией и способом доставки: у настройки advisor нет полей max_uses, max_tokens или caching, а совет поступает через события потока, а не через блоки advisor_tool_result.

Как работают консультации

Каждая консультация выполняется как созданный платформой поток с именем anthropic.advisor, который сам завершается по окончании консультации, а совет доставляется в основной поток как событие agent.thread_message_received. Консультация генерирует стандартные события потока, идентифицируемые зарезервированным именем anthropic.advisor (события жизненного цикла потока содержат его как agent_name, а доставка совета — как from_agent_name), обычно в следующем порядке:

1. session.thread_created
2. session.thread_status_running
3. agent.thread_message_received (совет)
4. session.thread_status_idle (stop_reason: end_turn)
5. session.thread_status_terminated

Для консультации не генерируются события agent.tool_use, и в потоке событий сессии не появляется событие agent.thread_message_sent, поскольку входные данные консультации формируются платформой, а не отправляются агентом. Если вы запросите список собственных событий потока советника, совет также появится там как событие agent.thread_message_sent. Не гарантируется, что доставка совета (событие 3) произойдёт раньше событий простоя и завершения потока советника, поэтому не считайте их сигналом того, что совет уже доставлен.

Сможет ли ваш клиент прочитать совет, определяется политикой модели-советника. Она повторяет разделение на варианты результатов в инструменте советника Messages API. Модель-советник, которая возвращает там результаты в виде открытого текста, доставляет здесь читаемый текст. Модель, которая возвращает скрытые результаты, доставляет заполнитель [{"type": "redacted"}] на всех клиентских интерфейсах, при этом агент по-прежнему читает полный совет на стороне сервера. В предыдущем примере в качестве советника используется новейшая доступная вам модель Opus. Claude Opus 5.5 возвращает скрытые результаты, поэтому ваш клиент видит только заполнитель. Чтобы читать совет в потоке событий, используйте советника, который возвращает открытый текст, например Claude Opus 4.8. Политика модели может измениться без изменений в API, поэтому обрабатывайте как блоки text, так и блоки redacted. Некоторые модели агентов составляют пару только с советниками, возвращающими скрытые результаты; см. таблицу совместимости инструмента советника. Размышления советника никогда не раскрываются. Клиенты не могут сами отправлять блоки redacted; событие, содержащее такой блок, отклоняется с ошибкой валидации 400.

Неудачная или прерванная консультация никогда не приводит к сбою хода агента: агент продолжает работу после общего уведомления о том, что консультация не удалась. user.interrupt на уровне сессии во время консультации завершает поток советника без доставки совета; user.interrupt с session_thread_id потока советника прерывает только эту консультацию.

Потоки советника

Советник не является субагентом. Инструмент агента list_agents его не показывает, а send_to_agent, который отправляет субагенту дополнительное сообщение, не может к нему обратиться. Консультироваться с ним может только основной поток сессии; субагенты не могут.

На потоки советника не распространяется ограничение в 25 дочерних потоков. Они отображаются в списке потоков сессии. Их agent имеет форму советника, {"type": "advisor", "model": ...}, с настроенной вами моделью, а их parent_thread_id — это основной поток.

«Prompt caching» (кэширование подсказок) на стороне советника выполняется автоматически; настраивать ничего не нужно. Консультации оплачиваются по тарифам модели-советника, а их токены отображаются в использовании потока советника и в итоговых показателях использования сессии. Они также учитываются в бюджете сессии по прейскурантной цене модели-советника. Каждая консультация отправляет советнику весь разговор основного потока на текущий момент, поэтому консультации на поздних этапах длинной сессии расходуют больше входных токенов.

Удаление советника

Чтобы удалить советника, обновите агента, задав для advisor значение {"type": "disabled"}. У агента, который уже имеет тип multiagent_20261001, настройка, не указанная в обновлении, сохраняет прежнее значение, поэтому повторно отправлять subagents или workflows не нужно. По той же причине обновление, в котором не указан advisor, сохраняет советника. Прежде чем изменять multiagent.type существующего агента, ознакомьтесь с разделом о переводе агента на этот тип.

Переход с типа coordinator

Как и multiagent_20261001, тип coordinator позволяет агенту делегировать работу перечисленным вами субагентам и консультироваться с моделью-советником. С типом coordinator агент не может начинать запуски рабочих процессов или сам определять субагентов. API принимает оба типа.

Чтобы перевести агента на multiagent_20261001, обновите агента, указав блок multiagent этого типа:

1. Задайте для type значение "multiagent_20261001".
2. Перечислите агентов, которых может вызывать агент, в subagents.predefined_agents. Записи сохраняют свою текущую форму.
3. Если у агента есть советник, задайте для advisor значение {"type": "enabled", "model": "..."} с моделью советника.
4. Отправьте весь блок в одном обновлении.

Например, этот блок предоставляет агенту двух субагентов и советника:

{
  "multiagent": {
    "type": "multiagent_20261001",
    "subagents": {
      "type": "enabled",
      "predefined_agents": [
        { "type": "agent", "id": "agent_01J8XkN5uT3vHpLqRfWdY2" },
        { "type": "agent", "id": "agent_01HqR2k7vXbZ9mNpL3wYcT" }
      ]
    },
    "advisor": { "type": "enabled", "model": "claude-opus-5-5" }
  }
}

В этом блоке не указаны workflows и subagents.inline_agents, поэтому обе настройки принимают значения по умолчанию и включены. Переведённый агент также может начинать запуски рабочих процессов и сам определять субагентов. Чтобы оставить любую из этих возможностей отключённой, задайте для неё значение {"type": "disabled"} в том же обновлении. См. разделы Включение динамических рабочих процессов и Предопределённые и встроенные агенты.

Если у агента есть советник, но нет субагентов, задайте для subagents значение {"type": "disabled"}, чтобы делегирование оставалось отключённым. Запрос, который отключает subagents.inline_agents и не перечисляет ни одного агента, завершается ошибкой 400.

Обновление заменяет весь блок multiagent, поэтому отправьте список агентов и советника повторно, как в примере. То, что вы не укажете, принимает значение по умолчанию:

• subagents.predefined_agents: список пуст, поэтому агент теряет перечисленных вами субагентов.
• advisor: советник отключён.

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

Обновление не изменяет уже существующие сессии. Чтобы использовать новый блок, создайте сессию после обновления.