Один стек для 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-агент для малого бізнесу

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

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, продажі, документація продукту.

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 + спеціалісти

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

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

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

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

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

Підсумок

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

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

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

Джерела

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

• Microsoft: Semantic Kernel і Microsoft Agent Framework

• Atlan: Microsoft Agent Framework 1.0, GA 3 квітня 2026

• HPCwire: Google Gemini Enterprise Agent Platform

• The New Stack: Google і Cloud Next '26

• FactualMinds: Bedrock AgentCore vs Amazon Quick Suite