Cowork Agents

Хто коли викликає Agent tool (субагент) у поточній Cowork-сесії, і як не просрати токени та якість на зайвій або кривій делегації.

Рамка рішення — робити самому vs делегувати

Дефолт при сумніві: не делегувати. Зайвий агент = зайві токени і зайва затримка на передачу контексту, якого субагент не бачив.

Як писати промпт агенту

Субагент не бачить цей чат. Промпт мусить бути самодостатній:

1. Що і навіщо — не «on the findings above», а власне ціль задачі одним реченням.
2. Що вже відомо — конкретні шляхи файлів, ID, URL, назви, вже виключені варіанти.
3. Формат відповіді — якщо потрібен короткий підсумок: «report in under 150 words», якщо структуровані дані — описати форму.
4. Межі — що НЕ чіпати (не редагувати код, якщо задача — тільки research).

Погано: "Based on the plan, implement it." Добре: "Файл X.php, метод Y() — додай валідацію Z за схемою у файлі W.md, рядки 12–40. Тестів не пиши, лише зміни коду."

Якщо потрібна коротка відповідь — прямо попроси ліміт слів, інакше субагент за дефолтом повертає розлогий текст.

Паралельний fan-out

Незалежні задачі → один message з кількома tool calls Agent tool одночасно, не послідовні виклики. Послідовні виклики для незалежних задач — марна втрата часу.

Fan-out доречний коли:

• N файлів/модулів треба перевірити тим самим чеклістом
• Потрібні кілька незалежних точок зору на одне питання (adversarial verify)
• Дослідження за кількома джерелами одночасно

Fan-out НЕ доречний коли задачі залежні (крок 2 потребує результат кроку 1) — тоді послідовно, або в одному агенті.

Вибір subagent_type

Дефолт — general-purpose (все, всі tool). Точковий вибір коли підходить:

Якщо не singleton — перевірити список актуальних типів у system reminder перед викликом, бо перелік плагінних агентів змінюється разом з інстальованими плагінами.

isolation: worktree

Тільки якщо кілька агентів паралельно пишуть у ті самі файли і інакше конфліктнуть. Для read-only чи для одного агента — не використовувати (зайвий сетап-кост).

Ескалація до Workflow tool

Workflow tool (детермінований оркестратор кількох агентів: pipeline/parallel/loop) — НЕ дефолт. Викликати лише коли є явний opt-in:

• Mark сказав «workflow», «ultracode», «запусти воркфлоу», «orchestrate», «fan out агентів» — своїми словами, а не бо задача виглядає масштабною.
• Викликаний скіл/команда прямо каже викликати Workflow.

Без цього opt-in — навіть велика задача робиться через звичайні Agent tool виклики (послідовно чи fan-out), не через Workflow. Якщо задача явно виграла б від Workflow (масштаб, потрібна adversarial-перевірка кожної знахідки) — коротко запропонувати це Марку одним реченням і назвати ціну (скільки токенів/агентів), а не запускати самовільно.

Антипатерни

• Агент на задачу, яку швидше зробити самому (1 Read, 1 Grep) — зайвий overhead.
• Промпт агенту типу «продовж з того місця» без контексту — субагент нічого не бачив.
• Послідовні Agent-виклики для незалежних задач замість одного message з fan-out.
• Workflow без явного opt-in Марка.
• Плодити агентів «про всяк випадок» — кожен виклик коштує токенів.
• Просити субагента зробити те, що вже видно з наявного контексту чату.

Швидкий чекліст перед викликом Agent tool

• Це справді ділиться на незалежну підзадачу, чи простіше самому?
• Промпт самодостатній (без «as discussed above»)?
• Вказано формат/ліміт відповіді, якщо потрібен короткий підсумок?
• Незалежні задачі → один message, кілька tool calls (fan-out), не послідовно?
• subagent_type відповідає задачі (чи general-purpose ок)?
• Workflow не викликається без явного «workflow»/«ultracode» від Марка?