Weekly AI Roundup: Copilot Agents, MCP Security, and RAG Patterns
This week's Weekly AI Roundup is about AI moving from chat helpers to agent-driven workflows that ship real code and run inside everyday team processes. GitHub Copilot's new desktop app, stronger CLI and IDE agent modes, and GitHub-side changes (review shaping, PR attribution, issue triage) all point to agents becoming normal collaborators, with MCP as the connective tissue. At the same time, model routing, lifecycle changes, and per-user spend reporting are turning cost and policy into daily ops concerns. We also cover MCP's expanding tool ecosystem (from APIM gateways to MSBuild binlog analysis), the AutoJack security lesson on trust boundaries, and practical grounding patterns for RAG across Azure AI Search, file data via OneLake shortcuts, and Postgres-backed retrieval.
This Week's Overview
- GitHub Copilot shifts from “chat in your editor” to agent-driven workflows
- Model choice, routing, and spend tracking become day-to-day concerns
- Auto mode in Copilot Chat goes GA for all plans (with token billing incentives)
- Token efficiency work lands in VS Code: caching, tool search, and WebSockets
- VS Code BYOK expands model choice (and changes how you operationalize access)
- Copilot model availability changes: MAI-Code-1-Flash expands, Opus 4.6 (fast) deprecates
- Usage and billing visibility: per-user credits and broader active-user reporting
- MCP everywhere: tool ecosystems mature, and security catches up
- Enterprise tool control with APIM as an MCP gateway
- ARM MCP Server PoCs: deterministic infra agents built on Resource Graph + deployments
- Build troubleshooting gets agent-friendly: MSBuild Binlog MCP Server (preview)
- Security wake-up call: AutoJack RCE chain in AutoGen Studio via localhost MCP WebSocket
- RAG and data grounding patterns: from Azure AI Search to Postgres and OneLake-connected files
- Local AI and enterprise agent platforms: Windows expands on-device options, Foundry pushes RL loops
- AI security and defense: agentic scanning moves into production, identity defenses go agent-native
- GitHub and Azure migration/modernization: agents move up to portfolio-level planning
- Other Artificial Intelligence News
GitHub Copilot shifts from “chat in your editor” to agent-driven workflows
GitHub Copilot app reaches GA (desktop, issue-to-PR flow, canvases, MCP)
Following last week's focus on shipping and operating agents as real services (with MCP as the tool wiring layer), GitHub shipped the GitHub Copilot app as a generally available desktop experience on macOS, Windows, and Linux, centered on an agent-driven workflow that starts from Issues or PRs and ends with a pull request that runs your existing checks. The app leans on “canvases” (a workspace where the agent can draft plans, code, and artifacts) plus cloud automations, and it can integrate with your own tools and models through Model Context Protocol (MCP) servers.
For developers, the practical shift is that Copilot work can live “next to” your repo and collaboration objects instead of being trapped inside a single IDE tab. The related walkthrough content highlights patterns like plan mode, agent merge, and handling CI failures inside the agent loop, plus the Git mechanics (notably Git worktrees) that make parallel agent sessions less painful.
- GitHub Copilot app generally available
- GitHub Copilot App Launch - Rubber Duck Takeover!
- How to take work from issue to merge with the GitHub Copilot app
- Exploring the agent-first GitHub Copilot desktop app | GitHub Checkout
- RDT: Exploring the GitHub Copilot App
- What are git worktrees, and why should I use them?
- Can the GitHub Copilot app run Doom?
Copilot CLI and JetBrains: slash commands, agent modes, and MCP connections
GitHub continued to invest in Copilot CLI as a “front door” to agentic workflows, publishing beginner-focused resources that cover setup, interactive vs non-interactive usage, slash commands, and connecting MCP servers. The companion JetBrains content shows Copilot CLI embedded into JetBrains IDEs with ask/plan/agent modes, along with tooling to inspect token usage and debug logs.
The immediate win is standardizing an agent workflow across environments (terminal, IDE, CI), which echoes last week's theme that tool connectivity (via MCP) only pays off when it's packaged into repeatable workflows rather than one-off chat sessions. If you're wiring in enterprise tools through MCP, the CLI tutorials are a good reminder to treat context and tool access as first-class configuration, not an afterthought.
- Ultimate GitHub Copilot CLI tutorial for beginners
- GitHub Copilot CLI for Beginners: Overview of common slash commands
- Introducing Copilot CLI and agentic features in JetBrains IDEs
GitHub-side workflow updates: code review shaping, PR attribution/search, and issue triage via MCP
Copilot code review updates moved into GA improvements: repositories can now add an AGENTS.md file to shape review feedback, and the UI reduces friction when requesting reviews on draft PRs while cutting timeline noise. In parallel, Copilot cloud agent-opened pull requests now show up in author: searches and default PR views (with REST/GraphQL parity rolling out July 16), and generated release notes can credit the developer who requested the agent PR alongside @copilot.
On the issue side, GitHub introduced public preview duplicate issue detection during issue creation, and added MCP support to read/write issue fields so AI tools can create and filter fully triaged issues. Taken together, these changes make it easier to integrate agents into normal team hygiene (triage, review, attribution) without losing accountability or flooding timelines, which lines up with last week's push toward enterprise-grade governance and distribution for agent outputs.
- Copilot code review: AGENTS.md support and UI improvements
- Copilot-authored pull requests now included in author searches
- Generated release notes credit you for Copilot pull requests
- Detecting Duplicate Issues (Public Preview) and issue fields MCP support for GitHub Issues
Model choice, routing, and spend tracking become day-to-day concerns
This week tied together three practical threads: more models and more ways to bring them into your tools, more automation in selecting the “right” model per request, and better reporting so orgs can actually manage cost and policy.
Auto mode in Copilot Chat goes GA for all plans (with token billing incentives)
GitHub made auto model selection generally available for Copilot Chat across all Copilot plans on github.com and GitHub Mobile. Auto routes requests to different models based on task complexity, availability, and policy settings, and paid subscribers get a 10% token-billing discount when using auto mode.
For teams, this pushes model routing from a power-user feature into a default, echoing last week's Foundry story that routing plus evaluation is becoming a baseline operational concern, not an advanced add-on. If you are enforcing model policies in Copilot Enterprise, auto mode becomes another path to validate that the allowed models actually match your compliance and performance requirements.
Token efficiency work lands in VS Code: caching, tool search, and WebSockets
GitHub and the VS Code team detailed how Copilot is getting more token-efficient in agentic sessions, with extended prompt caching and deferred tool definition loading via tool search. They also called out a WebSocket transport path to reduce latency across OpenAI and Anthropic models, plus related notes like Anthropic cache_control behavior.
This matters because agent workflows tend to amplify overhead (planning steps, tool schemas, intermediate reasoning), so small savings can translate into real latency and billing improvements across a fleet. If you're building your own tools or skills, take this as a signal to design for “load on demand” and to treat tool definitions as part of the performance budget, not just a developer convenience.
- Getting more from each token: How Copilot improves context handling and model routing
- Improving token efficiency in GitHub Copilot
- What 50,000 Runs of a 5-Line Eval Taught Us
VS Code BYOK expands model choice (and changes how you operationalize access)
VS Code added bring-your-own-key (BYOK) support for Chat, letting developers configure providers like Azure, OpenAI, Anthropic, and Gemini, plus local models through Ollama and Foundry Local. Configuration lives in the Language Models editor, and the system supports extensions and “utility models” for background tasks.
BYOK changes the rollout story for teams that cannot (or do not want to) standardize on a single assistant subscription, and it is a practical mirror of last week's “open models with enterprise controls” theme where platform choice expands but operational responsibility (keys, quotas, policy, telemetry) shifts back to the team. If you're supporting both Copilot and BYOK paths, plan for differences in model capabilities, pricing, and telemetry when debugging “why did the assistant do that” across your org.
- Use your own language model key in VS Code
- Bring your own key in VS Code
- Bring Your Own AI… No Sign‑In Required!
- Visual Studio Code 1.126
- Visual Studio Code and GitHub Copilot - What's new in 1.125
Copilot model availability changes: MAI-Code-1-Flash expands, Opus 4.6 (fast) deprecates
GitHub expanded availability of MAI-Code-1-Flash (Microsoft's small coding model tuned for Copilot) across more Copilot surfaces, including Copilot CLI, Copilot Chat on GitHub, Visual Studio, and multiple IDEs, with a gradual rollout and Business/Enterprise access “soon.” At the same time, GitHub announced the deprecation of Opus 4.6 (fast) across Copilot experiences on June 29, 2026, recommending Opus 4.8 (fast) as the replacement and noting that Copilot Enterprise admins may need to enable the new model via model policies.
The net effect is that “what model is my team using” is no longer stable by default, which fits the broader operational through-line from last week: once agents become production workflow participants, model lifecycle changes start to look like routine platform maintenance. If you run enterprise Copilot, treat model deprecations like dependency upgrades: validate downstream behaviors (code review tone, refactor safety, test generation) and update policy before the cutoff.
Usage and billing visibility: per-user credits and broader active-user reporting
GitHub added ai_credits_used to the Copilot usage metrics API, enabling per-user AI credit consumption reporting in both 1-day and 28-day user-level reports at org and enterprise scope. Separately, enterprise usage metrics now incorporate server-side telemetry in addition to client-side IDE signals, increasing coverage of active users even if per-IDE/per-feature breakdowns are still empty for newly surfaced users.
If you're doing chargeback, budgeting, or just trying to catch runaway usage, per-user credit reporting is the missing piece for tying cost to adoption, and it complements last week's emphasis on closed-loop operations where measurement and iteration are part of the default stack. The telemetry expansion also means your “active user” counts may jump, so plan to explain the reporting change internally before people interpret it as a sudden surge in Copilot usage.
- AI credits consumed per user now in the Copilot usage metrics API
- Copilot usage metrics now include more of your active users
- Copilot individual plan sign-ups are reopening
MCP everywhere: tool ecosystems mature, and security catches up
MCP continued to solidify as the glue between LLMs and real tools (cloud management, build logs, databases), but the security research this week made the trust boundaries painfully concrete.
Enterprise tool control with APIM as an MCP gateway
Building on last week's “managed MCP” direction (where tool connectivity becomes governable infrastructure, not ad hoc glue), a practical pattern emerged for controlling tool access: using Azure API Management (APIM) as an MCP gateway to selectively expose MCP tools while enforcing authentication, logging, rate limits, and network isolation. The guide contrasts a static allowlist approach with a dynamic deny-list that rewrites tools/list responses, and it calls out trade-offs that show up with streaming.
If you're standardizing on MCP internally, a gateway is the difference between “every agent can call everything” and a policy-driven tool surface that security can live with. The tools/list and tools/call layer is also where you can implement coarse-grained segmentation (prod vs non-prod tools, read-only vs write), which is easier than trying to encode policy into prompts.
ARM MCP Server PoCs: deterministic infra agents built on Resource Graph + deployments
A catalog of 24 proof-of-concept agents built on the Azure Resource Manager MCP Server showed how to combine Azure Resource Graph queries (KQL) with ARM template deployments under a deterministic, repeatable workflow. The write-up details the server's six MCP tools, a “determinism contract,” and scenarios spanning governance and SRE operations.
The key developer takeaway is that infra agents can be more than “chat that runs az”: with deterministic constraints and a fixed toolset, you can build runbooks that are inspectable and repeatable. That matters for production changes, where you need auditability and predictable behavior more than creative output.
Build troubleshooting gets agent-friendly: MSBuild Binlog MCP Server (preview)
The Microsoft Binlog MCP Server (preview) exposes 15 tools for querying MSBuild .binlog files so AI assistants can diagnose failures, trace properties, analyze performance, and compare builds across Visual Studio, VS Code, and CLI environments. It builds on the Structured Log Viewer search DSL, turning a normally manual log-forensics workflow into a tool-callable surface.
This is a strong example of where MCP shines: the model does not need to “understand” MSBuild logs from raw text if it can ask a purpose-built tool for the exact graph node, property value, or timing edge it needs. If you already archive binlogs in CI, you can imagine wiring an agent to triage failures with evidence and links rather than vague speculation.
Security wake-up call: AutoJack RCE chain in AutoGen Studio via localhost MCP WebSocket
Last week, MCP was framed as the scalability unlock for tool connectivity, and this research shows the other side of that coin: Microsoft Defender Security Research published AutoJack, an exploit chain in AutoGen Studio where an AI browsing agent can be steered to open a localhost MCP WebSocket and trigger arbitrary process execution. The write-up explains root causes (localhost trust boundary mistakes, WebSocket exposure patterns), documents upstream hardening, and provides mitigations plus Microsoft Defender hunting queries.
If you're building or deploying agent runtimes, treat this as a reminder that “the agent opened a web page” is untrusted input that can pivot into tool execution if you blur boundaries between browsing and local control planes. The mitigations and hunting queries are directly actionable for defenders, but developers should also revisit defaults: require explicit user confirmation for sensitive tools, bind localhost services safely, and avoid assuming that “local” means “trusted.”
RAG and data grounding patterns: from Azure AI Search to Postgres and OneLake-connected files
Azure AI Search RAG implementation guidance (indexing, hybrid retrieval, embeddings)
Last week's Foundry IQ updates kept pushing “grounding as a managed layer,” and two deep-dive resources this week focused on implementing Retrieval-Augmented Generation (RAG) with Azure AI Search to ground LLM outputs in private and up-to-date data. The guidance emphasizes production building blocks like indexing, semantic search, vector search, embeddings, and hybrid retrieval workflows that balance lexical relevance with semantic similarity.
For developers, the recurring point is that RAG quality depends more on retrieval design than prompt cleverness. If you are fighting hallucinations, start by instrumenting recall/precision at retrieval time (what chunks are coming back, why, and how often), then tune chunking, metadata filters, and hybrid scoring before tweaking the LLM.
- Deep Dive: Implementing Retrieval-Augmented Generation (RAG) with Azure AI Search
- Deep Dive: Implementing Retrieval-Augmented Generation (RAG) with Azure AI Search
Zero-copy file data foundations for RAG: Azure NetApp Files + OneLake shortcuts
A pair of Azure Storage posts outlined a zero-copy, zero-migration pattern that keeps Azure NetApp Files as the system of record while exposing file data to Microsoft OneLake via the Azure NetApp Files Object REST API. The more detailed pipeline version shows indexing “in place” using OneLake shortcuts, chunking and vector retrieval with Azure AI Search, and grounded answer generation with citations using Azure OpenAI (including embeddings).
This matters for enterprises where file shares are the real knowledge base, but migrating them is slow and politically difficult. If you can index and retrieve without moving the data, you can prototype RAG and governance patterns sooner, then decide later whether the storage layer needs to change.
- From Enterprise File Storage to an AI-Ready Data Foundation using Azure NetApp Files and OneLake
- From File Data to AI‑Powered Knowledge Pipelines using Azure NetApp Files object REST API
Postgres for agent retrieval: MCP patterns, safety, and production scaling (POSETTE 2026)
POSETTE 2026 content dug into Postgres-backed agent patterns, including MCP-based interaction, common SQL-generation failure modes, and retrieval approaches that blend relational, vector, and graph techniques. Talks covered practical safety design for Postgres MCP servers (typed tools vs free-form SQL, read-only modes, eliciting user confirmation, and guarding against SQL injection/unintended mutations), plus a production RAG case study using Azure Database for PostgreSQL with pgvector, DiskANN indexing, and Semantic Kernel integration.
For teams adopting RAG on Postgres, the key is to treat “database tools” like any other privileged API: design the tool surface area first, then let the model use it, a direct extension of last week's grounding theme where connectors and access control matter as much as retrieval quality. DiskANN and pgvector show up as the scaling story, but the reliability story still starts with constraining what queries the agent is allowed to run and how you prevent expensive or dangerous operations.
- From Queries to Agents: The Next Era of Data Retrieval on PostgreSQL | POSETTE 2026
- Production RAG at Scale with Azure Database for PostgreSQL | POSETTE: An Event for Postgres 2026
- PostgreSQL Tooling Across AI Editors and Agents | POSETTE: An Event for Postgres 2026
- An MCP for your Postgres DB | POSETTE: An Event for Postgres 2026
- KEYNOTE: Driving Postgres forward at Microsoft | POSETTE: An Event for Postgres 2026
- Trailer for Livestream 1 of POSETTE: An Event for Postgres 2026
Local AI and enterprise agent platforms: Windows expands on-device options, Foundry pushes RL loops
Local AI on Windows for telecom: Windows AI APIs, Foundry Local 1.2.0, and agent governance
Microsoft outlined Build 2026 updates for running AI locally on Windows in telecom scenarios, including Windows AI APIs expanding CPU/GPU support and adding a Speech Recognition API, alongside Foundry Local 1.2.0 and Windows ML. The post also introduced Microsoft Execution Containers (MXC) and Windows 365 for Agents as options for policy-driven containment, identity, and governance for autonomous agents.
The practical implication is clearer separation between “on-device inference for latency/data locality” and “managed agent execution for control,” a continuation of last week's Foundry platform story where identity and governance are treated as part of agent deployment rather than bolt-ons. If you're prototyping local models with Foundry Local, start mapping which workloads must stay on-device (privacy/latency) versus which can run in contained execution environments with stronger auditing.
Outcome-driven learning systems: OpenEnv + Foundry for enterprise RL loops
Microsoft described an outcome-driven learning loop for enterprise agents in Foundry, combining OpenEnv environments, rubric-based evaluation, non-parametric harness optimization, and managed post-training. The post also highlights OpenEnv contributions like an Azure Container Apps (ACA) sandbox provider and the ECHO technique for learning world models from environment tokens.
For developers building agents that must improve over time, this frames a path beyond prompt iteration: define an environment, define success rubrics, and run evaluation and post-training as a managed loop, which connects directly to last week's emphasis on closed-loop optimization (traces, evals, routing, tuning) as the platform default. It also reinforces that sandboxes (like ACA providers) are not optional when agents take actions; they are part of keeping learning and tool use safe and reproducible.
AI security and defense: agentic scanning moves into production, identity defenses go agent-native
MDASH brings multi-model agentic scanning into real security workflows
Microsoft shared how MDASH (a multi-model agentic scanning system) moved from benchmark results into production security workflows, integrating with Microsoft Defender, GitHub Advanced Security, and Azure DevOps. The update describes pipeline improvements driven by CyberGym evaluation, recent CVE discoveries in Windows and identity, and remaining gaps across scan/validate/prove stages.
For AppSec teams, the interesting detail is the operationalization: evaluation harnesses and pipelines matter as much as raw model performance, especially when you need repeatable results and triageable evidence, and it echoes last week's agent-ops theme of making evaluation a first-class loop. If you are experimenting with AI-based scanning, this is a reminder to invest early in evaluation and feedback loops, otherwise improvements will not stick when you move from demos to CI.
Identity and SOC workflows: unified risk scoring and Security Copilot-driven triage
Microsoft outlined how AI is accelerating identity-based attacks and described efforts to unify identity and security signals across Entra and Defender, including a unified identity risk score, updated Entra ID Protection views, and least-privilege response roles. The same direction includes agent-based recommendations (Conditional Access Optimization Agent) and identity-focused extensions to the Security Alert Triage Agent, with attack disruption and predictive shielding themes.
This is less about new SDKs and more about what your security platform may start doing by default: surfacing recommendations and taking constrained actions based on cross-product signals, aligning with last week's distribution/governance framing where identity-backed endpoints and centralized control planes become the enabling layer. Developers supporting enterprise IT should expect increased demand for auditable automation (who/what changed Conditional Access and why), and for integrations that preserve least privilege when agents participate in response workflows.
- AI is accelerating cyberattacks—here’s how to stay ahead
- Forrester names Microsoft a Leader in the 2026 Extended Detection and Response Platforms Wave report
- Microsoft Defender email security benchmarking: Key insights from one year of data
GitHub and Azure migration/modernization: agents move up to portfolio-level planning
Azure Migrate integrates Copilot Modernize CLI (preview) for at-scale code insights
A new public preview integration lets Azure Migrate surface at-scale code insights generated by the GitHub Copilot Modernize CLI, aiming at portfolio-level assessment and remediation guidance across multiple apps and repos. The related Azure Update recap reinforced that this is part of a broader Azure Migrate story this week, positioned alongside other platform changes.
If you're modernizing a fleet, the interesting angle is centralizing agent output where migration decisions happen (Azure Migrate) instead of leaving it scattered across local CLI runs, a continuation of last week's theme of moving agents closer to where work happens (and where governance can be applied). The preview framing suggests you should validate the outputs as “recommendations” and build a workflow for sampling and verification before you treat them as a source of truth.
- Generate at scale code insights in Azure Migrate using GitHub Copilot Modernize CLI (preview)
- Azure Update 19th June 2026
Storage migration guidance: choosing between Migrate, Copilot agents, Storage Mover, and Data Box
Azure published a phased approach to Azure Storage migrations, including how to choose between Azure Migrate, the Azure Copilot Migration Agent (preview), Azure Storage Mover for online sync, and Azure Data Box for offline bulk transfers, with an example path like AWS S3 to Azure Blob Storage. This is less “AI feature news” and more a pragmatic map of where agent assistance fits (planning and guided execution) versus where traditional transfer tooling still does the heavy lifting.
For teams juggling multiple data movement constraints (downtime, bandwidth, compliance), the key is sequencing: assess and plan first, pick an online/offline movement method, then use agent help where it reduces coordination overhead rather than trying to replace transfer tools.
Other Artificial Intelligence News
GitHub continued tightening enterprise controls and product boundaries as Copilot expands, while Microsoft highlighted both infrastructure scale and more “agent-ready” developer building blocks.
GitHub added an enterprise-managed setting (disableBypassPermissionsMode) to prevent Copilot CLI and VS Code from auto-approving or skipping permission prompts (with VS Code v1.122+ respecting the policy), and it launched an agent finder implementing the Agentic Resource Discovery (ARD) spec to discover/rank agent capabilities from registries under managed policies. GitHub also began retiring GitHub Models for new customers, pointing new projects to Azure AI Foundry, which tracks with last week's emphasis on Foundry as the end-to-end platform layer for building and operating agents.
- Enterprise-managed settings now support bypass permission controls
- Agent finder for GitHub Copilot now available
- GitHub Models is no longer available to new customers
Teams building agent stacks got more advice on evaluation and “agent experience” (AX): how GitHub built an internal analytics agent (Qubot) using an MCP-based query engine for Kusto and Trino plus an offline evaluation framework, and how to avoid extension/skill bloat and conflicts that waste context and reduce net lift. A separate guide showed a cloud-native skill-eval harness on Foundry Hosted Agents that runs the same test cases across models with deterministic validation and structured scoring, extending last week's “operations loop” narrative from platform features into day-to-day engineering practices.
- How we built an internal data analytics agent
- Stop overloading your skills
- When your agent extensions fight each other
- Agents That Test Agents: A Cloud-Native Skill-Eval Harness on Foundry Hosted Agents
Microsoft pushed more agent touchpoints into everyday dev tools, including Copilot Agent mode (preview) inside SQL Server Management Studio (SSMS) with explicit read-only vs read/write guidance, and ongoing work like dotnet/skills to help assistants generate more idiomatic .NET. On the platform side, Azure highlighted an MLPerf Training v6.0 result for Llama 3.1 405B (just over seven minutes on an 8,192 GPU GB200 NVL72 cluster) and separate messaging about extreme-scale training performance.
- Introducing Agent mode in SQL Server Management Studio (SSMS) | Data Exposed
- ASP.NET Community Standup: Better AI for .NET developers with dotnet/skills
- Azure Sets a New Performance Record for LLM Training Benchmark at Extreme Scale
- Azure sets a new performance record for LLM training benchmark at extreme scale
Developers building document and data pipelines got more reference architectures and integrations: a hybrid document extraction pattern using Azure Content Understanding plus bounded Azure OpenAI verification and confidence-based routing, and a real-time weather pipeline in Fabric Eventstream/Eventhouse using AI Skills and automated deployment via Fabric REST APIs. Fabric and Azure Databricks interoperability also advanced with OneLake positioning, including OneLake catalog federation and governance themes, plus previews like a ServiceNow connector for zero-copy querying via OneLake Table APIs (Iceberg REST Catalog compatible) and an open-source Fabric Spark Operations Skill for diagnostics.
- Revolutionizing Document Intelligence: Scaling Construction Industries with AI-Driven Extraction
- Monitoring weather conditions in real-time using AI and Fabric Eventstream
- Unlocking Microsoft OneLake as the data foundation for Azure Databricks customers
- Azure Databricks at Databricks Data + AI Summit 2026: updates and new announcements
- ServiceNow Zero-Copy Querying of Enterprise Data in Microsoft OneLake (Preview)
- Simplify Spark failure diagnosis in Fabric (Preview)
A few more community and product notes rounded out the week: GitHub Code Quality is scheduled to become generally available as a paid product on July 20, 2026 with per-committer pricing plus metered AI usage and Actions minutes for deterministic CodeQL analysis, and there were additional practical resources around modernization and agent middleware in .NET. The roundup content also included lighter agent demos and ideation lists, useful if you're looking for weekend prototypes rather than platform changes.
- GitHub Code Quality generally available July 20, 2026
- .NET 11 Preview 5 is now available!
- On .NET Live - Demystifying Microsoft Agent Framework Middleware
- Master AI Agent Framework Middleware in just 30 minutes!
- Modernize Java apps with AI | OD871
- Modernize .NET Apps with GitHub Copilot
- Modernize .NET Apps and Add Agentic Functionality in Minutes
- 25 Copilot Studio Agent Ideas You Can Build This Weekend