Weekly AI Roundup: Foundry Agents, MCP Tools, and Enterprise Grounding

by TechHub

This week's AI roundup focuses on Microsoft Foundry's shift from a model catalog to an end-to-end platform for building, operating, and distributing enterprise agents. Build 2026 updates centered on a repeatable operations loop (traces, evaluations, routing, and tuning), production-ready hosted agents with more reliable memory controls, and tool connectivity that scales through Toolboxes and managed MCP servers. On the grounding side, Foundry IQ expanded retrieval and connectors, while Teams and Microsoft 365 Copilot publishing (plus Entra ID-backed A2A endpoints) moved agent deployment closer to where work actually happens.

This Week's Overview

Microsoft Foundry and the enterprise agent platform stack

Building on last week's theme of treating Foundry as an agent platform (not just a place to pick models) with evaluation, routing, MCP catalogs, and operational controls, Microsoft used Build 2026 to position Foundry as the “run it and operate it” layer for agents, not just a model catalog. The through-line across announcements was making agent systems easier to ship with consistent identity, governance, and an operations loop (traces, evals, routing, tuning) that can keep improving after rollout.

A key shift is that Foundry is treating tools and connectivity as first-class deployable assets. Toolboxes and managed MCP (Model Context Protocol) servers aim to reduce one-off tool wiring, while new distribution paths (Teams and Microsoft 365 Copilot) and incoming Agent-to-Agent (A2A) endpoints move agents closer to where work happens, with Entra ID-backed authentication and centralized governance via Agent 365.

Foundry Agent Service: hosted agents, better memory, and closed-loop optimization

Hosted Agents in Foundry Agent Service picked up several production-oriented updates, including an “operations loop” that ties together OpenTelemetry tracing, evaluations, and configuration iteration (a direct continuation of last week's push to ship agents like real services with repeatable evaluation and routing). Microsoft also called out source-code deployments (no container required) and built-in Content Safety guardrails as part of the hosted agent experience, which should lower the bar for teams that do not want to manage container pipelines for every agent revision.

Memory also got a strong reliability push, with procedural memory designed to make recall more consistent, plus practical controls like TTL (time-to-live), multimodal memory, and explicit remember/forget commands. A new portal UI for inspecting and managing memory items makes it easier to debug why an agent “knows” something and when it should stop knowing it.

Agent Optimizer (preview) rounds this out as a closed-loop system: evaluate an agent, generate candidate improvements (instructions, skills, model choice, tool descriptions), rank them, then promote the best configuration. The focus here is not “one more prompt tweak”, but repeatable iteration that can plug into release workflows via Azure Developer CLI (azd).

Toolboxes, routines, and managed MCP: scaling “agents that do things”

Following last week's MCP catalog and scalable tool server coverage (API Center as a catalog and App Service patterns for running MCP servers), Foundry Toolboxes expanded in preview with capabilities like Tool Search (discover tools at runtime), Skills, Work IQ/Fabric IQ integration, browser automation via Playwright, and managed MCP servers. In parallel, Foundry Agent Service introduced “Routines” for trigger-based runs, which helps agents behave more like production services (scheduled or event-driven) instead of only interactive chat sessions.

On the tooling side, Foundry Toolkit for VS Code added an end-to-end hosted agent workflow (scaffold, run, deploy, observe), more Toolbox integrations (including Fabric OneLake), and LangGraph samples that emphasize human-in-the-loop flows and OpenTelemetry tracing into Application Insights. Taken together, this points to a consistent developer loop: build locally, wire tools via MCP, deploy into hosted agents, and debug using standardized traces.

Foundry IQ and the “Three IQs” approach to grounding

This builds on last week's RAG-in-production thread (scaling retrieval and confidence-aware RAG), with Foundry IQ updates emphasizing a serverless retrieval preview, GA knowledge bases with an MCP server, and additional knowledge connectors (Work IQ, Fabric IQ, Azure SQL, MCP). The architectural goal is to ground agents in governed enterprise context without forcing every team to build and maintain a custom retrieval pipeline, and to improve retrieval quality through evaluation-driven iteration.

In Build sessions, Microsoft framed grounding as three complementary context layers: knowledge (Foundry IQ), data (Fabric IQ), and work signals (Work IQ). The practical takeaway for developers is that “RAG” is no longer a single vector store decision; it is increasingly about layering multiple context sources with consistent access control and observability.

Managed compute and model lifecycle: open models with enterprise controls

Foundry Managed Compute (preview) adds a managed GPU hosting layer for open-source and custom models, with deployment templates, cache-aware routing, unified endpoints/SDKs, and built-in observability (continuing last week's emphasis on routing plus evaluation as part of the default platform story, not a separate MLOps build-out). Microsoft also described deployment scopes (Global vs Data Zone) and emphasized Azure-native security and networking controls, which matters if you need open models but still want enterprise guardrails and cost controls.

Alongside that, Microsoft continued pushing an evaluation-first model lifecycle: select models by workload fit, evaluate on your own datasets, then optimize with routing, fine-tuning, and distillation. This is the same operational story repeated across Foundry announcements: measuring and controlling quality/cost is part of the platform, not a bespoke MLOps project.

Enterprise distribution: Teams/M365 Copilot publishing, autopilot agents, and A2A endpoints

Foundry added new distribution capabilities aimed at enterprise adoption: publishing agents into Microsoft 365 Copilot and Teams, introducing autonomous “autopilot agents”, and exposing incoming A2A endpoints secured with Entra ID (a clear follow-on to last week's governance theme of making agents deployable and administrable like standard enterprise services). This is effectively an “agent app store” pattern for internal organizations, with a control plane (Agent 365) that can apply governance consistently across deployment and usage.

This matters if your current “agent deployment” is a web app URL and a readme. With first-class distribution, identity, and governance, teams can treat agents like managed products, with discoverability and administrative oversight rather than ad hoc sharing.