Термінологія агентів у Claude Code

1. Плутанина навколо слова agent

Коли продукт швидко зростає, зручні слова починають означати одразу кілька різних сутностей. Із agent відбувається саме це. «Запустимо агента», «нехай агент перевірить код», «потрібен ще один агент» — красиво, а інженерно це туман. На тумані Workflow Kit не побудуєш.

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

Коли фраза «запусти ще одного агента» звучить досить точно, це означає, що розмова поки що недостатньо точна.

В інженерній роботі майже завжди треба уточнити три речі: де живе його контекст, чи повертається результат у поточну розмову автоматично та чи потрібна йому ізоляція файлової системи — окрема Git-гілка або worktree. Три запитання — і туман розсіюється.

Саме тому спочатку важливо не те, «як створити агента», а те, як перестати плутати пʼять сутностей, що випадково схожі на одну. Щойно Claude перестає бути однією довгою розмовою і починає допомагати з делегуванням усередині workflow, постає наступне запитання: яку робочу одиницю ви запускаєте. За замовчуванням це найчастіше subagent. Інші слова нижче потрібні, щоб не сплутати його із сусідніми режимами.

2. Agent — парасольковий термін

У звичайному мовленні agent зручний як парасолька: будь-який AI-виконавець усередині Claude Code. Для загальної картини підходить. Для точної команди — слабко.

Сказати «у нас є agent» — це приблизно те саме, що сказати «у нас є спеціаліст». А який? Аналітик? Ревʼюер? Тестувальник? Із доступом лише на читання чи той, хто змінює код? Поки не уточнили — це лише категорія.

Тому agent зручно використовувати у двох випадках: архітектура зовсім зверху («так, агентні механізми в системі є») і момент, коли тип ще не визначено. Дійшло до реальної задачі в Workflow Kit або Commerce OS — переходьте до точних слів.

Подивіться на різницю:

Неточно:
«Давайте запустимо ще одного агента на auth-модуль».

Точніше:
«Потрібен read-only subagent для дослідження auth-модуля
і короткого summary у поточну сесію».

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

3. Subagent: робочий термін рівня

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

Робоча формула має такий вигляд:

subagent = role
         + isolated context
         + tools
         + output contract

Формула коротка, але в ній уже майже все важливе. role — «хто він за функцією»: reviewer, дослідник, документатор. isolated context — помічник працює не на вашій мисленнєвій кухні, а у власному вікні: читає гору файлів і не завалює основну сесію шумом. tools задають межу можливостей: читати, шукати, запускати команди — або нічого зайвого. output contract визначає форму результату: summary, findings, посилання на файли, відкриті запитання.

Із цієї формули випливають дві важливі властивості. Subagent — не «другий Claude поруч»: він вбудований у поточний workflow і зазвичай повертає результат у поточну розмову. Сила не в автономності, а в спеціалізації та ізоляції.

Якщо ви подумки відкриваєте артефакт agents/reviewer.md у Workflow Kit, читайте його так: не «якийсь агент», а конкретний subagent із роллю ревʼюера, окремим контекстом і зрозумілою формою виводу. Файл перестає бути магічним сувоєм і стає інженерною конструкцією.

Саме subagent зручно тримати як робочий варіант за замовчуванням. Інші сутності не конкурують із ним, а показують, коли потрібна інша форма ізоляції.

4. Separate session: окрема розмова

На слух separate session легко сплутати з subagent — там і там ніби зʼявляється «ще один Claude». Але відмінність принципова: це не помічник усередині поточного workflow, а окрема розмова зі своєю історією. Результат назад він автоматично не приносить: ви самі вирішуєте, що переносити далі.

Хороша аналогія тут проста. Subagent — спеціаліст, якому дали вузьку підзадачу й попросили повернутися з короткою запискою. Separate session — ніби ви відкрили інший блокнот і повели там паралельну лінію думки.

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

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

5. Background agent: робота у фоновому режимі

Іноді задачі потрібен не діалог, а час: сканувати проєкт, зібрати великий звіт, не блокувати поточну роботу. Тут спливає ще одне значення agent — фонова робоча одиниця, яку відправляють виконувати задачу асинхронно. Точні назви й сам факт наявності такої можливості в різних версіях Claude Code можуть відрізнятися, але патерн важливіший за кнопку.

Ключове слово тут — «фон». Background agent добрий, коли ви не хочете сидіти з ним у постійному діалозі: задаєте зрозумілу роботу, знаєте очікуваний артефакт, пізніше повертаєтеся за результатом. А коли задача вимагає щільного інтерактиву — «подивися це, ні, зачекай, краще так, а тепер уточни ще одне місце» — фон заважає, логічніше звичайний subagent або поточна сесія. Не «розумніший агент», а робоча одиниця з іншим ритмом.

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

Потрібен швидкий повернений summary у поточну розмову → subagent.
Потрібен результат пізніше, без постійного діалогу → background agent.

6. Worktree-backed session: ізоляція файлів

До цього моменту йшлося переважно про ізоляцію контексту: хто де думає, хто куди повертає відповідь. Але в інженерній роботі є ще один рівень — файловий: правки мають фізично йти в іншу Git-гілку та іншу робочу директорію. Саме тут і зʼявляється worktree-backed session.

Це вже не просто інша розмова, а сесія, привʼязана до окремої Git worktree: власна файлова поверхня для правок, свій branch, свій diff. Різниця з subagent тут особливо важлива. Задача суто дослідницька — знайти всі точки входу в payments або перевірити, як улаштований auth — worktree не потрібна: ганяти її заради дослідження — це все одно що їхати в сусідній магазин на бронетранспортері. А от спробувати ризиковану реалізацію, не торкаючись основного working tree, або порівняти два варіанти без конфліктів у файлах — тоді worktree виправдана.

Корисна коротка схема має такий вигляд:

Потрібно лише ізолювати дослідження → subagent.
Потрібно ізолювати реальні правки і Git-історію → worktree-backed session.

У цьому й полягає зрілість термінології: не одне слово agent на все, а форма ізоляції під реальну інженерну потребу.

7. Agent team: координація, а не заміна дизайну

Коли люди вперше чують про кілька агентів, дуже хочеться одразу уявити AI-команду: один планує, другий пише код, третій тестує, четвертий робить каву й морально підтримує pipeline. Звучить бадьоро. Саме тому agent team корисно одразу поставити на місце: це карта можливої координації, а не режим за замовчуванням.

Agent team передбачає кількох виконавців або сесій із загальним планом і координацією. У теорії корисно. Але на базовому рівні курсу важливіше не розганяти оркестр, а розрізняти одиночні сутності: дуже часто «мені потрібен agent team» перекладається інженерно як «мені потрібен один нормально спроєктований subagent».

Тут корисна крапля самоіронії. У програмуванні ми любимо красиво ускладнювати: систему можна зібрати з одного зрозумілого механізму, а ми все одно тягнемо туди хор, симфонічний оркестр і дим-машину. Agent team — той випадок, коли гарний термін створює хибне відчуття зрілості. Професійніше протилежне: не множити сутності без потреби.

Тому на поточному етапі достатньо памʼятати просту річ: agent team — не синонім subagent і не «прокачаний Claude». Термін знати корисно. Будувати на ньому базовий workflow — поки що зарано.

8. Порівняльна таблиця термінів

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

agent

subagent

separate session

background agent

worktree-backed session

agent team

Ця таблиця особливо корисна для нашого наскрізного артефакту agents/reviewer.md. Якщо подивитися на нього крізь сьогоднішню лекцію, стає зрозуміло: це саме subagent. Не окрема сесія — він працює всередині поточного workflow. Не worktree-backed session — не його справа розводити правки по гілках. І не agent team — для локального review це було б декоративно.

Тому точне інженерне формулювання звучить так:

Потрібен read-only subagent reviewer для локальної перевірки diff.
Йому не потрібна окрема worktree і не потрібна самостійна session.

А ось розпливчастий варіант звучав би так:

Давайте заведемо ще одного агента на ревʼю.

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