Microsoft AI Updates: November 7, 2026

1. GitHub’s Rubicon Git Storage Handles 7,200 Pushes per Second From 5,000 Concurrent Agents on One Repository

GitHub published the third part of its agent-scale Git storage series on November 5, describing the architecture announced at GitHub Universe, internally called Project Rubicon. In internal testing it supported 5,000 concurrent agents on a single repository sending 7,200 pushes per second while serving reads at consistently low latency; today the busiest repositories see at most dozens of writes per second in short bursts, and GitHub set a target of at least two orders of magnitude more. The design rests on the observation that only reference updates need agreement: virtual replicas (disposable compute whose local disk is a rebuildable cache) index each incoming pack, upload it to Azure Blob Storage, then commit one transaction to Ref-CAS, a replicated log service in which each reference update is a quorum-committed compare-and-swap that locks only the references it touches. GitHub rejected two Blob-only designs: a single write-ahead-log blob capped writes in the mid-hundreds per second, and sharding references across segment blobs forced every read to check every segment. Reads start with a version check against Ref-CAS’s log sequence number, so an unchanged repository costs one comparison, and separate compaction nodes take leases on hash-based shards to merge packs in the background, keeping the pack count flat as pushes climb; Ref-CAS alone handles reference state at tens of thousands of operations per second. The architecture is in limited private preview with a broader rollout early next year, and GitHub lists clone-free file reads, an atomic multi-file commit API and event streams for agents as follow-ups. Source

2. Copilot Code Review Settings Move Into the REST and GraphQL APIs, and Balanced Reviews Now Use Three Reviewer Models

GitHub made Copilot code review settings manageable through the REST and GraphQL APIs on November 6, from enterprise policy down to individual repositories, on the Copilot Pro, Pro+, Max, Business and Enterprise plans. Enterprise administrators can enable or disable code review for all organizations or delegate the choice; organization administrators can set enablement, the default review effort and the runner configuration; repository administrators can set review effort and whether reviews use custom instructions and MCP tools. Responses now carry explicit attribution fields for Copilot’s reviews and comments, the review effort used, and the skills, MCP servers and custom instructions Copilot reported as sources for a comment; the enterprise and organization endpoints do not accept GitHub Apps or fine-grained personal access tokens, while the repository endpoints do with Administration read or write permission. Balanced-effort reviews now run three reviewer models with another model combining their findings, agent sessions show the AI credits a review consumed, failed or timed-out reviews retry once and can switch to another eligible model, and the automatic review repository rule now honors its bypass list. The review overview comment is also more compact, grouping skipped and content-excluded files under one “Files not reviewed” section. Source

3. @GitHub in Slack and Teams Reaches General Availability, With a Canvas in Teams for Reviewing Plans and Code

GitHub made @GitHub in Slack and Microsoft Teams generally available on November 6, letting users investigate bugs, create issues, implement changes and open pull requests from a conversation. In Teams, a new Canvas shows implementation plans, code changes and previews beside the conversation so teammates can review and refine the work without leaving the chat. @GitHub now infers the repository from the message and starts the coding session without asking for it again, onboarding is shorter for users who are not signed in, have no default repository or need app access, and issues and pull requests it creates now note in their description which Slack or Teams user started them. GitHub also fixed an issue that could stop responses to follow-up messages. Source

4. GitHub Copilot App Keeps Agent Merge Armed While Checks Run and Adds Personal Rules for Assisted Approvals

GitHub’s weekly Copilot roundup on November 6 listed new GitHub Copilot app features: Agent Merge can be set up directly from a pull request and now stays enabled while required checks or rules are pending, so Copilot merges when the pull request is ready, and users can check reviewer status, request more reviews and quote selected comment text into a discussion with Copilot. Opt-in personal instructions for assisted approval tell Copilot which tool requests it may approve without asking, and apply to local sessions. When a conversation reaches its context limit, the error now offers to compact it or show what is using the space, and dropping files on “New” starts a session, with CSV and TSV files opening as tables. In Copilot CLI, /settings now opens one searchable dashboard for plugins, MCP servers and other settings. Source

5. Copilot Impact Dashboard Counts Copilot Chat and the VS Code Agents Window, and Renames “Passive Users”

GitHub added Copilot Chat and the VS Code Agents window to the Agent adoption chart in the Copilot impact dashboard on November 6, bringing it to nine tracked Copilot experiences, and added chat and vscode_agent entries to copilot_feature_engagement.totals_by_feature in enterprise and organization 28-day usage metrics reports. The cohort formerly labeled “Passive users” is now “Chat-first users”: people active in Copilot who did not use a qualifying feature on at least two days in the 28-day period. Chat and Agents window use count as feature engagement but not toward adoption phases, so cohort sizes do not change, and chat includes agent mode, so users who make agent edits are also counted under chat. Reports for periods before the change include only the original seven features. Source

6. GitHub Copilot’s Upgrade Agent Adds a .NET Migration Path From Windows x64 to Windows Arm64

Microsoft added a Windows Arm64 migration scenario to the GitHub Copilot upgrade agent for .NET on November 5. The agent assesses .NET projects moving from Windows x64 or x86, flagging architecture-specific code and build settings, native dependencies without Arm64 binaries, packages that need compatible versions and configuration that targets only x64 or x86, then writes a migration plan and updates code, dependencies and project settings, pausing when a step needs developer input. It builds the migrated components for Windows Arm64 and, when matching hardware or CI runners are available, runs tests to check runtime behavior. Microsoft says the scenario covers portability and correctness, not Arm64-specific performance tuning, and that a successful build still needs validation on Arm64 hardware. Developers pick the upgrade agent in the agent picker and select the .NET Arm64 migration scenario. Source