Що Microsoft насправді зібрав в один стек
Я часто бачив питання на кшталт: це у Microsoft вже четвертий агентний фреймворк чи п'ятий? По факту ні. Зараз мова не про ще один новий зоопарк, а про нормальну консолідацію двох ліній, які раніше жили поруч: AutoGen для оркестрації та Semantic Kernel для enterprise-обв'язки.
4 квітня я поліз перевіряти, де тут маркетинг, а де реальний зсув, і картина доволі приземлена. Microsoft Agent Framework 1.0 вийшов як production-ready SDK для .NET та Python, з довгостроковою ставкою саме на нього. Анонс був ще восени 2025, RC пройшли в лютому 2026, тепер це вже не демо-історія.
Мене зачепило не слово Framework, а те, що вони нарешті перестали змушувати людей склеювати половину системи вручну. Один runtime, єдина модель для multi-agent orchestration, графи, стрімінг, checkpointing, human-in-the-loop. Не революція. Але нарешті схоже на інструмент, який можна тягти в прод, а не лише в презентації.
Де тут підступ з Azure і чи є vendor lock-in
Скепсис щодо vendor lock-in я поділяю. У Microsoft на цю тему репутація, скажімо так, зароблена. Але в цьому кейсі я б не зводив усе до «будь ласка, юзайте тільки Azure AI Foundry».
Agent Framework відкритий під ліцензією MIT, підтримує не тільки Azure, а й будь-який OpenAI-compatible endpoint. Плюс можна ганяти локальні моделі через Ollama і хостити все в ASP.NET Core без обов'язкової прив'язки до хмари Microsoft. Для тих, хто будує архітектуру ШІ-рішень і заздалегідь думає, як потім не вирізати платформну залежність скальпелем, це хороший сигнал.
Окремо важливий серпневий зсув 2025 року з Azure OpenAI v1 APIs. Microsoft тоді явно почав прибирати зайвий Azure-specific overhead і підтягувати сумісність із клієнтами OpenAI. Я це читаю так: вони зрозуміли, що для впровадження штучного інтелекту перемагає не найбільш закритий стек, а той, який найменше заважає розробнику.
А що з RAG, який раніше був квестом на півдня
Ось тут у Microsoft довго було реально важко з DX. Якщо у 2023-2024 роках хтось намагався підняти RAG через Azure AI Search, то пам'ятає цей атракціон з індексами, пайплайнами, ручним збиранням чанкінгу та іншими радощами. Не смертельно, але дружнім це точно не назвеш.
Зараз картина краща. У Foundry Agent Service та навколо нового агентного стеку вже є більш зрозумілий File Search-підхід: завантаження файлів, vector store, підключення до агента, далі сервіс бере на себе чанкінг, ембединги, keyword + semantic search та reranking. Для enterprise RAG це як мінімум знижує поріг входу.
При цьому я б не вдавав, що магію вже вирішено назавжди. Якщо у вас складний домен, нестандартні права доступу, важкі документи, багатомовний пошук або вимоги до explainability, абстракція «просто кинув файли» швидко закінчується. Але як базовий шар для ШІ-інтеграції це вже не соромно показувати команді.
Кому це насправді вигідно
Виграють команди, яким потрібен не research sandbox, а робоча агентна система під процеси бізнесу. Особливо там, де треба швидко зібрати внутрішнього асистента, RAG по документах, операторський copilot або ШІ-автоматизацію поверх CRM, helpdesk та бази знань.
Програють, як не дивно, не конкуренти Microsoft, а старі саморобні збірки. Ті самі, де orchestration жив окремо, retrieval окремо, а glue-code займав більше місця, ніж корисна логіка. Я такі конструкції бачив не раз, і підтримувати їх потім боляче.
Ми в Nahornyi AI Lab якраз на цій ділянці зазвичай і підключаємося: коли потрібно не просто спробувати агента, а зробити ШІ-автоматизацію з нормальною архітектурою, без зайвої хмарної залежності та без фокусів на проді. Іноді стек Microsoft тут підходить відмінно. Іноді ні, і тоді я чесно дивлюся в бік інших варіантів.
Цей розбір написав я, Вадим Нагорний, з Nahornyi AI Lab. Я не переказую пресрелізи, а збираю та перевіряю такі штуки руками в реальних кейсах: RAG, агентні пайплайни, AI-архітектура, інтеграція штучного інтелекту в бізнес-процеси.
Якщо хочете обговорити ваш кейс, замовити ШІ-автоматизацію, створити ШІ-агента на замовлення або зібрати n8n-автоматизацію з LLM поверх ваших даних, пишіть мені. Подивимося, де тут потрібен стек Microsoft, а де краще піти коротшим і дешевшим шляхом.