Вбудовані subagents і модель делегування

1. Делегування роботи Claude

Після того як subagent відокремився від separate session, фоновий режиму і worktree-сесії, можна спокійно подивитися на перший робочий режим без термінологічного туману — built-in delegation: Claude виносить вузьке дослідження в окремий контекст і повертає не «ще одного мудреця», а коротке перевірюване зведення. Коли ви вперше бачите, що Claude «передав задачу іншому помічнику», це трохи схоже на наукову фантастику і трохи — на привід насторожитися. Насправді все простіше: делегування економить увагу і захищає сесію від сміття.

Уявіть, що у вас у Commerce OS є баг із черговістю refund-запитів. Якщо почати розбирати його «в лоб» в основній сесії — Claude прочитає контролер, сервіс, DTO, тести, фронтенд-таблицю, конфіги, логи, старі обговорення і ще кілька файлів «про всяк випадок». І вийде вже не чистий робочий стіл, а шафа, відчинена ногою.

Вбудований subagent розвʼязує цю проблему інакше. Claude ніби каже собі: «Для цієї підзадачі потрібен не весь мій діалог, а акуратний дослідник з окремим вікном контексту. Нехай збере факти і поверне зведення». Grep-результати, десятки файлів і миттєві гіпотези в основну сесію не потрапляють — лише результат.

Тут важливо зрозуміти одну річ. Делегування не робить відповідь точнішою — воно робить дослідження ізольованим і зручним для перевірки. Це не другий мудрець у печері, а помічник, який сходив до архіву і приніс папку з закладками: «Ось що знайшов, ось де лежить, а ось що не встиг перевірити».

2. Модель делегування на практиці

На словах усе це звучить красиво, але корисніше побачити механіку як робочий цикл. Тоді замість «усередині щось незрозуміле» лишиться інженерна модель: що Claude зробив, що повернув і де залишається ваше рішення.

flowchart TD
    A[Ви формулюєте задачу] --> B[Claude обирає відповідного вбудованого subagent]
    B --> C[Subagent працює в isolated context]
    C --> D[Збирає файли, команди, знахідки, обмеження]
    D --> E[Повертає коротке зведення в main session]
    E --> F[Ви перевіряєте evidence і вирішуєте наступний крок]

Якщо розкласти це на кроки, вийде дуже зрозуміла схема:

Найцінніше тут — четвертий крок. Саме він перетворює делегування на інженерний інструмент. Остаточна думка без слідів — не краще за ворожіння. Файли, рядки, тести, команди і блок «що не перевірено» — це матеріал для перевірки.

Вам не потрібно запамʼятовувати конкретні внутрішні реалізації, службові механізми і решту кухні. Важливий патерн: роль обрана → контекст ізольований → проміжний шум не потрапив до основної сесії → зведення повернулося як evidence. Щойно він зрозумілий, магія зникає.

3. Типи вбудованих subagents

На цьому місці хочеться спитати: «Гаразд, а як вони називаються?» Але саме тут курс навмисно тримає вас подалі від зубріння. Імена, кількість і доступність вбудованих subagents у конкретній версії Claude Code змінюються. Важливий не список назв, а типи поведінки. Найчастіше зустрічаються три великі класи вбудованих ролей:

Якщо говорити зовсім просто, один вбудований помічник добре працює в режимі «покажи, де це знаходиться», інший — «зібери матеріал для плану», третій — «розберися з вузькою гілкою і поверни сухий залишок». Важлива не вивіска, а поведінка. «Знайди, де формується сортування refund-запитів, і нічого поки не змінюй» — read-only дослідження. «Подивися, які файли зачепить виправлення, які тести є і де ризик регресії» — уже дослідження для плану.

І ще одна важлива деталь. Навіть побачивши знайоме імʼя в інтерфейсі, не будуйте процес на думці «цей агент завжди робить X». Будуйте на думці «мені потрібен ізольований дослідник для такої-то підзадачі». Продукт зміниться — а звичка залишиться робочою, і лекція не застаріє раніше, ніж закінчиться кава.

4. Ізольований контекст покращує відповіді

На перший погляд може здатися, що окремий контекст зменшує прозорість: раніше Claude «думав при мені», а тепер пішов за двері й коротко відзвітував. Насправді — частіше робить результат зрозумілішим: розслідування засмічує сесію швидше, ніж допомагає.

Згадайте, як ви самі шукаєте проблему у великому проєкті: файл, другий, grep, тест, конфіг, ще файл — половина виявляється хибним слідом. Це нормально. Але якщо весь ланцюжок тягнеться в основний діалог, Claude потім памʼятає зайве: старі гіпотези і невдалі здогадки.

Ізольований subagent працює як одноразова дослідницька гілка. Читає двадцять файлів, повертає чотири справді корисні знахідки. Замість лавини вихідних кодів ви отримуєте компактну карту, за якою вже можна йти осмислено. Уявіть такий запит:

Досліди, де в Commerce OS формується список refund-запитів.
Нічого не змінюй.
Поверни:
1) ключові файли,
2) повʼязані тести,
3) що залишилося неперевіреним.

Якщо таку задачу виконувати прямо в основній сесії з повним виводом усіх пошуків, ви швидко отримаєте стіну тексту. А у вбудованого subagent — коротке зведення. І тут важливо не ображатися на лаконічність: вам не вилили склад проміжного сміття.

5. Повернене зведення як evidence

Це центральна навичка сьогоднішньої лекції. Поки ви читаєте returned summary як «розумну відповідь Claude», легко прийняти гіпотезу за факт. Щойно починаєте читати її як документ із доказами, усе стає на свої місця. Зведення — не вирок, а папка зі знайденими слідами.

Сильне і слабке зведення зручно розрізняти за кількома ознаками:

Ось слабкий варіант:

Схоже, проблема міститься в support-модулі.
Сортування потрібно змінити і, ймовірно, додати тести.

Звучить упевнено, користі мало. Де support-модуль? Який файл? Що саме перевірено? Це не докази, а настрій.

А ось сильний:

Зведення дослідження:
- support/refund/RefundInboxService.java:42 — список сортується за createdAt ASC
- support/refund/RefundController.java:18 — endpoint /api/support/refunds/inbox викликає service.listInbox(...)
- support/refund/RefundInboxServiceTest.java:55 — є тест на порядок ASC
- Не перевірено: чи впливає фронтенд-таблиця dashboard/refunds/InboxTable.tsx
  на фінальне видиме сортування

Ось це вже робочий матеріал. Відкрити файл і перевірити рядок. Відкрити тест і побачити, що він покриває. Помітити прогалину: фронтенд не перевірено. Якщо зведення слабке, не варто драматично розчаровуватися у built-in subagents — треба просто дотиснути формат:

Покажи, на яких файлах і рядках ґрунтується висновок.
Якщо щось не перевірено, перелічи це окремо.
Не роби загальних рекомендацій без evidence.

Це дуже важливий перелом у мисленні: відповідь оцінюють не за тоном, а за слідами. Гарний абзац — це приємно. Відкриваний файл і перевірюваний рядок — корисно.

6. Сценарій Commerce OS: баг сортування refund

Тепер давайте зберемо все разом на короткому сценарії, близькому до нашого наскрізного проєкту. Уявімо, що в Commerce OS менеджер підтримки скаржиться: у inbox refund-заявки йдуть у неправильному порядку. Перша помилка, яку ви легко зробите, — одразу попросите Claude «виправити сортування»: модель може піти правити не той шар, фронтенд замість сервісу. Потрібен не fix, а спочатку розслідування з доказами:

Досліди, де в проєкті задається порядок refund-запитів у inbox.
Нічого не змінюй.
Поверни коротке зведення:
- ключові файли,
- повʼязані тести,
- можливу точку зміни,
- що ще не перевірено.

Claude делегує підзадачу дослідницькому subagent — той повертає, наприклад:

Зведення:
- support/refund/RefundInboxService.java:42 — сортування за createdAt ASC
- support/refund/RefundController.java:18 — endpoint передає запит у service
- support/refund/RefundInboxServiceTest.java:55 — тест перевіряє ASC, немає сценарію newest-first
- dashboard/refunds/InboxTable.tsx — таблиця показує дані в отриманому порядку, локального сортування не знайдено
- Не перевірено: чи впливає параметр сортування з query string на backend

Що ви робите далі? Не пишете одразу «чудово, лагодь». Спочатку перевірте сліди. Відкрийте RefundInboxService.java, переконайтеся, що сортування ASC. Тест не покриває потрібний сценарій. Фронтенд, схоже, не винен. Тепер у вас є обґрунтована наступна команда: дослідити query string або планувати точкове виправлення сервісу і тесту.

Зверніть увагу, наскільки чистішою стала робота: основна сесія не потонула в шумі, а зведення конкретне для ухвалення рішення. Ось у цьому і полягає реальна цінність delegation model.

7. Запит зведення в зручному форматі

Дуже часто якість built-in subagent визначається не лише самою роллю, а й тим, наскільки акуратно ви задали формат результату. Розпливчастий запит майже гарантовано дає розпливчасте зведення. Заздалегідь назвали файли, тести, відкриті питання і межі неперевіреного — шанс на корисний результат різко зростає. Для пошуку файлів і точок входу працює шаблон:

Знайди, де в проєкті реалізовано цю поведінку.
Нічого не змінюй.
Поверни:
1) ключові файли,
2) повʼязані функції або класи,
3) тести,
4) що залишилося неперевіреним.

Якщо вам важливо не засмічувати основну сесію і отримати саме стислий результат, корисно уточнювати це прямо у формулюванні:

Досліди задачу в ізольованому контексті.
В основний діалог поверни лише коротке перевірюване зведення.
Не перелічуй увесь проміжний пошук.

А якщо вам потрібне зведення, придатне для подальшого рішення, а не «загальні рекомендації», додайте вимогу до evidence:

Для кожного висновку вкажи файл і, якщо можливо, рядок.
Якщо це гіпотеза, познач її окремо.
Якщо щось не перевірено, винеси в окремий блок.

Зверніть увагу, чого тут немає. Ні «думай як senior», ні «увімкни максимальний інтелект», ні інших заклинань. Є задача, межа і формат артефакта — інженерний підхід, нудніший за шаманство, але стабільніший.

І ще одна мʼяка, але корисна порада: не просіть надто багато за один раз. Вимагаєте в одному запиті знайти файли, зрозуміти архітектуру, оцінити ризики, придумати fix, написати тести і сходити по хліб — навіть хороший subagent поверне кашу. Делегування працює на вузьких підзадачах.

8. Делегування: коли воно виправдане

На тлі всіх переваг легко почати делегувати взагалі все — аж до пошуку одного рядка у вже відкритому файлі. І тут корисно вчасно пригальмувати. Built-in subagents — не обовʼязковий ритуал, а інструмент. Задача маленька, сесія не забрудниться — делегування буде зайвою прошарком.

Припустімо, ви вже знаєте точний файл і хочете зрозуміти одну функцію на двадцять рядків. Тут окремий subagent лише додасть руху — прочитаєте самі. А коли задача розповзається на шари, тести, конфіги і точки входу, isolated investigation окупається.

Хороший орієнтир звучить так: дослідження може захламити основну розмову — делегуйте; ні — обійдетеся без нього. Не перетворюйте built-in subagents на новий культ. Курс бореться з двома крайнощами: «AI все зробить сам» і «треба обовʼязково використовувати найпросунутішу фічу, інакше я поганий інженер».

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

Коли ви починаєте дивитися на built-in subagents не як на маленьких оракулів, а як на акуратних збирачів доказів, усе стає спокійніше. Claude делегує не для того, щоб забрати керування, а щоб повернути коротке, чисте і перевірюване зведення. А рішення знову за вами: відкрити файли, перевірити сліди, звузити задачу і лише потім рухатися далі.