Microsoft вывела агенты Azure Functions в public preview на Build 2026 и встроила их прямо в серверless-платформу. Для разработчиков это важный сдвиг: агент теперь можно описать одним markdown-файлом, подключить к 1400+ корпоративным коннекторам и запускать по тем же триггерам, что и обычные функции, без отдельной наценки к Flex Consumption.
По данным InfoQ, новый serverless agents runtime превращает Azure Functions из инструмента для обработки событий в площадку для хостинга ИИ-агентов. Главная идея в том, что агент описывается в файле .agent.md: в YAML-блоке задаются метаданные и триггер, а в markdown-теле лежат инструкции, системный промпт и логика поведения. В результате сценарий, который в других стеках обычно расползается по Python- или TypeScript-проекту с зависимостями и обвязкой, здесь можно собрать в одном читаемом документе.
Microsoft делает ставку на то, что для команд, уже живущих в Azure Functions, порог входа будет минимальным. Запускать агента можно через любой привычный триггер Functions: HTTP, Timer, Service Bus, Event Hubs, SQL или Cosmos DB. Плюс появились connection-backed triggers для сообщений Teams, почты Outlook, событий календаря и элементов SharePoint. Сам агент получает доступ к MCP-серверам, песочнице для запуска кода и браузерному исполнению через Azure Container Apps dynamic sessions. Сверху к этому добавляется каталог из более чем 1400 managed-коннекторов, включая Microsoft 365, Teams, Outlook, SharePoint, Salesforce и ServiceNow.
Самый чувствительный вопрос для практиков здесь не в синтаксисе, а в цене и задержках. Команда Azure Functions отдельно подтвердила InfoQ, что runtime для агентов не добавляет дополнительного cold start сверх того, что уже есть у обычного HTTP-trigger на Flex Consumption. Формулировка у Microsoft показательная: узкое место не инфраструктура, а LLM. Иначе говоря, задержка будет упираться прежде всего в вызов модели и сложность промпта, а не в сам serverless-слой. По деньгам позиция тоже предельно прагматичная: никакого отдельного «налога на агентов» нет, биллинг идет как за стандартное выполнение функции с scale-to-zero и посекундной оплатой в рамках Flex Consumption.
Для рынка это, пожалуй, даже важнее самой markdown-модели. За последний год почти каждая крупная облачная платформа пытается ответить на один и тот же вопрос: как превратить LLM-демо в нормальный production-сервис с авторизацией, трассировкой, безопасным доступом к корпоративным системам и предсказуемой эксплуатацией. Microsoft здесь не изобретает новую вселенную, а встраивает агентный слой в уже знакомый enterprise-контур. Аутентификация остается на managed identity, трейсинг на Application Insights, масштабирование и scale-to-zero тоже не меняются. Меняется только полезная нагрузка: вместо обработки очереди или HTTP-запроса функция просыпается, чтобы запустить рассуждающего агента, вызвать инструменты, сходить в MCP-серверы и выполнить действие в бизнес-системах.
В этом и есть главная ставка на разработчиков и IT-команды. Агенты Azure Functions пытаются продать не как новую магию, а как еще один тип workload внутри существующего облачного операционного контура. Для CTO, платформенных команд и архитекторов это выглядит понятнее, чем очередной отдельный агентный фреймворк с новой моделью деплоя. Для продуктовых и интеграционных команд плюс в другом: можно быстро собирать событийные сценарии на стыке почты, мессенджеров, CRM, сервис-деска и внутренних источников данных, не вытаскивая все в один монолитный пайплайн.
Microsoft, разумеется, не ограничилась красивой теорией. Principal Program Manager Azure Functions Тьяго Алмейда рассказал InfoQ, что команда уже использует такой подход внутри компании: timer-triggered агент на базе .agent.md регулярно проверяет security posture по GitHub-организациям и репозиториям, анализирует branch protection, secret scanning и права workflow, а затем отправляет результаты через те же коннекторы и MCP-серверы, которые доступны внешним клиентам. Аргумент здесь не в том, что Microsoft нашла идеальный use case, а в том, что сама платформа тестируется на скучной, дорогой для ручной рутины задаче. Обычно именно такие сценарии и переживают презентации лучше всего.
На Build 2026 компания подвязала к релизу агентов и несколько соседних обновлений, которые вместе складываются в более цельную картину. MCP extension для Azure Functions дошло до GA и выросло из одного tool trigger в полноценную поддержку MCP server с tool-, resource- и prompt-trigger для .NET, Java, Python, TypeScript и JavaScript. Появилась встроенная OBO-аутентификация, чтобы MCP-серверы на Functions могли наследовать identity вызывающей стороны. Microsoft также планирует интеграцию с Foundry Toolbox, чтобы MCP-серверы, опубликованные из Functions, автоматически обнаруживались агентами Foundry.
Отдельная линия связана с Durable Task Scheduler. Microsoft утверждает, что по мере роста Copilot-команд именно этот слой стандартизировал управление состоянием, ретраи и восстановление для сложных длительных AI-workflow, а система уже обрабатывает сотни миллионов запусков в неделю. Параллельно в private preview показали On-demand Sandboxes: изолированные шаги оркестрации в чистых microVM-песочницах. Сценарии звучат вполне земно: запустить ffmpeg, LibreOffice или Pandoc, сделать тяжелую OCR-предобработку, вызвать Python-инференс из .NET-оркестратора или безопасно исполнять клиентские плагины и код, который сгенерировала модель. Если Microsoft доведет это до стабильного состояния, разговор про «агентов в проде» станет менее философским и более инженерным.
Позиционирование внутри Azure компания тоже проговаривает без особой дымовой завесы. Functions отводят роль code-first слоя для разработчиков, Logic Apps оставляют low-code-интеграциям с визуальным конструктором, а Azure API Management назначают контуром управления поверх обоих вариантов: маршрутизация моделей, content safety для MCP и A2A-трафика, метрики токенов на уровне предприятия. Для клиентов это неплохо хотя бы потому, что Azure пытается не смешивать аудитории в один продукт «для всех сразу».
Теперь интрига не в том, можно ли запускать агентов в serverless, а в том, будет ли markdown-first модель достаточно удобной после первых реальных внедрений. Если агенты Azure Functions и правда сохранят предсказуемую эксплуатацию обычных Functions, а узким местом останется только модель, Microsoft может забрать заметную часть enterprise-сценариев, где агент нужен не для сцены на конференции, а для интеграций, аудита, автоматизации и внутренней рутины. Проверить первоисточник с цитатами команды и деталями анонса можно в .