Microsoft Graph on DR.365

Built for human pace: what Anthropic's source control rewrite means for enterprise IT strategy

Wed, 14 Oct 2026 07:00:00 +0200

In May 2026, Anthropic merged about 2,500 code changes per day into its monorepo. By September it was more than 30,000. Git and the mirror infrastructure around it could not keep up, so a team of seven built its own version control system and moved the entire monorepo onto it in five months (Anthropic Engineering).

Almost nobody reading this will build a version control system. That isn’t the point of the story. Every organization runs processes that were sized for the speed of people: change advisory boards, four-eyes approvals, access reviews, CI pipelines, budgets calculated in person-days. Once agents do a large share of the work, those processes become the bottleneck, and the question is which of them you redesign before they break.

TL;DR

Agents are becoming the main consumers of your systems. Architecture decisions should assume machine clients that are always online and call APIs at high volume.
Review and approval have to move from “a human looked at everything” to rules that decide where a human must look.
Every agent needs an identity, an accountable person and a cost center. Without those three you can neither govern nor budget agent work.

What Anthropic actually changed

The headlines say “Anthropic threw out Git”. The engineering post is more careful. The new system is called Scion, the review tool Antique. Anthropic explicitly says Scion is not a general replacement for git, because that would mean replacing the whole development toolchain. They published the design so that git platforms can adopt parts of it.

The numbers explain why they did it anyway. The main branch history is almost 100 GB, a compressed working copy more than 25 GB, and CI runs roughly 25 million checkouts per day. Git is designed for distributed clients that work offline. Anthropic’s clients are almost entirely agents and jobs that are always online. Scion moves the expensive work to the server: commits, merges, rebases, history and blame happen there, clients get sparse, virtualized checkouts that load files on demand, and much of the functionality is available through an API without any local repository. According to the post, the new infrastructure uses about 200 times less CPU and memory than the old git mirrors, and CI checkouts take seconds instead of minutes.

Three decisions in the post matter beyond source control:

There is no merge queue with a global lock. Anthropic invested in post-merge and pre-deploy testing instead. Conflicts between concurrent changes happen, and Claude usually fixes them faster than a human would notice them.
Antique can express semantic rules for approvals. A comment-only change gets treated differently from a change to sensitive logic, so human reviewers spend their time where it counts.
Access control at repository and directory level was built in from the start, not added later.

Agents are the new primary client

The first lesson is about architecture. Most enterprise systems assume a person in front of a screen. Agents behave differently: they poll, they run in parallel, and they don’t take lunch breaks.

In Microsoft 365 you can see this today in Microsoft Graph throttling. Microsoft lists two typical causes: many requests across all applications in a tenant, and many requests from one application across tenants. Polling a resource and repeatedly scanning collections are named as patterns that lead to throttling. The recommended alternatives are delta queries and change notifications, and for bulk extraction Microsoft points to Graph Data Connect instead of the REST APIs (Microsoft Learn). SharePoint Online goes one step further: an application that keeps exceeding limits can be blocked entirely (Microsoft Learn).

That guidance was written for integration developers. It now applies to every agent that reads mailboxes, sites or Teams channels on someone’s behalf. When I evaluate an agent scenario, I now ask how it detects changes before I ask what it does. An agent that rescans a document library every ten minutes works fine in the pilot and becomes a problem when 40 departments copy it.

For your own systems the same principle applies in the other direction. If agents are going to be the main consumers of an internal platform, give it a proper API, change feeds and per-client limits. A web UI with a scraping agent in front of it is the git mirror of your organization: it works until the volume grows tenfold.

Review by intent instead of line by line

The second lesson concerns control processes. The Anthropic team still reviews every change, but they review the intent, not every line. Their main job, as they describe it, is telling Claude “no”: when it violates system constraints, or when it over-engineers in response to hypothetical concerns.

In regulated environments this is the uncomfortable part. Many change processes implicitly promise that a qualified person checked everything. At 30,000 changes per day that promise can’t be kept, and honestly it often wasn’t kept at 30 per week either. The CAB that approves a stack of changes in 45 minutes is mostly checking that the form is complete.

In my experience, auditors want evidence that changes are controlled and traceable. NIS2 asks for risk management measures that include security in development and maintenance; it does not prescribe that a human reads every line. That leaves room for a model that ITIL already knows as standard changes, applied to agent output:

Low risk (documentation, tests, formatting, configuration within defined guardrails): automated checks, no mandatory human review, full logging.
Medium risk (business logic, integrations): human review of intent and test evidence, with the agent’s summary as input.
High risk (authentication, permissions, data flows across trust boundaries, anything regulated): line-level review by a named person, the way it has always been.

What decides the tier has to be a rule, not a gut feeling. Anthropic models this in the review tool, and you can model it in branch protection rules, CODEOWNERS files or a Power Automate approval flow. The rule itself is the control that an auditor will want to see.

I would be careful with one part of the Anthropic approach: moving checks after the merge. For an internal developer platform that is a reasonable trade. For a system in a KRITIS environment where a faulty change can reach production directly, I wouldn’t do it. The safeguard has to sit before deployment, even if it no longer sits before the merge.

Every agent needs an identity and an owner

Anthropic built access control into Scion from day one, down to the directory level. In Microsoft 365 the equivalent is the identity layer for agents. Microsoft Entra Agent ID gives agents their own identities in the directory, created from agent identity blueprints. Every agent identity requires a human sponsor who is accountable for purpose, lifecycle and access reviews. If the sponsor leaves, sponsorship transfers to their manager. Conditional Access and access packages from entitlement management apply to agents as well (Microsoft Learn). As of October 2026, identity governance for agents is labeled preview, and the licensing depends on Microsoft 365 E7 or Agent 365 licenses; check the current terms before you plan with it.

On top of that, Microsoft Agent 365 provides the registry as one inventory of Microsoft and non-Microsoft agents, including counts of agents without owners (Microsoft Learn). I described the governance side in more detail in the post on the agent lifecycle.

The strategic point: an agent that runs under a shared service account or a person’s delegated credentials cannot be distinguished in the audit log, cannot be throttled separately and cannot be billed separately. Fixing that later for hundreds of agents is the kind of project nobody wants to fund.

Measuring agent work

The budget side breaks in the same way. Controlling in most IT organizations still calculates in person-days, and that model has no line for agent work. A practical way to close the gap is to route agent sessions through an AI gateway, so that every token and every hour of runtime can be assigned to a project and a repository and priced at real cost.

A feature that needed 20 days last year and 3 days of review plus agent runtime this year doesn’t fit that model. Counting agent hours is a start, but hours are an input metric. What you want to know is the cost per accepted change: tokens and runtime plus the human time for review, rework and the cases where someone had to say “no”. Without the human share, agent work looks cheaper than it is.

For Microsoft agents, Agent 365 observability collects activity data and is meant to support business metrics like usage and time savings (Microsoft Learn). That covers part of the picture. Coding agents outside Microsoft 365 need their own attribution, and that is where the gateway approach comes in.

Decisions for the next twelve months

Anthropic expects other organizations to run into this class of problem within the next six to twelve months. Even if your timeline is longer, these are the decisions I would make now:

Inventory human-paced controls. List every approval, review and pipeline step that assumes a person and a working day. Mark which ones would break at ten times the volume.
Introduce risk tiers for changes. Write down which changes need a human, which need a human for intent only and which need logging only. Make the rule machine-readable.
Give agents their own identities. No shared service accounts, every agent with a sponsor, permissions through access packages with an expiry date.
Design integrations for machine clients. Delta queries, change notifications and API budgets instead of polling and scraping.
Attribute agent cost. Tokens and runtime per project, plus the human review time, from the first productive agent onward.

What I wouldn’t do is copy Anthropic’s tooling. Their problem was 25 million checkouts a day. Yours is more likely a change process that takes two weeks for a configuration change an agent prepared in ten minutes. That is the place to start.

References

Anthropic Engineering: Redesigning source control at Anthropic (October 13, 2026)
Microsoft Learn: Microsoft Graph throttling guidance
Microsoft Learn: Avoid getting throttled or blocked in SharePoint Online
Microsoft Learn: Governing agent identities
Microsoft Learn: Manage agent registry in Microsoft 365 admin center
Microsoft Learn: Agent 365 observability
EUR-Lex: Directive (EU) 2022/2555 (NIS2), Article 21

PowerShell or Microsoft Graph? Choosing the Right Interface and Fixing Module Conflicts

Sun, 11 Oct 2026 07:00:00 +0200

“Should I do this with PowerShell or with Graph?” breaks down into two questions: which interface actually exposes what I need, and how will this thing run in six months when nobody is watching it. If you’ve ever mixed the Graph PowerShell SDK with PnP.PowerShell or the Exchange Online module in one script, you know the third question, the one nobody asks until it bites: will these modules even load together?

TL;DR

Use Exchange Online PowerShell for Exchange administration (mailbox permissions, transport rules, org config). Graph doesn’t cover most of it.

Use Microsoft Graph for identity, cross-service data and anything an application does: integrations, mail sending, reporting. For application access to mailboxes, Graph is the interface to build on.

The classic trap when combining them: assembly conflicts (Microsoft.Identity.Client, Microsoft.Graph.Core, Azure.Core …) between Microsoft.Graph, PnP.PowerShell, ExchangeOnlineManagement and Az. Connection order is a lottery; process isolation and fewer modules are the real fix.

What you’re actually choosing between

The Microsoft Graph PowerShell SDK is PowerShell, and it calls Graph under the hood. So the choice is between two kinds of interface:

Service-specific admin modules: ExchangeOnlineManagement, MicrosoftTeams, PnP.PowerShell for SharePoint. They talk to the admin surfaces of a workload and expose things that simply don’t exist in Graph.
Microsoft Graph: one REST API for Entra ID, mail, calendars, files, Teams, Planner and much more, callable from anything: the Graph PowerShell SDK, Invoke-RestMethod, C#, Python, Logic Apps or a ticketing system.

Which one to use depends first on which surface has the capability at all.

Where each one wins

Task	My pick	Why
Full Access / Send As permissions, transport rules, org-wide Exchange settings	Exchange Online PowerShell	Graph has no endpoints for these. The new Exchange Online Admin API (preview) only covers a small subset like folder permissions and Send on Behalf.
Users, groups, licences, app registrations in Entra ID	Graph (SDK or REST)	This is Graph’s home turf.
An application sends or reads mail (ticketing, workflows)	Graph	`sendMail` / message endpoints with OAuth, scoped via RBAC for Applications.
Site provisioning, templates, SharePoint permissions	PnP.PowerShell	Far richer than Graph’s SharePoint surface for admin tasks.
Teams policies (meeting, calling, messaging)	MicrosoftTeams module	Policy management lives in the Teams admin surface, not in Graph.
Cross-service reporting (users + licences + sign-ins + groups)	Graph	One API, one auth model, paging and `$select` built in.

My rule of thumb: if a person runs it, use the module that’s closest to the workload. If an application runs it, use Graph – and give that application exactly the permissions it needs, nothing more.

A practical example: mail integrations

The LinkedIn post that inspired this article describes modernising a ServiceNow mail integration so that it sends and receives mail through Microsoft Graph. Here an application, not a person, works with mailboxes, and that’s where Graph fits: OAuth, granular permissions and a clean audit trail. Sending a message is a single call:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Microsoft Graph v1.0 – send mail as the service mailbox (app-only)
# Required application permission: Mail.Send (scoped via RBAC for Applications, see below)
$message = @{
 message = @{
 subject = 'Ticket INC0012345 updated'
 body = @{ contentType = 'Text'; content = 'Your ticket has been updated.' }
 toRecipients = @(@{ emailAddress = @{ address = 'adele.vance@contoso.com' } })
 }
 saveToSentItems = $true
}

Invoke-MgGraphRequest -Method POST `
 -Uri 'https://graph.microsoft.com/v1.0/users/servicedesk@contoso.com/sendMail' `
 -Body ($message | ConvertTo-Json -Depth 10) -ContentType 'application/json'

What I’d add from a regulated-environment perspective: an app with the application permission Mail.Send can, by default, send as any mailbox in the tenant. That’s not something you want to explain to an auditor. Use RBAC for Applications in Exchange Online to scope the service principal to the mailboxes it actually needs:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Exchange Online PowerShell – scope a ticketing app to its service mailboxes only
# Prerequisite: the Entra app has NO tenant-wide Mail.Send consent (otherwise permissions add up)
# IDs from "Enterprise applications" in Entra, not from "App registrations"
New-ServicePrincipal -AppId '<app-id>' -ObjectId '<service-principal-object-id>' -DisplayName 'Ticketing'

New-ManagementScope -Name 'Ticketing-Mailboxes' `
 -RecipientRestrictionFilter "CustomAttribute10 -eq 'Ticketing'"

New-ManagementRoleAssignment -App '<service-principal-object-id>' `
 -Role 'Application Mail.Send' `
 -CustomResourceScope 'Ticketing-Mailboxes'

# Verify before you go live
Test-ServicePrincipalAuthorization -Identity '<service-principal-object-id>' -Resource 'servicedesk@contoso.com'

Note the irony: you configure Graph permissions with Exchange PowerShell. That’s exactly what the original post means by “use both”.

Module conflicts between Graph, PnP and EXO

Say you write a perfectly reasonable script: Graph for user data, PnP for SharePoint, EXO for mailboxes. It works on your machine. Then it fails in the next session with something like:

1
2


Could not load type 'Microsoft.Identity.Client.BaseAbstractApplicationBuilder`1'
from assembly 'Microsoft.Identity.Client, Version=4.50.0.0'

1

Method not found: '!0 Microsoft.Identity.Client.BaseAbstractApplicationBuilder`1.WithLogging(...)'

Why it happens

Every one of these modules is a binary module that ships its own copies of shared .NET libraries – most notably MSAL (Microsoft.Identity.Client.dll), but also Azure.Core, Azure.Identity, Microsoft.Graph.Core or System.Text.Json. PowerShell loads assemblies into one shared context per process, and only one version of an assembly with a given name can be loaded there. Whichever module loads it first wins; the other module then runs against a version it was never built for.

Microsoft’s own PowerShell documentation describes exactly this: the outcome depends on which module was loaded first, which code path ran, and whether the dependency is loaded at import or only on first use. That’s why the same script works, fails, and works again depending on what you did earlier in the session.

Known combinations that have caused trouble:

PnP.PowerShell + Microsoft.Graph: older PnP builds bundled an outdated Microsoft.Graph.Core (1.25.x) and older MSAL versions, which broke Connect-MgGraph and Invoke-MgGraphRequest once PnP was loaded.
ExchangeOnlineManagement + Microsoft.Graph: a long-running story. EXO 3.5.1 introduced a System.Text.Json clash; in June 2026 Tony Redmond reported that with Graph SDK 2.38 and EXO 3.10, neither connection order worked reliably in PowerShell 7: one order fails with the Method not found error above, the other with a NullReferenceException while acquiring a token.
Az.Accounts + Microsoft.Graph: same pattern with Azure.Core / Azure.Identity.

How to recognise it

First check: what is actually loaded in the current session?

1
2
3
4
5
6
7
8


# Which version of the usual suspects is loaded in this session – and from which module folder?
$suspects = 'Microsoft.Identity.Client', 'Microsoft.Graph.Core', 'Azure.Core', 'Azure.Identity', 'System.Text.Json'

[System.AppDomain]::CurrentDomain.GetAssemblies() |
 Where-Object { $_.GetName().Name -in $suspects } |
 Select-Object @{ n = 'Assembly'; e = { $_.GetName().Name } },
 @{ n = 'Version'; e = { $_.GetName().Version } },
 Location

If Location points into the PnP folder while you’re calling Connect-MgGraph, you’ve found your culprit.

Second check: which versions do your installed modules ship? This inventory makes conflicts visible before they hit production:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


$modules = 'Microsoft.Graph.Authentication', 'PnP.PowerShell', 'ExchangeOnlineManagement', 'Az.Accounts', 'MicrosoftTeams'
$dlls = 'Microsoft.Identity.Client.dll', 'Microsoft.Graph.Core.dll', 'Azure.Core.dll', 'Azure.Identity.dll'

Get-Module -ListAvailable -Name $modules | ForEach-Object {
 $module = $_
 Get-ChildItem -Path $module.ModuleBase -Recurse -Include $dlls -File -ErrorAction SilentlyContinue |
 ForEach-Object {
 [pscustomobject]@{
 Assembly = $_.BaseName
 Version = [System.Reflection.AssemblyName]::GetAssemblyName($_.FullName).Version
 Module = "$($module.Name) $($module.Version)"
 Path = $_.FullName
 }
 }
} | Sort-Object Assembly, Version | Format-Table Assembly, Version, Module -AutoSize

Some modules ship separate builds for .NET Framework and .NET, so you may see two entries per module. What matters is when the same assembly shows up with different versions across modules.

How to solve it

In order of preference:

1. Don’t load what you don’t need. If PnP.PowerShell is already connected, you often don’t need the Graph SDK at all. Invoke-PnPGraphMethod calls Graph with PnP’s connection (provided your PnP app registration has the required Graph permissions). And if you do need the SDK, install Microsoft.Graph.Authentication plus the one or two submodules you use (or just Invoke-MgGraphRequest) instead of the full Microsoft.Graph meta-module.

2. Isolate per process. Assemblies are per process, so separate processes can’t conflict. In PowerShell 7, Start-Job runs in a child process:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Graph work in its own process – app-only auth with a certificate
# Required application permission: User.Read.All
$auth = @{ ClientId = '<app-id>'; TenantId = 'contoso.onmicrosoft.com'; Thumbprint = '<cert-thumbprint>' }

$users = Start-Job -ArgumentList $auth -ScriptBlock {
 param($a)
 Connect-MgGraph -ClientId $a.ClientId -TenantId $a.TenantId -CertificateThumbprint $a.Thumbprint -NoWelcome
 Get-MgUser -Filter 'accountEnabled eq true' -All -Property id, userPrincipalName, department |
 Select-Object Id, UserPrincipalName, Department
} | Receive-Job -Wait -AutoRemoveJob

# Main session: PnP only – Graph's assemblies were never loaded here
Connect-PnPOnline -Url 'https://contoso.sharepoint.com/sites/hr' `
 -ClientId $auth.ClientId -Tenant $auth.TenantId -Thumbprint $auth.Thumbprint

The job returns deserialised objects (properties yes, methods no), which is exactly what you want for passing data between steps. Important: Start-ThreadJob and ForEach-Object -Parallel do not isolate. They run in the same process and share the loaded assemblies.

3. Split runbooks and pipelines. In Azure Automation, use separate runtime environments (PowerShell 7.4) per module set rather than one “everything” environment. In CI/CD, one job per workload. This also gives you cleaner permissions per identity, which helps with least privilege.

4. Pin versions deliberately. #Requires -Modules @{ ModuleName = 'ExchangeOnlineManagement'; RequiredVersion = '<tested-version>' } at the top of a script turns “it broke after an update” into “it refused to start”, which is a much better failure mode. Update modules on purpose, after a smoke test that imports and connects every module combination you use.

5. Last resort: connection order and DLL swapping. Connecting in a particular order, or copying a newer Microsoft.Identity.Client.dll into another module’s folder, is circulated widely in the community. It can get you through a day, but it’s unsupported, it’s overwritten by the next Update-Module, and, as the 2026 EXO/Graph case shows, it stops working without warning. I wouldn’t build production automation on it.

Other pitfalls

Windows PowerShell 5.1 and PowerShell 7 behave differently. Assembly loading differs between .NET Framework and .NET, so a combination that fails in 7 can work in 5.1 and vice versa. PnP.PowerShell 3.x requires PowerShell 7.4 or later anyway, so “just use 5.1” isn’t an option for SharePoint.
-DisableWAM is not a fix. Since EXO 3.7.0, Web Account Manager is the default broker for interactive sign-in. Disabling it with Connect-ExchangeOnline -DisableWAM sometimes sidesteps conflicts, but Microsoft explicitly describes it as a temporary measure.
App-only beats interactive for automation. Certificate-based auth avoids most WAM/broker issues and is what scheduled automation should use anyway.
Permissions add up. With RBAC for Applications, Entra consent and Exchange role assignments are additive. A tenant-wide Mail.Send consent in Entra ID silently defeats your scoped assignment.
The Exchange Online Admin API is preview and deliberately narrow. It complements EXO PowerShell; it doesn’t replace it.

Wrap-up

Admin modules give you the depth of each workload; Graph gives applications a single, auditable way in, which makes it the natural home for every mailbox integration. When you combine modules, treat them like components with dependencies: load less, isolate per process, pin versions and test updates before your runbooks do it for you.

References

Inspired by a LinkedIn post by Anthony Samuel.