AI

Microsoft собирает единую платформу для AI-агентов: GitHub, Foundry, IQ и Agent 365

Microsoft переводит разговор об AI-агентах из демо в инфраструктуру. Компания показывает платформу, где GitHub, Microsoft IQ, Foundry, Agent 365, Teams и Microsoft 365 должны работать как один управляемый контур.

Что Microsoft собирает вокруг AI-агентов

Microsoft 2 июня 2026 года опубликовала материал Джея Париха из CoreAI о том, как должна выглядеть платформа для AI-агентов в больших организациях. Главная мысль: одного доступа к модели мало. Агентам нужен полный рабочий контур - от разработки до управления правами и оценки качества.

В статье Microsoft описывает шесть частей платформы: Build в GitHub, Contextualize через Microsoft IQ, Run в Microsoft Foundry, Govern через Agent 365, Improve через оптимизацию Foundry и Surface в Teams и Microsoft 365.

Почему это важно для агентных инструментов

AI-агенты быстро переходят из статуса эксперимента в рабочие процессы: они пишут код, разбирают обращения, вызывают инструменты, работают с данными и запускают цепочки действий. Чем больше таких агентов, тем важнее знать, кто их создал, к каким данным они имеют доступ, что они делают и сколько это стоит.

Microsoft пытается занять место не только поставщика Copilot, но и контрольного слоя для всего парка агентов. Это особенно важно для компаний, где агенты могут появляться в разных командах и на разных стекаx.

Из чего состоит платформа

GitHub отвечает за разработку агентов как обычного production-софта: код, зависимости, work items, skills, tools, evals и observability должны версионироваться и проходить жизненный цикл от source до deploy.

Microsoft IQ нужен для контекста бизнеса: продукты, клиенты, контракты, процессы, базы знаний и данные из Microsoft 365 или других систем. Foundry выступает runtime-слоем, где агенты запускаются, вызывают инструменты, координируются и проходят оценку.

Что нового для разработчиков

Microsoft подчеркивает, что Foundry должен поддерживать не только собственный стек. В списке названы Microsoft Agent Framework, LangGraph, GitHub Copilot SDK, Claude Agent SDK и кастомные harness. Это важная деталь: компания хочет быть площадкой для разных агентных фреймворков, а не закрытым конструктором.

Отдельно упомянуты MCP, connectors, APIs, workflows, evals и traces. Для разработчиков это означает, что агентный проект будут оценивать не только по качеству ответа, но и по наблюдаемости, безопасности вызовов инструментов и предсказуемости действий.

Зачем нужен Agent 365

Agent 365 в этой архитектуре отвечает за governance. Microsoft описывает единый каталог агентов: IT-команда видит, кто развернул агента, какие данные и инструменты ему доступны, как он себя ведет и во что обходится.

Это закрывает типичную проблему agentic AI: отдельные команды быстро делают полезных помощников, но организация теряет контроль над доступами, рисками, затратами и качеством. Без такого слоя агенты остаются разрозненными экспериментами.

Что проверить перед внедрением

Первое - какие данные агент реально видит и кто утверждает эти права. Второе - есть ли evals и traces, которые показывают не только итоговый ответ, но и путь агента к нему. Третье - есть ли политика на tool calls, внешние API, действия с файлами и автоматические изменения.

Microsoft делает ставку на управляемую агентную платформу. Для рынка это значит, что конкуренция будет идти не только между моделями, а между системами, которые позволяют безопасно строить, запускать и улучшать AI-агентов.

Где может быть подвох Agent 365

Идея управлять агентами как отдельным рабочим слоем выглядит логично, но она сразу поднимает сложные вопросы: кто выдает агенту права, кто видит его действия, как ограничить доступ к данным и как понять, что агент не сделал лишнего.

TechSvod считает такие платформы необходимыми для бизнеса, но опасными без governance. Чем больше агент похож на сотрудника внутри систем компании, тем важнее журнал действий, роли, ограничения, review и понятный kill switch.

Кому не нужно внедрять это прямо сейчас

Небольшим командам без сложной IT-инфраструктуры не обязательно первыми бежать за агентной платформой. Если процессы еще не описаны, документы лежат хаотично, а права доступа не настроены, агент только ускорит путаницу.

Сначала стоит выбрать один узкий сценарий: подготовка отчета, triage заявок, помощь разработчику или поиск по внутренним документам. Если там появляется измеримая польза и понятный контроль, тогда можно расширять агентный контур.

Что это меняет для разработчика

Для разработчика такая платформа интересна не лозунгом об агентах, а тем, сможет ли она связать код, задачи, документацию и review без потери контроля. Хороший агент должен помогать делать pull request понятнее, а не просто генерировать больше изменений.

Перед пилотом стоит проверить три вещи: умеет ли агент объяснять правки, можно ли ограничить область файлов и насколько хорошо он работает с существующими тестами. Без этих условий агентная разработка легко превращается в поток непроверенного кода.

Практический вывод для бизнеса

Бизнесу не стоит начинать с покупки большой агентной платформы. Лучше выбрать один измеримый процесс: обработка обращений, подготовка документа, помощь разработчику, поиск по базе знаний или отчетность. У процесса должны быть владелец, метрика и понятная зона риска.

Если агент экономит время и не увеличивает число ошибок, его можно расширять. Если он требует постоянной ручной перепроверки, значит компания пока автоматизирует не процесс, а хаос.

Итог по платформе агентов Microsoft

Microsoft двигается к модели, где AI-агенты становятся управляемой частью корпоративной системы, а не отдельными экспериментами в чате. Это правильное направление для крупных компаний, которым нужны права, аудит, безопасность и интеграция с рабочими инструментами.

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