# Один стек для AI-агентів у 2026: що змінили Microsoft, Google та AWS і який стек обрати без хайпу

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

## Коротка відповідь

Одного коробкового продукту, який закриє все під ключ, немає. Але 'хаос із 20 сервісів' теж не єдина альтернатива. Реалістичний варіант: обрати **одну керуючу екосистему** і додавати до неї лише те, чого бракує (окрему векторну базу, observability, evaluation, власний інтерфейс).

## Що змінилося у 2026 році

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

*   **Microsoft.** Semantic Kernel і AutoGen об'єднали в Microsoft Agent Framework. Версія 1.0 вийшла 3 квітня 2026 і є наступником обох. Для нових проєктів дивитися варто туди.
    
*   **Google.** Сервіси й roadmap Vertex AI тепер постачаються через Gemini Enterprise Agent Platform, а не як окрема лінійка. 22 квітня 2026 Google оголосив Gemini Enterprise Agent Platform як його еволюцію. Agent Builder тепер частина цієї платформи: агентів збирають або у візуальному Agent Studio, або кодом через Agent Development Kit (ADK). Окремо є застосунок Gemini Enterprise для співробітників, і саме його часто називають «сирим». Це інший шар того самого стеку.
    
*   **AWS.** Amazon Q Business, за даними кількох джерел, перестав приймати нових клієнтів після 31 липня 2026. Нових покупців скеровують на Amazon Quick Suite (інтерфейс для співробітників) і Bedrock AgentCore (інфраструктура для агентів). Bedrock Agents Classic також закритий для нових клієнтів, а для нових проєктів AWS позиціонує AgentCore. Джерела тут вторинні, тому перед рішенням перевірте в документації AWS.
    

Моделі теж змінилися. Claude 3.5 Sonnet, Gemini 1.5 і GPT-4o як 'поточний стандарт' уже не пишуть. У статтях краще писати нейтрально ('модель Claude через Bedrock'), бо версії міняються швидше, ніж виходять тексти.

## Три міфи, які варто викинути

**1\. 'У кожної хмари свої моделі'.** Це вже не так. Claude доступний не лише в AWS, а й у Google Model Garden, і, наскільки мені відомо, у Microsoft Foundry. Вибір хмари більше не прив'язує вас до однієї моделі.

**2\. 'Серйозний бізнес не використовує прямі API'.** Занадто категорично. Комерційні API провайдерів зазвичай не тренуються на ваших даних, а enterprise-контракти з SLA можна укласти й напряму. Хмару обирають частіше заради єдиної системи доступів, мережевого периметра, закупівель і compliance, а не тому, що прямий API 'несерйозний'.

**3\. 'LangGraph - індустріальний стандарт'.** Він сильний і популярний, але стандарту немає. Поруч існують вендорські SDK (OpenAI Agents SDK, Google ADK, Microsoft Agent Framework), CrewAI, LlamaIndex і звичайний код із durable-оркестратором. Обирайте під задачу, а не під модний список.

## Як обирати основу: два запитання

**Де вже живуть ваші дані та ідентичність користувачів?**

> Microsoft 365, Google Workspace чи ваші сервери на AWS. Агент, якому не потрібно заново будувати права доступу, з'являється швидше й безпечніше.

**Скільки інженерів ви готові тримати на підтримці?**

> Якщо жодного, дивіться на керовані продукти (Copilot Studio, Gemini Enterprise, Quick Suite) або low-code. Якщо є команда, можна брати AgentCore, ADK або Agent Framework. Для малого бізнесу, де інженер один, часто виграє легший стек.

## Яку екосистему обирати: ситуація → стартова точка

| Ситуація | З чого почати | Чому |
| --- | --- | --- |
| Компанія на Microsoft 365 | Foundry + Microsoft Agent Framework + Copilot Studio | Дані, identity, Teams і SharePoint вже в одній екосистемі |
| Компанія на Google Workspace | Gemini Enterprise Agent Platform + ADK | Agent Studio, ADK і Model Garden в одному контурі |
| Інфраструктура на AWS | Quick Suite для співробітників + AgentCore для власних агентів | Managed-асистент для людей і окремий runtime для кастомних агентів |
| Малий бізнес, Telegram-бот | n8n або власний FastAPI + LangGraph | Швидше до MVP, менше vendor lock-in |
| Агент усередині CRM | Salesforce Agentforce або HubSpot | Дані й процеси вже там |
| Аналітика та RAG по даних | Databricks або Snowflake | Дані та governance вже там |
| Регульовані процеси, безпека | Tines або Workato | Сильніші контролі над процесами |

## Які ще є варіанти, крім 'великої трійки'

*   **Екосистеми провайдерів моделей:** Anthropic, OpenAI та їхні SDK. Мінус: прив'язка до моделей одного вендора.
    
*   **Платформи з вбудованими агентами:** Salesforce Agentforce, ServiceNow, HubSpot. Працюють добре, якщо ваш процес уже живе в цій системі.
    
*   **Data-платформи:** Databricks, Snowflake. Логічні, якщо дані вже там, а головна задача - аналітика або RAG.
    
*   **Workflow-платформи:** n8n (можна self-hosted), Dify, Flowise, Langflow. Швидко збирають автоматизації навколо Telegram, пошти, CRM, таблиць. Слабші в enterprise-контролях.
    
*   **Automation для бізнес-процесів:** Retool, Workato, Tines. Підходять, коли агент має діяти в CRM, ERP, HR або безпеці, а не просто відповідати.
    
*   **Власний open-source стек:** Postgres із pgvector, Langfuse, LiteLLM, свій інтерфейс. Максимум контролю, але платите годинами інженерів.
    

## Архітектурні патерни, які реально працюють

Головне правило: не будуйте одного «супер-агента». Розділяйте відповідальність.

**RAG-бот.**

> Модель відповідає лише на основі перевірених документів. Потрібні ingestion (chunking, embeddings), гібридний пошук і логування кожного кроку.

**Router + спеціалісти.**

> Координатор визначає намір і передає запит агенту з потрібною компетенцією (HR, IT, продажі, підтримка). Описи агентів працюють як документація для роутера, тому пишіть їх чітко.

**Послідовний конвеєр.**

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

**Generator + Critic.**

> Для коду, договорів, текстів. Критик не повинен бути лише ще однією LLM: додайте детерміновані перевірки (схема, лінтер, тести), ліміт ітерацій і підтвердження людини перед публікацією.

**Human-in-the-loop.**

> Обов'язково, якщо агент може витрачати гроші, змінювати дані, деплоїти або писати клієнтам. Дозволи на кожного агента, аудит кожного виклику інструмента, ліміти, явне підтвердження незворотних дій.

Паралельний fan-out (кілька незалежних перевірок одночасно, наприклад security, стиль, продуктивність) додавайте тоді, коли вони справді незалежні.

## Чотири приклади архітектур

### 1\. Telegram-агент для малого бізнесу

Лідогенерація, запис на послугу, підтримка, обробка заявок.

```text
Telegram-користувач
      │
      ▼
aiogram + FastAPI webhook
      │
      ▼
LangGraph (або Microsoft Agent Framework)
      │
      ├── RAG tool ──────> Postgres + pgvector
      ├── CRM tool ──────> Notion / HubSpot / Google Sheets
      ├── Payment tool ──> Stripe / WayForPay
      └── Approval tool ─> Telegram-чат адміністраторів
      │
      ▼
Langfuse / OpenTelemetry
```

Це мінімальний production-стек, а не ідеальний: aiogram для інтерфейсу, FastAPI для webhook і API, Postgres з pgvector для користувачів, сесій і знань, Langfuse для трасування, Redis для rate limiting і черг, Docker на VPS чи Render/Fly.io для деплою.

### 2\. RAG-асистент для внутрішньої бази знань

HR, IT helpdesk, продажі, документація продукту.

```text
SharePoint / Google Drive / Notion
      │
      ▼
Ingestion: parser → chunker → embeddings
      │
      ▼
Векторне сховище / пошуковий сервіс
      │
      ▼
Агент: retrieve → відповідь із посиланнями на джерела
      │
      ▼
Slack / Teams / застосунок команди
```

| Потреба | Microsoft | Google | AWS | Self-hosted |
| --- | --- | --- | --- | --- |
| Пошук по документах | Azure AI Search | Vertex AI Search | Bedrock Knowledge Bases | pgvector + власний pipeline |
| Інтерфейс для команди | Teams / Copilot Studio | Застосунок Gemini Enterprise | Quick Suite | Slack або власний Web UI |
| Runtime агента | Microsoft Agent Framework | ADK | AgentCore Runtime | FastAPI + LangGraph |

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

### 3\. Router + спеціалісти

```text
Slack / Teams / Telegram
        │
        ▼
Triage Agent
        │
        ├── Billing Agent ──> Stripe / CRM
        ├── Support Agent ──> Zendesk / база знань
        └── IT Agent ───────> Jira / Confluence
        │
        ▼
Відповідь + audit log
```

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

### 4\. Обробка документів

```text
PDF-рахунок
   │
   ▼
Parser → Extractor → Validator → дія в ERP
   │
   └── апрув людини, якщо сума перевищує ліміт
```

Кожен крок пише результат у власний ключ стану: `parsed_text`, `extracted_fields`, `validation_result`, `erp_action`. Так простіше дебажити й відкочувати помилки.

## Антипатерни

*   **Один агент із 30 інструментами.** Модель плутається, зростає затримка, промпт стає нестабільним.
    
*   **Векторна база як «пам'ять» за замовчуванням.** Vector search це retrieval, а не довгострокова пам'ять про користувача.
    
*   **Агент без audit log.** Ви не відповісте, хто, коли, з якими даними і чому зробив дію.
    
*   **Автономні дії без апруву.** Платежі, видалення, деплой, листи клієнтам.
    
*   **MCP заради MCP.** Протокол корисний, коли інструментів і систем багато. Для одного Telegram-бота він може бути зайвим.
    
*   **Фреймворк раніше за процес.** Спершу опишіть процес: вхід → рішення → дія → перевірка → ескалація.
    

## Мінімальний практичний стек

Для Telegram-бота або внутрішнього агента в малому бізнесі я б починав із такого набору:

*   інтерфейс: Telegram-бот, Slack або веб;
    
*   backend: FastAPI або Cloudflare Workers;
    
*   логіка: LangGraph або простий власний цикл;
    
*   пам'ять і знання: PostgreSQL із pgvector;
    
*   спостережуваність: Langfuse або OpenTelemetry;
    
*   апрув людиною: окремий чат для адміністраторів.
    

Порядок впровадження: спочатку **один RAG-бот**, потім **router і 2–3 спеціалісти**, і лише потім складна мультиагентна система. Вкладені цикли з першого дня майже завжди ускладнюють налагодження без користі.

## Що не зміниться за рік

*   Дані та права доступу залишаться головним вузьким місцем.
    
*   Апрув людини залишиться обов'язковим для незворотних дій.
    
*   Observability і evaluation стануть стандартом, а не опцією.
    
*   MCP і A2A корисні як інтерфейси, але не замінюють архітектуру.
    
*   Ціна помилки агента важливіша за вибір моделі.
    

## Чекліст перед production

*   \[ \] Агент має окрему identity та мінімальні права.
    
*   \[ \] Кожен виклик інструмента логується.
    
*   \[ \] Є ліміти на кількість викликів, вартість і доступні системи.
    
*   \[ \] Незворотні дії проходять апрув людини.
    
*   \[ \] RAG повертає джерела, а не лише відповідь.
    
*   \[ \] Є evaluation-набір на реальних кейсах.
    
*   \[ \] Модель можна замінити без переписування агента.
    
*   \[ \] Є план відкату, якщо агент почав діяти неправильно.
    

## Що далі: коли агентів стає багато

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

Я окремо розібрав це в статті **«Buildkite: огляд CI/CD-платформи, яку обрали OpenAI, Anthropic, Meta та Nvidia»**:

[Buildkite: огляд CI/CD-платформи, яку обрали OpenAI, Anthropic, Meta та Nvidia](https://dou.ua/forums/topic/62205/)

Там - про CI/CD для AI-систем, паралельні тести, динамічний sharding, кейс Uber і те, де Buildkite справді потрібен, а де достатньо GitHub Actions чи GitLab CI.

## Підсумок

Шукати 'єдиний ідеальний продукт' марно. Корисніше вирішити три речі: де ваші дані, хто це підтримуватиме і де потрібна людина в циклі. Решта (назви продуктів, версії моделей, брендинг платформ) змінюватиметься щокварталу, тому закладайте змінність у архітектуру: gateway для моделей, протоколи на кшталт MCP для інструментів, логування з першого дня.

Якщо хочете розібрати свій випадок, пишіть у Telegram-канал @aibiz\_ua або на kotovich.uk.

*Без хайпу, тільки те, що реально працює.*

## Джерела

Це матеріали, які я знайшов пошуком. Частина з них вторинні (блоги й огляди), тому ключові дати варто звірити з офіційними анонсами вендорів.

*   [Microsoft: Semantic Kernel і Microsoft Agent Framework](https://devblogs.microsoft.com/agent-framework/semantic-kernel-and-microsoft-agent-framework/)
    
*   [Atlan: Microsoft Agent Framework 1.0, GA 3 квітня 2026](https://atlan.com/know/ai-agent/microsoft/agent-framework/)
    
*   [HPCwire: Google Gemini Enterprise Agent Platform](https://www.hpcwire.com/aiwire/2026/04/23/google-unveils-gemini-enterprise-agent-platform/)
    
*   [The New Stack: Google і Cloud Next '26](https://thenewstack.io/google-finally-builds-the-ai-and-agent-platform-its-been-describing-for-years/)
    
*   [FactualMinds: Bedrock AgentCore vs Amazon Quick Suite](https://www.factualminds.com/blog/aws-bedrock-agentcore-vs-amazon-q-enterprise-decision-guide-2026/)