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

Цей посібник розповідає, як передати роботу зі своїх плечей агенту, і що відбувається, коли агенти передають роботу одне одному.

Передати тікет агенту

Створіть тікет із заголовком і описом, достатньо точним, щоб за ним можна було працювати.
Укажіть агента в полі Виконавець, щоб власність була зафіксована.
Відкрийте (або створіть) простір і @-згадайте цього агента.
Посилайтеся на тікет згадкою # у своєму повідомленні — редактор повідомлень автодоповнює тікети робочого простору — і скажіть, що саме потрібно зробити.

Агент бере роботу з розмови. Його поступ потоково надходить у цей простір.

Що отримує агент

Ваше повідомлення, зокрема посилання на тікет, який ви позначили.
Простір, у якому працювати й звітувати.
Ізольований worktree з пов’язаних репозиторіїв робочого простору.
Режим простору — саме він визначає набір інструментів запуску.

Режим — це властивість простору, а не тікета — тікет режиму не має. Тож один агент може бути в chat в одному просторі й у plan в іншому. Виберіть його зі списку режимів у редакторі повідомлень (Agent, Plan або Orchestrate); review встановлюють простори перевірки PR, і його не можна вибрати. Див. Режими.

Вимагати структурований результат

Контракт виводу оголошується на запуску, а не на тікеті: expected_output_schema разом з output_contract_mode (типово strict). Агент виконує його, викликаючи submit_output, який перевіряє вміст на відповідність схемі й відхиляє невідповідний.

І прийнятий вивід, і будь-які відхилення потрапляють до журналу запусків агента. Статус самого тікета це не зачіпає — невдалий контракт не провалює тікет.

Стежити за поступом

Простір — активність агента в реальному часі, основний вигляд.
Тікет — його статус, такий, яким його встановить той, хто його переміщує.
Спостережуваність → Наживо (/workspaces/<workspace-id>/observability) — живий реєстр агентів.
Спостережуваність → Інсайти — журнал запусків, із вартістю та тривалістю.

Екрана панелі керування немає; голий URL робочого простору переспрямовує до вхідних.

Дозволити агентам делегувати одне одному

Агент, який натрапив на підпроблему, делегує її інструментом MCP delegate_task. Той створює дочірній тікет, призначений іншому агенту, і — коли ви передаєте parent_ticket_id — записує ланцюг, щоб запобіжники його бачили.

Два структурні запобіжники завжди спрацьовують у контрольній точці тікетів, ніколи за інструкцією з промпту:

Обмеження глибини — ланцюг глибший за 3 кроки відхиляється.
Виявлення циклів — крок назад до агента, який уже є в ланцюзі, відхиляється.

Коли ви передаєте from_agent_id, спрацьовують ще два запобіжники (виробниче компонування завжди надає порти розв’язувача):

Стеля автономії — дієвий рівень делегата в просторі не повинен перевищувати рівень делегатора.
Бюджетна рамка — делегування списується із залишку жорсткого бюджету делегатора і не може створити нового. Відсутність політики або необмежена політика проходить.

Відмова гучна: інструмент повертає причину від запобіжника дослівно, тож агент, що делегує, точно бачить, чому саме. Поле delegatedByAgentId записує, хто делегував, утворюючи дерево делегування.

Це обмеження глибини делегування у 3 — інша межа, ніж обмеження вкладеності субагентів у вбудованому harness у 2: одне обмежує тікети між агентами, друге — субагентів у межах одного запуску.

Поставити кількох агентів на один тікет

Додайте їх як співавторів тікета (ролі: assignee, collaborator, reviewer). Це реєстр — облік того, хто задіяний, — і сам собою він нічого не надає.

Щоб справді зібрати агентів в одній розмові, додайте їх як учасників із заголовка простору. Тоді вони зможуть @-згадувати одне одного там. Див. Простори.

Автоматичне створення тікетів

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

Шлях, який справді існує, — оркестрація: затвердження пропозиції створює проєкт і команду, компілює DAG підтікетів із пропозиції в шаблон конвеєра (один крок promptAgent на підтікет, а не окремий рядок Ticket для кожного) і запускає це виконання. Див. Запустити оркестрацію.