Анатомія бізнес-команди з ШІ: координація агентів за допомогою LangGraph та FastAPI

Більшість систем автоматизації на основі ШІ досі працюють у форматі одного агента: одна модель отримує запит та повертає відповідь. Це підходить для відповідей на запитання, але справжня бізнес-робота розподілена між різними ролями, деякі кроки виконуються паралельно, а інші вимагають підтвердження людини. У цьому огляді розглядається програмна платформа з відкритим кодом Multi Agent for Business Automation, яка моделює невелику команду стартапу як координовані агенти. До кінця ви повинні зрозуміти, як поєднуються її механізми оркестрації, пам’ять, процедури схвалення та API-інтерфейс, а також які елементи дизайну можна використати у власних системах агентів.

Розгляньмо, як насправді планується новий проект. Засновник сформулюовує бачення. Менеджер перетворює його на конкретні завдання. Фінансовий відділ перевіряє припущення щодо доходів та витрат, відділ маркетингу розробляє стратегію позиціонування, юридичний відділ аналізує ризики, а відділ продажів готує заходи з просування. Частина цих дій відбувається по черзі, частина — одночасно, а ще частина зупиняється до тих пір, поки людина не схвалить наступний крок.

Згідно з документом README, цей проект — це платформа для автоматизації бізнес-процесів та підтримки прийняття рішень, у якій агенти з різними ролями, особистостями та інструментами координуються за допомогою робочих процесів LangGraph, спільної пам’яті та механізмів схвалення з участю людини (HITL), а також з можливістю створення звітів та зовнішніх інтеграцій. Метою є не створення ще одного чат-бота, а віртуальний офіс, де агенти працюватимуть разом, як команда стартапу.

П’ять архітектурних шарів

Система чітко поділяється на п’ять шарів:

• Фронтенд: панель керування на базі React для інтеграції користувачів через чат, візуалізації робочих процесів, схвалень та аналітики.
• Бекенд API: REST-кінцеві точки FastAPI, потоки WebSocket, механізми автентифікації, звіти та API для керування пам’яттю.
• Шар агентів: агенти Cofounder, Manager, Finance, Marketing, Legal, Money та Sales.
• Шар оркестрації: робочі процеси LangGraph разом із власним оркестратором, делегування завдань та контроль стану.
• Пам’ять та інфраструктура: Neo4j, Qdrant, Redis або Upstash, Supabase та системи зберігання звітів.

Згідно з README, стек складається з React 18 разом із Vite, FastAPI, LangGraph та LangChain і CrewAI для роботи агентів, Neo4j, Qdrant та Redis для зберігання даних у пам’яті та чергах, а також Supabase як необов’язковий шар для автентифікації та збереження даних.

Загальний ланцюжок життєвого циклу працює зверху вниз: від ідеї користувача через агентів-лідерів до спеціалістів, а потім у спільну пам’ять, для отримання схвалень та результатів:

User Vision
   ↓
Cofounder Agent
   ↓
Manager Agent
   ↓
Specialist Agents
   ├── Finance
   ├── Marketing
   ├── Legal
   ├── Money
   └── Sales
   ↓
Shared Memory + Approval Gates
   ↓
Reports + Dashboard + Integrations

Головна ідея цього діаграми полягає у тому, що це система робочих процесів, а не ланцюг запитів. Стан, пам’ять, схвалення, повторні спроби, можливість моніторингу та збережені результати є ключовими аспектами.

П’ятиетапний робочий процес

Етап 1: перетворення нечіткої ідеї на структурований контекст

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

Input:
"I want to build an AI tool for small businesses."

Його завдання — перетворити цю інформацію на структурований контекст, з яким зможе працювати решта команди:

Cofounder Output:
- Vision statement
- Target users
- Problem definition
- Market opportunity
- Strategic assumptions
- Initial business direction

У документі README цей крок позначається як „Збір інформації про бачення“. На серверній частині його можна ініціювати через кілька вхідних точок, залежно від того, чи бажає клієнт одноразовий проект, спілкування чи розширену сесію:

POST /api/start-project
POST /api/conversation/start
POST /api/enhanced/start-session

Яким би шляхом не було скористано, серверна частина створює проект або сесію, фіксує початковий стан та надсилає повідомлення відповідному агенту.

Етап 2: планування та делегування менеджером

Коли бачення сформоване, агент-менеджер бере керування на себе та розбиває стратегію на конкретні завдання, які можна реалізувати:

Manager Responsibilities:
- Convert vision into roadmap
- Break work into functional domains
- Create agent assignments
- Define task dependencies
- Decide which agents should execute in parallel

У цьому користувацькому оркестраторі це реалізовано у функції AgentOrchestrator.start_project(), яка знаходиться у файлі backend/flows/orchestrator.py. Вона генерує ідентифікатор проекту, спочатку запускає Cofounder, передає результати Cofounder менеджеру, а потім запускає спеціалістів відповідно до завдань, призначених менеджером. У псевдокоді:

cofounder_result = await Cofounder.execute(vision_task)
manager_result = await Manager.execute(manager_task)
specialist_results = await execute_specialists(manager_result)
generate_outputs(all_results)

Менеджер є шаром керування. Без нього кожен спеціаліст працюватиме із первинною ідеєю окремо та надаватиме результати, які не будуть взаємопов’язані. Саме централізація розбиття завдань у одному агенті дозволяє результатам спеціалістів утворювати цілісний план.

Етап 3: паралельна робота спеціалістів

Як тільки завдання створені, їх беруть на себе агенти домену. Стандартний склад команди та їхні обов’язки такі:

• Співзасновник: бачення, стратегія та ринкові можливості.
• Менеджер: план дій, розбивка завдань та делегування обов’язків.
• Фінанси: модель доходу, модель витрат, показник ROI та прогнози.
• Маркетинг: позиціонування, кампанії та стратегія контенту.
• Юридичний відділ: дотримання правил, оцінка ризиків, контракти та перевірка політик.
• Фінансування: ціноутворення, монетизація та операції з доходами.
• Продажі: процес продажів, звернення до клієнтів та стратегія продажів.

Кожен агент визначений у файлі backend/agents/personalities.py, і кожне таке визначення містить риси характеру, стиль комунікації, сфери експертизи та інструменти, специфічні для певної ролі. Це має велике значення: агенти моделюються як виконавці, притаманні певній ролі, з власною поведінкою, порогами впевненості та контекстом завдання, а не просто як різні запити до системи.

Виконання завдань здійснюється за допомогою функції _execute_specialists(), яка готує по одному завданню для кожного спеціаліста (фінанси, маркетинг, юриспруденція та фінанси, а також продажі у разі їх активації). Кожен виклик агента обгорнутий таймаутом у 60 секунд:

parallel_executions = [
    asyncio.wait_for(agent.execute(task), timeout=60.0)
    for agent_name, task in specialist_tasks
]

Усі ці обгорнуті виклики потім очікуються одночасно:

specialist_results = await asyncio.gather(
    *parallel_executions,
    return_exceptions=True
)

Оскільки функція asyncio.gather() має параметр return_exceptions=True, тайм-аут чи збій у одному агенті повертається як об’єкт винятку у списку результатів замість того, щоб скасувати всю операцію. Це означає, що код, який викликає цю функцію, повинен перевіряти кожен результат та вирішувати, чи потрібно спробувати знову обробити агента, який зазнав помилки, пропустити його чи передати проблему на вищий рівень. Загальне конструктивне рішення є правильним: коли аналіз у сфері фінансів ніколи не потребує результатів маркетингових операцій, або навпаки, немає причин виконувати їх по черзі.

Етап 4: спільна пам’ять та передача контексту

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

Neo4j      → graph memory and relationships
Qdrant     → vector memory and semantic retrieval
Redis      → task queue, cache, runtime coordination
Local data → fallback storage and exported outputs

У документації README це узагальнюється як використання пам’яті графу Neo4j, векторного пошуку Qdrant, черг Redis або Upstash та локального кешування з гнучким переходом на альтернативу. Кожен з цих інструментів задовольняє різні потреби.

Пам’ять графу фіксує зв’язки між агентами, завданнями, проектами та результатами:

Agent → executed → Task
Task → belongs_to → Project
Agent → produced → Output
Output → depends_on → PriorContext

Ця структура дозволяє візуалізувати співпрацю та точно визначити, який агент створив певний результат та на основі якого попереднього контексту.

Векторна пам’ять у Qdrant підтримує семантичне пошукове відновлення, тож агент може звертатися до попередніх робіт за значенням, а не за ідентифікатором:

"Find previous market assumptions."
"Retrieve prior financial analysis."
"Use the earlier legal risk summary."

Пам’ять черг, підтримувана Redis відповідає за координацію під час виконання:

- Event streaming
- Task queues
- Cache
- Agent activity updates
- WebSocket event propagation

Проєкт також грайно реагує на відсутність сервісів. Під час локальної розробки Redis можна замінити адаптером у пам’яті, а виклики LLM можна направити до штучного постачальника. Це знижує бар’єри для запуску всієї системи на ноутбуці без необхідності налаштовувати кожну залежність для продакшену, хоча це також означає, що локальні тести не виявлять проблем, які з’являються лише з реальними сервісами.

Етап 5: схвалення людиною

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

- Customer-facing campaigns
- Pricing recommendations
- Legal-sensitive outputs
- CRM updates
- Social media publishing
- Financial projections
- Business-critical recommendations

У README наголошується на гачках для сповіщень у Slack та налаштовуваних таймаутах для цих процесів схвалення. З боку API схвалення доступне через такі кінцеві точки:

GET  /api/approvals/pending
POST /api/approvals/{approval_id}/respond
GET  /api/approvals/advanced/pending
GET  /api/approvals/stats

Базовий життєвий цикл схвалення виглядає так:

Agent generates action
   ↓
System evaluates confidence/risk
   ↓
Approval request is created
   ↓
Frontend or Slack notifies human
   ↓
Human approves/rejects/provides feedback
   ↓
Workflow continues or stops

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

Усередині бекенду FastAPI

Основна точка входу бекенду, backend/main.py, створює набір глобальних сервісів під час запуску додатку:

AgentOrchestrator
Enhanced Orchestrator
ReportGenerator
SimplePredictor
AgentCollaborator
AdvancedApprovalManager
AgentService
ReportService
LangGraphOrchestrator
Queue Manager

Згідно з README, кожен маршрут підключається через backend/main.py; backend/api/main.py — це більш легкий альтернативний вхідний пункт, який підключає лише частину маршрутів. Код організований за принципом відповідальностей:

backend/
├── main.py                 # Primary FastAPI app
├── api/                    # Route controllers
├── agents/                 # Agent implementations and personalities
├── workflows/              # LangGraph and HITL orchestrators
├── flows/                  # PRD DAG orchestrator
├── memory/                 # Graph, vector, cache managers
├── task_queue/             # Redis/Upstash queue with fallback
├── integrations/           # HubSpot, Slack, Instagram clients
├── approvals/              # Approval managers
├── collaboration/          # Cross-agent communication
├── outputs/                # Report generation
├── analytics/              # Predictions and metrics
├── auth/                   # Supabase auth
├── services/               # LLM, agent, report services
└── tools/                  # Search and tool registry

Варто звернути увагу на розділення між workflows/ (оркестратори LangGraph та HITL) та flows/ (оркестратор DAG, заснований на PRD): проект використовує два підходи до оркестрації одночасно, що забезпечує гнучкість, але вимагає перевірки того, який шлях використовує певний кінцевий пункт.

Інтерфейс API, груповано

Аутентифікація

POST /api/auth/signup
POST /api/auth/signin
GET  /api/auth/user

У режимі, схожому на продакшн, ці кінцеві пункти базуються на аутентифікації Supabase. У локальному чи демонстраційному режимах додаток може повністю пропустити Supabase та використовувати простішу логіку розробки. Опції конфігурації, зазначені в README, включають DEMO_MODE, змінні Supabase та змінні постачальника LLM. Відповідні обробники:

signup()          → creates user account
signin()          → authenticates user
get_current_user()→ verifies token and returns user profile

Життєвий цикл проекту

GET  /api/projects
POST /api/projects
POST /api/start-project
POST /api/auto-execute
GET  /api/auto-execute/status

Це відповідає наступним функціям:

get_user_projects()       → fetch projects for authenticated user
create_project()          → create new project record
start_project()           → execute Cofounder → Manager → Specialists workflow
auto_execute_project()    → start automated coordination from raw vision
get_auto_execution_status() → return execution progress and logs

start_project() є серцем цієї групи. Його внутрішня послідовність є наступною:

1. Generate project_id
2. Execute Cofounder Agent
3. Log Cofounder result
4. Execute Manager Agent with Cofounder context
5. Log Manager result
6. Execute specialist agents in parallel
7. Export and persist final outputs
8. Return project status and timeline

Ця послідовність безпосередньо відповідає AgentOrchestrator.start_project() та _execute_specialists() у модулі оркестрування.

Покращені сесії

POST /api/enhanced/start-session
POST /api/enhanced/continue-session
POST /api/enhanced/approve-and-execute
GET  /api/enhanced/session-status
GET  /api/enhanced/live-logs
GET  /api/enhanced/session-results
GET  /api/enhanced/system-metrics
POST /api/enhanced/cancel-session
POST /api/enhanced/cleanup-sessions

Кожен кінцевий пункт має чітку функцію:

start-session        → create enhanced automation session
continue-session     → continue existing multi-turn planning session
approve-and-execute  → approve captured vision and run workflow
session-status       → inspect session state
live-logs            → stream logs for UI monitoring
session-results      → return final session output
system-metrics       → expose high-level runtime metrics
cancel-session       → stop active session
cleanup-sessions     → remove old sessions

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

Керування агентами

GET  /api/agents/status
GET  /api/agents/list
GET  /api/agents/personalities
GET  /api/agents/configs
POST /api/agents/configs
POST /api/agents/execute
GET  /api/agents/logs/live

Що робить кожен маршрут:

agents/status       → current status of all agents
agents/list         → available agent inventory
agents/personalities→ UI-visible personality metadata
agents/configs      → current agent runtime settings
update configs      → update temperature, approval mode, priority, enabled flag
agents/execute      → execute a single agent manually
logs/live           → recent agent execution logs

Коли ви викликаєте /api/agents/list, список агентів повертається розсортованим у чотири категорії (стратегічні, бізнес-агенти, оперативні та спеціалізовані), а кінцеві точки конфігурації під час роботи дозволяють оператору змінювати параметри такі як температура, режим схвалення, пріоритет та статус активації агента.

Розмови

POST /api/conversation/start
POST /api/conversation/{conversation_id}/message
POST /api/conversation/{conversation_id}/approve

Обробники, які працюють за ними:

start_conversation()     → starts a Cofounder-led discovery conversation
continue_conversation()  → continues the existing conversation with stored context
approve_conversation()   → approves the captured vision and starts task distribution

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

1. User sends initial idea
2. Cofounder Agent asks clarifying questions or structures the vision
3. Conversation state is persisted
4. System detects whether vision is ready for approval
5. User approves
6. System starts agent coordination

У оркестраторі функція start_conversation() присвоює новий ідентифікатор розмови, зберігає те, що написав користувач, викликає агента Cofounder, зберігає відповідь та повертає флаг ready_for_approval, який інформує клієнта про те, чи є концепція достатньо готовою до схвалення.

Робочі процеси LangGraph

POST /api/workflow/execute
POST /api/workflow/resume/{thread_id}

Відповідні функції:

execute_langgraph_workflow() → runs a LangGraph-based workflow
resume_workflow()            → resumes workflow from checkpoint

Ці кінцеві точки безпосередньо використовують шар LangGraph. У документації його описують як станові машини LangGraph, які зберігають свої досягнення у формі чекпоїнтів, можуть самостійно виправляти помилки та містять вузли переривання, де може втрутитися людина. Ключовою властивістю є можливість продовження роботи: коли тривалий процес зупиняється на підтвердження чи зазнає невдачі на певному етапі, він має продовжитися з останнього чекпоїнта, а не починатися знову та оплачувати кожен виклик LLM. Наш огляд того, як InMemorySaver LangGraph зберігає чекпоїнти, пояснює, що саме зберігається на кожному етапі.

Звіти

GET  /api/reports/comprehensive
GET  /api/reports/{report_type}
POST /api/reports/generate-pdf
GET  /api/reports/download/{filename}
GET  /api/reports/domains
GET  /api/reports/domains/{domain}

Що генерує кожен маршрут звіту:

comprehensive report → generate full business report
specific report      → generate executive, marketing, financial, etc.
generate PDF         → convert report data into downloadable PDF
download report      → serve generated PDF/HTML
domain reports       → return modular reports by business domain

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

Пам’ять

GET    /api/memory/graph
GET    /api/memory/stats
POST   /api/memory/export
DELETE /api/memory/clear

І що вони повертають:

memory/graph  → return graph nodes and edges for visualization
memory/stats  → return vector/graph memory statistics
memory/export → export stored memory and outputs
memory/clear  → clear memory stores

README групує їх під /api/memory/* для експорту графіків та статистики. З їх допомогою можна перевіряти накопичені агентами знання, відстежувати їхні результати та бачити, скільки пам’яті використовує кожен бекенд для зберігання даних. Зауважте, що кінцевий ендпоїнт має руйнівний ефект та потребує таких самих механізмів контролю доступу, як і будь-яка інша адміністративна дія.

Аналітика

GET /api/analytics/predictions
GET /api/enhanced/system-metrics
GET /api/communication/stats

Їхня мета:

predictions          → analyze generated outputs and estimate success/revenue/market timing
system metrics       → return enhanced orchestrator metrics
communication stats  → return inter-agent communication analytics

За ними знаходяться прості допоміжні функції:

_analyze_project_success()
_analyze_revenue_trend()
_analyze_market_timing()

Вони аналізують результати роботи агентів та отримують сигнали, корисні для бізнесу, такі як ймовірність успіху, напрямок зростання доходів та рекомендований час дії. Це евристики, створені на основі генерованого тексту, тому їхні результати слід розглядати як орієнтовні, а не як прогнози.

Інтеграції

/api/integrations/*

У репозиторії перелічені HubSpot, Slack та Instagram Business API, кожен з яких виконує певну функцію:

HubSpot   → CRM workflows
Slack     → HITL approval notifications
Instagram → marketing automation with compliance checks

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

WebSockets та стрімінг

WS  /ws/agent-updates
WS  /ws/agent-events
GET /api/stream/logs

Що передає кожен потік:

/ws/agent-updates → periodically sends agent status updates
/ws/agent-events  → streams queue/Redis events to frontend
/api/stream/logs  → streams recent logs via server-sent response

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

Фронтенд на React

Клієнт побудований на такому стеку:

React 18
Vite
React Router
Tailwind CSS
React Flow
Recharts

Згідно з README, панель керування поєднує процес ознайомлення через чат, актуальний статус агентів, візуальну карту потоку завдань та інструменти для перевірки відповідності PRD. Її функції включають:

1. Capture the user’s project vision
2. Display agent execution status
3. Visualize task flow
4. Show pending approval requests
5. Display reports and analytics
6. Show memory/monitoring data
7. Connect to WebSocket streams
8. Communicate with FastAPI through api.js

Вихідна структура є компактною:

frontend/
└── src/
    ├── App.jsx
    ├── pages/
    ├── components/
    └── services/api.js

App.jsx є автентифікованою оболонкою, pages/ містить вікна для роботи з процесами, аналітики та моніторингу, а components/ забезпечує базові елементи: панелі для дашборду, екрани схвалення, вікна для перевірки відповідності PRD та налаштування інтеграції. Кожен HTTP-запит проходить через services/api.js, який об’єднує функції повторних спроб та кешування в одному місці, залишаючи проблеми мережі поза компонентами.

Повний процес

У сукупності основний шлях роботи в системі виглядає так:

1. User submits business vision from React UI
2. Frontend sends request to FastAPI
3. FastAPI creates project/session
4. Cofounder Agent structures vision
5. Manager Agent converts vision into roadmap and assignments
6. Specialist agents execute assigned tasks
7. Results are stored in memory
8. HITL approval is requested where required
9. Reports are generated
10. Frontend displays logs, status, graph, reports, and outputs

Якщо віднести цей процес до конкретних модулів та методів, він виглядає ось так:

React UI
   ↓ HTTP/WebSocket
FastAPI main.py
   ↓
AgentOrchestrator / EnhancedOrchestrator
   ↓
CofounderAgent.execute()
   ↓
ManagerAgent.execute()
   ↓
_execute_specialists()
   ↓
FinanceAgent / MarketingAgent / LegalAgent / MoneyAgent / SalesAgent
   ↓
MemoryManager + GraphMemory + VectorMemory
   ↓
ReportGenerator
   ↓
Dashboard + PDF/HTML/JSON Output

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

Чому саме оркестратор графів, а не ланцюг

Робочі процеси з кількома агентами потребують більшого, ніж просто серії викликів функцій. Їм потрібно:

- State transitions
- Conditional routing
- Checkpointing
- Retry behavior
- Human approval interruptions
- Recovery after failure
- Resume from previous state

У документації README машини станів LangGraph називаються шаром оркестрації саме через ці можливості. Звичайний ланцюг запитів є лінійним:

A → B → C → Done

Бізнес-робочий процес розгалужується на основі проміжних результатів:

A → B
    ├── if finance confidence low → retry Finance
    ├── if legal risk high → ask human approval
    ├── if marketing ready → generate campaign
    └── if all complete → generate report

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

Що правильно реалізовано в дизайні

• Чіткі межі агентів: кожен агент відповідає за одну сферу бізнесу, що забезпечує послідовність результатів та полегшує додавання нових ролей.
• Оркестрація з акцентом на робочий процес: виконання завдань моделюється як робочий процес, а не як послідовність відповідей на запити.
• Паралельні спеціалісти: функції фінансів, маркетингу, юриспруденції, керування коштами та продажів виконуються одночасно, де це можливо через відсутність залежностей, що скорочує час виконання завдань.
• Спільна пам’ять: Neo4j, Qdrant, Redis та локальне зберігання разом забезпечують керування взаємозв’язками, семантичне пошукове функціонування, черги, кешування та альтернативні рішення.
• Безпека завдяки участі людини: механізми схвалення роблять систему придатною для прийняття рішень із реальними наслідками.
• Моніторинг у реальному часі: WebSockets, журнали подій, часові шкали, панелі керування та аналітика дозволяють бачити, що роблять агенти.

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

Готовність до інтеграції: підтримка HubSpot, Slack та Instagram свідчить про те, що система призначена для використання з реальними бізнес-інструментами.

Підготовка до експлуатації

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

1. Add distributed tracing with OpenTelemetry
2. Add LangSmith or custom LLM evaluation dashboards
3. Add cost tracking per agent and per workflow
4. Add stronger RBAC for users, agents, and approvals
5. Add persistent workflow checkpoints in Postgres or Redis
6. Add retry policies per agent type
7. Add queue-based background execution with Celery/RQ/Arq
8. Add structured output validation with Pydantic schemas
9. Add agent-level unit tests and golden-output evaluation
10. Add Docker production profiles and deployment manifests

Два з цих аспектів потребують особливої уваги. Відстеження витрат за кожним агентом та кожним робочим процесом має велике значення, оскільки паралельна робота спеціалістів збільшує кількість викликів ШІ, а витрати залишаються непомітними, доки їх не виміряють. Перевірка структурованого виводу за допомогою схем Pydantic є важливою, адже кожен наступний етап — від запису даних у пам’ять до створення звітів та оновлення CRM — є настільки ж надійним, наскільки правильною є структура даних, яку повертає агент.

Ключові висновки

• Розглядайте шар оркестрації як продукт; ШІ є лише одним з компонентів усередині нього.
• Використовуйте агента у стилі менеджера для керування процесом розбиття завдань, щоб результати роботи спеціалістів залишалися послідовними.
• Запускайте незалежних агентів одночасно з таймаутами для кожного з них та прямо обробляйте часткові помилки.
• Призначте кожному сховищу пам’яті одну функцію: граф для відстеження походження даних, вектори для їх пошуку, черги для координації.

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