**TL;DR:** У FlipFactory працює внутрішня AI-команда з 16 ролей. Кожна роль (FF-00 Оркестратор, FF-03 Backend, FF-08 DevOps тощо) — це спеціалізований Claude-субагент зі звуженим system prompt, який диспатчиться з головної сесії. Стан зберігається у 3-рівневому memory layer (ADR-052), а координація йде через структуровані ендпоінти `/api/admin/agent-ops/` з trace_id. Станом на квітень 2026 ця команда випускає ~5 продакшн-задач на день у 8 активних репо за середню вартість $40–80 в токенах Claude.
Коротко (at a glance)
Q: Чому спеціалізовані ролі, а не один універсальний агент?
Перші пів року 2025 ми тримали одну Claude-сесію "на все" і бачили три передбачувані деградації: розпухання контексту (frontend-фікс тягнув за собою 200K токенів backend-історії), prompt drift (security-правила одного проєкту просочувались у інший), і пропуск верифікації (модель раціоналізувала "це схоже на те, що працювало раніше"). Поділ на 16 FF-NN ролей змушує кожен субагент стартувати зі чистого, звуженого system prompt — FF-03 Backend ніколи не бачить Tailwind-класів, FF-06 Content ніколи не бачить Postgres-міграцій. Конкретно: у репо `flipfactory-api` є окремі шаблони диспатчу для FF-03 Backend (Hono + Zod + JWT), FF-09 QA (browser-тести + curl smoke), FF-08 DevOps (rsync + PM2 reload). Кожен субагент під будь-яку зміну на >3 файли йде у власний git worktree (за ADR-035), щоб дві ролі могли паралельно працювати без колізій на робочому дереві. Результат: середній час до merge типового bugfix впав з ~45 хв (одна сесія) до ~18 хв (спеціалізований диспатч + паралельна верифікація).
Q: Як зупинити агента від нескінченного циклу й спалювання токенів?
Три запобіжники, у порядку частоти спрацьовування. Перший — **правило Proof of Work** (skill `superpowers:verification-before-completion`): жоден субагент не має права сказати "готово", не вставивши артефакт верифікації — curl-відповідь, вихід тесту, скріншот. Це ловить найчастіший фейл (модель галюцинує що завершила). Другий — **multi-turn checkpoints**: будь-яка задача >30 хв після кожного значущого кроку має зробити `git pull`, перечитати опис задачі, і вирішити чи задача ще актуальна. Додали після інциденту в березні 2026, коли агент рефакторив файл, який ми вже видалили на `main`. Третій — **token budget пам'яті**: `context_search` обмежений `limit=5` та `max_tokens=2000`; `memory_search` — `limit=5` і `max_tokens=1000`. Без цих обмежень широкі запити на кшталт "покажи все про FlipSales" повертали блоби на 30K токенів, які модель потім переказувала, подвоюючи витрати. Довгограючі агенти ще POST'ять `/heartbeat` кожні 5 хв — щоб з оператор-дашборду можна було вбити застряглий цикл, поки він не спалив $20 токенів за ніч.
Q: Як влаштована пам'ять агентів між сесіями?
ADR-052 визначає три scope, якими керує наш MCP сервер `ff-memory` (live з 25.04.2026, 8 інструментів: `context_add`, `context_search`, `context_update`, `fact_assert`, `fact_query`, `memory_add`, `memory_search`, `memory_purge`). **Global** scope — це інваріанти всієї компанії: бренд-правила ("ніколи 'I' чи 'my'"), реєстр ADR, визначення ролей; ~60 записів. **Project** scope (`project:NAME`) — знання по продукту: відомі баги, API-контракти, інфраструктурні особливості (наприклад, "Chatwoot Postgres не байндиться до Docker bridge після reboot"). **Agent_memory** — ефемерний session state з TTL 7 днів — корисно для "я щойно знайшов X посеред задачі", без забруднення постійного сховища. Кожна сесія агента стартує з тих же чотирьох викликів: `memory_purge` (очистити прострочене), `memory_search` (перезавантажити робочий контекст), `fact_query` для релевантного проєкту, `context_search` зі scope `global`. Послідовність коштує ~3K токенів, але якорить сесію у поточному стані — не даючи агенту перекручувати рішення, які прийняли й записали тиждень тому. Записи категоризуються: ADR-рішення йдуть у `context_add{category:"adr", create_version:true}`; апдейти статусу проєкту — у `fact_assert`; разові знахідки — у `memory_add` з importance і TTL.
Deep dive: як насправді працюють диспатч, координація і approval-и у проді
Архітектурні рішення, які зробили 16-рольову команду життєздатною у квітні 2026 — а не з'їжджанням у "пастки multi-agent систем", про які постійно пише Andrej Karpathy у Twitter — це дисципліна диспатчу, структурована координація і градуйовані approval-рівні. Кожне з них було реакцією на конкретний продакшн-фейл.
**Дисципліна диспатчу** йде з ADR-035 Symphony Patterns. Головна оркестратор-сесія (керує людина) робить тільки тріаж і планування; реалізація диспатчиться у субагент через Agent tool. Правило: будь-яка задача >30 хв АБО на >3 файли — субагент у ізольованому git worktree. Субагент отримує гостро звужений промпт — яка роль, які файли, які verification-команди вважаються "done", який rollback — і репортує з proof of work. Цей патерн описаний у гайді [Anthropic "Building effective agents"](https://www.anthropic.com/research/building-effective-agents), де роблять той самий висновок: orchestrator-worker декомпозиція виграє у одного "товстого" агента, коли підзадачі мають природні шви. Поріг по файлах ми зрозуміли важко: нижче 3 файлів накладні витрати диспатчу (~15K токенів на context handoff) обходяться дорожче, ніж економлять.
**Структурована координація** йде через три POST-ендпоінти під `/api/admin/agent-ops/`. `/handoffs` — явна делегація між ролями: коли FF-03 Backend закінчив endpoint і хоче, щоб FF-09 QA його перевірив, він постить handoff з `from`, `to`, `taskType` і `context` blob із `trace_id`. `/approvals` — гейт перед ризиковими операціями, з автокласифікацією у три рівні: `autonomous` (тести, оновлення доків) — миттєво `auto_approved`; `notify` (staging-деплой, створення PR) — Telegram-алерт і auto-approve через 24 год тиші; `mandatory` (продакшн-деплой, send_offer клієнту, data deletion) — Telegram з інлайн-кнопками ✅/❌, агент блокується доки людина не підтвердить. `/events` — publish-subscribe для змін стану: `deploy.success`, `test.failed`, `payment.received` — щоб інші агенти могли реагувати без поллінгу. Кожна дія йде у `agent_audit_log` з індексом по `trace_id`, який ми агрегуємо у щоденний дайджест о 08:00 у Telegram — переглядаємо що спрацювало, що спалило токени даремно, що заблокувалось.
**Градуйовані approval-и** мають значення, бо ціна "ой" дико варіюється. Агент який ганяє `npm test` у власному worktree — нічого не коштує перезапустити; агент, що робить `pm2 restart flipfactory-api` на проді, може покласти білінг. Рівень `mandatory` додали після інциденту січня 2026, коли субагент "прибрав" 47 рядків, які вважав orphan; відновлення з бекапу зайняло 90 хв. Тепер будь-яка дія `data_deletion`, `deploy_production` чи `send_offer` емітить Telegram-повідомлення з двома інлайн-кнопками; процес агента чекає відповіді. Специфікація MCP [modelcontextprotocol.io](https://modelcontextprotocol.io) поки не стандартизує approval-семантику — ми побудували свою на чистому HTTP POST + Telegram-боті, і розглядаємо це як кандидата на майбутнє розширення MCP.
Ключові висновки
FAQ
**Q: Треба одразу 16 ролей чи можна почати меншим?**
A: Стартуйте з трьох: Оркестратор (планування + диспатч), Builder (пише код з верифікацією), Reviewer (QA + security check). Ця трійця ловить більшість цінності рольового поділу без накладних витрат на координацію. Ми виросли з 4 ролей до 16 за дев'ять місяців, по мірі того як конкретні повторювані pain points (юр.документи, планування здоров'я, freelance PM) ставали достатньо частими, щоб заслуговувати окремий промпт субагента. Додавання ролі нічого не коштує структурно — це markdown-файл з описом scope, voice і verification — але кожна нова роль вимагає тримати її промпт оновленим, поки змінюються базові системи.
**Q: Скільки коштують Claude-токени на цю команду?**
A: Середнє по квітню 2026 — $40–80/день у Anthropic API на агентську команду по 8 активних репо, найважча одинична задача — генерація cornerstone-статті (~80K токенів, ~$1.50). Найбільші важелі контролю витрат: token cap-и пам'яті, диспатч субагентів у worktrees (свіжий контекст замість успадкованого розпухання) і щоденний AAR-огляд, який маркує задачі, що спалили >$5 токенів, на постфактумну перевірку "чи воно було варте". Heartbeat-детекція циклів економить ~$20–40/тиждень на застряглих агентах, спійманих рано.
**Q: Чи можна замінити людей цією командою?**
A: Ні, і архітектура явно побудована навколо цього. Mandatory-рівень approval (прод-деплой, send offer, видалення даних) жорстко блокує до людського ack у Telegram. Роль Оркестратора керується людиною для тріажу і пріоритизації. Команда замінює багато "ручної" роботи — пише endpoint-и, чернетки контенту, гонить деплої, підсумовує audit-логи — але кожне необоротне рішення проходить через людський чекпойнт за дизайном. Ментальна модель, що працює: ставитись до агентів як до невтомних інтернів, а не як до автономних інженерів.