Weekly AI Roundup: Production Agents, Governed Data, Safer Tooling

by TechHub

This week focused on making AI agents more controllable in real workflows, from Copilot context improvements and tracing in VS Code to enterprise-managed CLI plugins, model deprecation deadlines, and clearer review hygiene for agent-authored PRs. Microsoft advanced production agent building and deployment with the Agent Framework and Azure AI Foundry, while Fabric and Databricks shipped practical operations features for discoverability, concurrency, monitoring, and recovery. Security and governance news emphasized token theft defense, passkey rollout realities, and shifting scanning earlier into agent tools with GitHub MCP Server and runtime-aware code-to-cloud visibility.

Microsoft Agent Framework in .NET: agent building blocks, orchestration patterns, and a production deployment path

The Microsoft Agent Framework (v1.0) continued to take shape as a practical set of .NET building blocks for agentic apps, extending the same “from local to production” story we covered last week into more concrete .NET-first primitives. Jeremy Likness framed it as the third building block alongside the broader Microsoft.Extensions.AI story, focusing on what you need once you move past single-prompt chat: tool calling to let the model take actions, sessions (via AgentSession) to keep multi-turn state coherent, and memory via context providers (AIContextProvider) so the agent can retrieve and inject the right information at the right time. A key theme is that “agent” is not just a wrapper around an LLM call, its the combination of tools, state, and structured flow that makes behavior repeatable. That emphasis on structured flow showed up again in Jacob Alber's walkthrough of the Handoff orchestration pattern. It is a practical continuation of last week's focus on multi-agent workflows that can be run and shipped, not just diagrammed. Instead of one agent trying to do everything, you define a bounded graph of agents and let them route control between each other using injected handoff tools, while maintaining a shared transcript so context does not get lost mid-transfer. The post contrasts Handoff with Sequential and explicit conditional workflows, and includes both .NET and Python examples, plus guidance on when to add Human-in-the-Loop (HITL) checkpoints so the system can escalate decisions rather than guess. The other half of the story was what happens after your agent works locally. Following last week's introduction of Foundry Hosted Agents as the “where does the code actually run?” answer, Tao Chen and Shawn Henry described how to deploy Agent Framework agents to Foundry Hosted Agents (Foundry Agent Service) in Azure AI Foundry, with concrete steps that mirror real delivery pipelines: container packaging with Azure Developer CLI (azd) and Azure Container Registry (ACR), choosing between protocol styles (/responses vs invocations) depending on how you want clients to interact, and wiring identity through Microsoft Entra ID instead of shipping keys around. They also call out operational basics that agent apps need just as much as APIs do, like versioned rollouts and built-in observability through Application Insights, so you can see tool calls, failures, and latency once the agent is under real load. Read together with last week's OpenTelemetry-first messaging, the direction is consistent: Microsoft wants agent apps to inherit the same deployment and operations discipline teams already apply to services.

Azure AI Foundry + Fabric data: governed knowledge sources and real-world operations

Azure AI Foundry pushed further into “use your real data, but keep it governed” by making the OneLake catalog natively available in Foundry (now generally available). This is a direct continuation of last week's MCP-through-Fabric storyline, where Fabric started to look like an AI tool surface and operational plane for agents. Here, the focus is more on the RAG setup path and discoverability: instead of switching contexts to hunt for datasets, you can browse OneLake assets directly while creating knowledge sources, which matters when teams want retrieval-augmented generation (RAG) that is both discoverable and compliant. The GA post walks through prerequisites and the setup path for creating a Foundry knowledge base backed by OneLake and Azure AI Search, a common pairing when you need governed storage (Fabric) plus an index optimized for retrieval (AI Search). It also matches the broader Foundry direction from last week, where governance and reuse move “up a layer” so teams can scale beyond one-off demos. A Microsoft case study made that architecture feel less abstract by showing how Porsche Cup Brasil built AI-assisted race operations on the same stack. Their crash analysis workflow uses Azure AI Foundry with Azure AI Search and Microsoft Fabric, with apps running on Azure Kubernetes Service (AKS) and a human validation step to confirm conclusions before decisions get acted on. That HITL step echoes the practical safety thread running through both weeks: agentic systems need approval paths and auditability when outcomes matter. The broader operations loop pulls real-time telemetry into Fabric and visualizes it with Power BI for anomaly detection during races, illustrating a pattern many teams will recognize: stream data into an analytics layer, let AI help summarize or classify events, then keep a human in the approval path when the cost of a wrong call is high.

Agentic developer experience: IDE chat sessions, safer terminals, and editors that can opt out of AI

Tooling changes this week reflected a common friction point with agentic workflows: once you have multiple conversations, multiple models, and terminal access, the UI and safety defaults start to matter. That lines up with last week's platform-side emphasis on “safe to run” agents (sandboxing, identity, observability), but viewed from the developer workstation where accidents (like leaking secrets) actually happen. Visual Studio Code 1.120 (Insiders) refined chat and agent workflows with session organization changes (helpful when you are juggling several tasks), a model context size picker (so you can trade off cost/latency vs how much context the model can read), and safer handling of terminal password prompts to reduce the chance of accidentally leaking secrets into an agent session. For extension authors, it also introduced a proposed customDiffEditorProvider API, alongside improvements across GitHub and Copilot CLI-related integrations. On the editor side, Zed reached version 1.0 and positioned itself clearly as a “traditional editor and AI tool” rather than an AI-first environment. DevClass highlighted its Rust-based implementation, LSP-driven language support, and optional AI features that include Zeta LLM predictions and parallel agents, plus support for Agent Client Protocol (ACP). The practical detail many teams will care about is that AI can be disabled entirely, which complements the broader enterprise control story from last week (governed tools, identity boundaries, and hosted isolation): sometimes the safest AI feature is the one you can reliably turn off where policy demands it.

Applied agent patterns in teams: stand-ups, document pipelines, and production-minded tutorials

Several posts focused less on platforms and more on what teams are actually building with LLMs and agents, reinforcing the same “production reality” theme that ran through last week's Agent Framework and Foundry updates. John Edward's “Daily Stand-Up Agent” design connects to Jira and Azure DevOps, grounds responses on sprint and work item data, and uses LLM summarization to generate stand-up notes, blocker alerts, and sprint health reporting through a conversational interface. It highlights the integration work that tends to dominate these projects (Azure DevOps Work Item APIs, Jira REST API, OAuth, and RBAC), and why grounding plus prompt design matters when summaries must reflect real status rather than plausible text. On the data extraction side, tanyabaranwal shared an event-driven pipeline for contract processing that starts with Blob Storage and an Azure Functions Blob trigger, uses Azure AI Document Intelligence to extract layout and tables, normalizes the output into a canonical JSON schema, and stores results in Cosmos DB for downstream use. The post rounds out the “production” story with monitoring in Application Insights and security practices like Key Vault, Managed Identity, and RBAC, which tracks closely with the lifecycle framing from last week (identity, governance, and observability as defaults rather than add-ons). Even when this is not presented as an “agent,” it fits the same operational model: AI components become dependable services only when they ship with the same controls you expect for any other workload. Rounding out the week, GitHub's “Rubber Duck Thursdays” episode walked through building an AI agent app for a fictional company, including what changes when you plan for production deployment rather than a local prototype. That mirrors Microsoft's recent messaging almost point-for-point: the throughline across these examples is that the agent behavior is only half the job, the rest is connectors, identity, monitoring, and a clear strategy for what the model can and cannot do in your workflow.