Архітектура AI-агента для команди 30 людей (без DevOps)

Коли CEO логістичної компанії на 40 людей запитав мене, що означає "архітектура AI-агента" для команди його розміру, я сказав чесну відповідь: більшість референсних архітектур, які зараз ходять у мережі, малювалися для корпорацій на 5 000 людей з платформенною командою — і скопіювати їх це спосіб для SMB спалити пів року й чверть бюджету на сантехніку.

Чому архітектура важливіша за модель

Модель — товар. Anthropic, OpenAI, Google випускають співмірні Tier-1 моделі з різницею в тижні. Те, що відрізняє робочого агента від такого, що тихо галюцинує — це все навколо моделі: як приходить контекст, як логуються рішення, як вмикається людина, коли агент не впевнений.

MIT 2025 показав: 95% GenAI-пілотів не доходять до production-ROI. У провалених пілотах причина майже ніколи не "модель не достатньо розумна". Це "ми не могли зрозуміти, що зробив агент, тому не довіряли йому, тому вимкнули".

Визначення: AI-агент — програмний процес, що бере мету, вирішує проміжні кроки через LLM, виконує їх через інструменти (API, БД, пошук) і повертає результат. На відміну від чат-бота — діє; на відміну від скрипта — адаптується.

Чотири-компонентна референсна архітектура

Для компанії на 30-500 людей без виділеного DevOps у архітектурі чотири частини. Усе.

1. Оркестратор (мозковий стовбур)

Шар, що приймає запит, кличе LLM, кличе інструменти й вирішує наступний крок. Для SMB вибір між no-code/low-code (n8n, Make, Zapier з AI-нодами), hosted agent-платформою (Lindy, Relay, OpenAI Assistants API), або тонким кастомним шаром (LangChain, LlamaIndex, прямі SDK-виклики).

Визначення: Оркестратор — контролер, що крутить decision-loop агента. Володіє "що робити далі" з поточним станом.

Для команди на 30 людей без інженерів — починайте з hosted no-code. Колись ви це переростете. І це нормально — переростати означає, що агент дає цінність, а це єдиний результат, що має значення.

2. Сховище контексту (памʼять)

Агенту треба знати: хто цей клієнт, що він питав минулого тижня, яка наша політика, що в каталозі SKU. У enterprise це vector-database з RAG-pipeline. Для SMB це overkill у 80% випадків.

Дешевші альтернативи, що працюють:

• Прямий look-up по системі обліку — Salesforce, HubSpot чи Postgres напряму. Vector-store не потрібен.
• Document store з embedded-пошуком — Notion, Coda або Google Drive, індексовані вбудованим пошуком оркестратора.
• Vector DB лише коли потрібен семантичний пошук по неструктурованому тексту — стенограми дзвінків, support-тікети, довгі PDF.

Визначення: RAG (Retrieval-Augmented Generation) — патерн, де агент дістає релевантний контекст зі сховища ДО відповіді. Різко знижує hallucination rate, коли джерело чисте.

3. Шлях ескалації до людини (страхувальна сітка)

Найбільша помилка SMB при запуску — стартувати без чіткого "агент не впевнений — що далі?". Klarna в 2025 відкотила повністю-AI customer-service агента саме тому, що ескалація була повільною. Stanford 51-deployment study: escalation-routing агенти дають ~71% productivity gain проти ~30% у approval-routing — патерн архітектури важливіший за модель.

Три речі мусять існувати ДО запуску:

1. Поріг впевненості — нижче X — ескалація.
2. Іменований owner — не "команда", а конкретний Slack-handle.
3. SLA — "ескалації беруться в роботу за 30 хвилин у робочий час".

4. Observability (дашборд)

Треба бачити, що зробив агент. Не метрики — trace-логи. Кожен prompt, кожен tool-call, кожен output. Для команди на 30 людей це таблиця в Postgres, куди пише оркестратор, плюс одна сторінка адмінки з останніми 200 запусками.

[Run #1432]  Time: 14:22 UTC  Duration: 4.1s
Goal: "Look up invoice INV-2891 for Acme Co"
Step 1: query_crm(account="Acme") → 1 result
Step 2: query_invoice(id="INV-2891") → status=overdue, 11 days
Step 3: draft_email(tone="firm-but-polite") → 87 words
Result: Draft saved to Olha's inbox, awaiting approval
Confidence: 0.91
Escalated: no

Без цього неможливо дебажити, неможливо покращувати, неможливо виправдати агента перед CFO, коли вона спитає "що ця штука взагалі робить?".

Team scan (what AI champions report after week 1)

• Adoption всередині пілотної команди швидко росте перші 5 днів, потім плато на ~60% — плато це нормально.
• Найчастіший use-case — пошук інвойсу чи документа, не "креативний драфт".
• Середній saved-time на користувача за перші 14 днів — 2-4 години/тиждень.
• 15-20% запусків агента в перший тиждень тригерять ескалацію; падає до 5-8% до 4-го тижня, коли промпти й контекст покращуються.
• Чемпіони знаходять ті ж 3-4 broken edge-cases, про які засновник ніколи не знав (тайпи в назвах вендорів, неправильна валюта, weekend-handoff).
• Shadow-AI помітно падає — люди перестають копіпастити в ChatGPT і йдуть до санкціонованого агента.
• До 2-го тижня ніхто не питає "це AI?". Це стає інструментом, як пошта.
• Найбільший блокер — не модель, а відсутність доступу до однієї системи, яку забули в первинному скоупі.

Tool tip (Course for Business): Сценарій 30-людної команди — саме там, де ratio AI Champions (1:15-20) платить за себе: один натренований чемпіон на 15-20 людей покриває 30-людну компанію 1-2 людьми, які можуть дебажити запуски агента, писати кращі промпти й онбордити решту. Це довговічніше за зовнішнє агентство: знання залишається в компанії. Наша 5-денна програма тренує кожного співробітника зашипити одну автоматизацію, і ми ідентифікуємо 1-2 чемпіонів у перший тиждень.

Що пропустити (поки що)

Розмови з засновниками майже завжди починаються з неправильного питання. Питають "Pinecone чи Weaviate?" до того, як у проді є хоч один агент. Тому список того, що відкласти за 3-й місяць:

• Vector database (прямий DB-lookup, поки немає RAG по неструктурі)
• Self-hosted LLM (Gartner: CIO помиляються в AI-infra costs до 1 000% — зазвичай self-hosting це пастка)
• Кастомний eval framework (вистачає логів оркестратора)
• Multi-agent orchestration (один агент на одну роботу — досить на перший квартал)
• Fine-tuning (prompt engineering + RAG покривають 95% SMB use-cases)

Колапс Builder.ai на $1,3B у 2024 — повчальна історія: компанія перебудувала platform-шар до того, як довела, що agent-шар працює. У SMB немає такої злітної смуги.

Copy-paste decision template

Перед архітектурою заповніть це. Якщо не можете відповісти всі 6 на одній сторінці — ви ще не готові будувати.

1. Job to be done (одне речення):
   ____________________________________________

2. Хто володіє агентом (іменована людина, не команда):
   ____________________________________________

3. Системи-джерела, з яких агент ЧИТАЄ:
   - ____________________
   - ____________________

4. Системи, в які агент може ПИСАТИ:
   - ____________________ (ескалація обовʼязкова: y/n)

5. Шлях ескалації:
   - Тригер: ___________________
   - Owner: _______________________
   - SLA: _______________________________

6. Метрика успіху, яку міряємо на 14-й день:
   ____________________________________________

Якщо в (4) нічого нема — агент read-only — архітектура драматично простіша. Починайте звідти.

Micro-case (що змінюється за 7-14 днів)

Профсервісна фірма на 60 людей збирає агента за довгий вікенд: hosted-оркестратор, прямі CRM lookups, Slack-канал ескалації. До 7-го дня агент тримає ~40-50 рутинних client-status запитів на день, ~12% ескалюються. До 14-го дня ескалації падають до 6%, команда повертає ~15 годин senior-часу/тиждень, засновник перестав читати Slack-канал ескалації — там тихо. DevOps не наймали. Vector-DB не розгортали. Інфраструктура — менше €400/місяць.

Note on this case: Цей приклад ілюстративний — базується на типових патернах для компаній 30-500 людей, не на одному названому клієнті. Конкретні цифри — округлені діапазони, не гарантії.

Tool tip (Course for Business): Найкращий предиктор того, що архітектура агента 30-людної команди переживе 3-й місяць — це чи розуміють користувачі базовий цикл: контекст в → рішення моделі → tool-call → output → лог. Ми вчимо це в 6-week program з Shoulder-to-Shoulder hot-seat сесією, де кожна команда будує й дебажить власного агента наживо. Архітектура, яку команда не вміє дебажити — це архітектура, яку вимкнуть після першого ж збою.

FAQ

Чи потрібна vector-database? Скоріш за все, не в перший квартал. Якщо робота агента — "знайти структуровані дані й діяти на них" — прямий DB-запит швидший, дешевший і точніший за embeddings. Додавайте vector-store, коли є чіткий use-case з семантичним пошуком по неструктурі.

Hosted чи self-hosted LLM? Для SMB на 30-500 людей hosted — майже завжди правильний вибір. Self-hosted на папері виглядає дешевше, але GPU, ops-overhead і version-upgrade зʼїдають економію. Перегляньте, коли API-витрати перевищать €15k/місяць.

Чи може одна людина володіти всією архітектурою? Так, якщо архітектура достатньо маленька. У цьому й сенс чотири-компонентної моделі. Сильний ops-lead з одним натренованим чемпіоном тримає це. Якщо потрібно більше двох людей — архітектура занадто складна для вашої стадії.

Що з security і EU AI Act? Для більшості SMB-агентів (внутрішня продуктивність, customer-service драфти, lookup внутрішніх даних) ви далеко поза high-risk категорією EU AI Act. Штрафи — для high-risk систем (біометрія, credit scoring, рішення про найм). Для logistics-status агента чи invoice-lookup стандартної дата-практики достатньо. Але задокументуйте data flows зараз — аудитори спитають пізніше.

Підсумок

Команді на 30 людей не потрібна enterprise-архітектура. Потрібно чотири компоненти, один чемпіон, чіткий шлях ескалації й видимі логи. Пропустіть vector-DB, self-hosted LLM, orchestration framework з 800 GitHub-зірками. Зашипіть найпростіше, що працює, дивіться логи й дайте агенту заробити свою складність.

Наступний крок: запишіть decision template вище. Якщо не можете заповнити — жодна архітектура не врятує.

Якщо хочете, щоб кожен співробітник зашипив свою першу AI-автоматизацію за 5 днів — забронюйте 30-хв дзвінок: https://course.aiadvisoryboard.me/business