Weekly AI Roundup: Agent Interop, Foundry Ops, and RAG Governance
Copilot moves toward more agentic workflows across IDEs and GitHub, while June 1 brings token-based billing, AI Credits, and new meters like Actions minutes for private-repo code review. In parallel, Microsoft and the broader ecosystem tightened the production story for agents with GPT-5.5 in Foundry, GA interoperability protocols (A2A and MCP), and more concrete guidance on observability, retrieval, and governance. Platform updates across Azure and Fabric focused on controlled operations: sovereign and disconnected deployments, least-privilege storage access, SLI/SLOs in Azure Monitor, and better real-time pipeline monitoring.
Azure AI Foundry and Microsoft Foundry: GPT-5.5 lands, and the platform story gets clearer
Microsoft put GPT-5.5 into general availability inside Microsoft Foundry, positioning it as a more enterprise-ready way to consume frontier OpenAI models with the controls teams expect. The update calls out practical model-level gains like stronger agentic coding behavior, improved long-context reasoning, and better token efficiency, which matters when you are building multi-step agent flows that keep state, retrieve sources, and iterate. The more important shift is the surrounding platform: Foundry Agent Service is framed as the operational layer for hosted agents, with isolation boundaries, Microsoft Entra identity integration, and governance so teams can manage access and reduce the “who can make the agent do what” risk that shows up quickly in enterprise deployments. On the developer experience side, Foundry Toolkit added an in-editor image generation loop in VS Code. The flow is designed to be end-to-end: browse the model catalog, deploy GPT-Image-2 into an Azure AI Foundry project, generate images in an Image Playground, then export code snippets you can drop into an app. It is a small update, but it reflects a pattern Foundry is pushing this month: keep model selection, deployment, experimentation, and integration in one place so teams do not treat “prompting” and “shipping” as two separate projects.
- OpenAI’s GPT-5.5 in Microsoft Foundry: Frontier intelligence on an enterprise ready platform
- Streamline Image Generation Workflow in Foundry Toolkit
Microsoft Agent Framework 1.0 and A2A v1: interoperability becomes a first-class feature
Agent work this week was less about “how to build an agent” and more about “how agents talk to other agents and tools without custom glue.” Microsoft Agent Framework 1.0 reached GA with a clearer split between agent architecture and traditional workflow orchestration, plus a set of runtime components meant to standardize how you host, route, and invoke tools across deployments. Two interoperability pieces stand out. First is A2A (agent-to-agent), which is positioned as a common way for agents to communicate across platforms. Second is MCP (Model Context Protocol), which is used as the tool invocation and connectivity layer so an agent can call capabilities without every team inventing its own tool schema. For .NET teams, A2A Protocol v1.0 support landed in Microsoft Agent Framework for .NET with updated client and hosting packages and some concrete hosting details that matter in production. Discovery is handled via well-known agent cards (so clients can find capabilities without hardcoding), and streaming is supported over Server-Sent Events (SSE), which is a practical fit for incremental agent output and UI updates. The post also calls out migration notes from v0.3, which helps teams who started experimenting earlier move to the now-stable protocol and hosting APIs in ASP.NET Core.
- The Future of Agentic AI: Inside Microsoft Agent Framework 1.0
- A2A v1 Is Here: Cross-Platform Agent Communication in Microsoft Agent Framework for .NET
Foundry IQ and agentic retrieval on Azure AI Search: building knowledge copilots with fewer shortcuts
Enterprise RAG (retrieval-augmented generation) keeps running into the same hard problems: permissions, citations, query quality, and latency once you add multi-step reasoning. Two posts this month focused on Foundry IQ as the knowledge layer for that problem, backed by Azure AI Search. One walkthrough shows how to build an “enterprise knowledge copilot” using Foundry IQ knowledge bases with an agentic retrieval loop (plan, search, rank, reflect, synthesize). The point is not that agents can search, but that retrieval becomes iterative and self-correcting, which is often what it takes to get stable answers across messy internal content. It also leans on MCP-based connectivity so the agent can connect to tools and retrieval services in a standard way, while being candid about the real trade-offs teams need to measure (preview maturity, cost, latency, and security constraints).
A companion guide tries to reduce confusion about what Foundry IQ is and is not, when it fits, and how to use it without going through a full “copilot” layer. It highlights querying Foundry IQ knowledge bases directly with the Azure AI Search Python SDK (azure-search-documents), including returning citations and applying permission trimming so the retrieval layer respects user access (often enforced through Microsoft Entra ID patterns in enterprise environments). Together, the posts land on a pragmatic message: treat the knowledge base as a governed, queryable asset first, then decide how much agentic orchestration you actually need.
- Building an Enterprise Knowledge Copilot with Foundry IQ and Agentic Retrieval on Azure AI
- Making Sense of Azure AI Foundry IQ
Agent-driven UI and operations: streaming interfaces and real observability for agent workloads
As agents become long-running and multi-step, the UI and ops story matters as much as the prompt. AG-UI was introduced as a protocol for how agents communicate with frontends using streaming events, declarative UI proposals, and shared state updates, with explicit support for human-in-the-loop interrupts so a user can approve, correct, or stop actions mid-flight. The design lines up with the same streaming patterns showing up elsewhere (notably SSE), and the security notes point teams back to common Azure controls like Azure AD (Microsoft Entra) for securing endpoints and Key Vault for handling secrets. On the operations side, another post focused on observability for agent workloads in Azure AI Foundry, specifically what it takes to get traces you can actually use in incident response and performance work. It compares tracing depth and setup effort across Microsoft Agent Framework, Semantic Kernel, LangChain/LangGraph, and the OpenAI Agent SDK, using OpenTelemetry pipelines into Azure Monitor and Application Insights. The practical takeaway is that “agent observability” is not a single feature toggle; it is a combination of consistent spans/attributes across tool calls and model invocations, plus an instrumentation story that does not collapse once you add multiple agents, external tools, and streaming responses.
- AG-UI: The Future of Agent-Driven User Interfaces
- Operating AI Agents on Azure: Observability with Azure AI Foundry
Other Artificial Intelligence News
Microsoft highlighted a real multi-agent workflow in science with Microsoft Discovery, describing an automated computational chemistry screening pipeline that runs Gaussian 16 DFT simulations in parallel (using an MPI-style master-worker pattern), then feeds results into ML-based redox potential prediction with structured JSON outputs so downstream systems can consume the results reliably.
- How Microsoft Discovery Is Empowering Scientists to Do More A .NET-focused tutorial showed how to extend an agent built with the .NET Agent Framework by adding a class-based skill, using a locally hosted LLM through Ollama, which is a useful pattern when you want the “skills” abstraction without requiring a hosted model for every experiment.
- Add class-based skill to an AI agent in .NET Agent Framework