The Microsoft 365 outage and your AI agent: what the record should say about 12 November

On Thursday 12 November 2026, from 11:17 a.m. Eastern, Microsoft’s Exchange Online stopped answering reliably. By the evening Microsoft had listed Teams, SharePoint, Microsoft 365 Copilot and Microsoft Graph among the affected services, and the next morning it had still not called the incident fixed. Graph is the door most agents use into Microsoft 365: to send an email, book a meeting, read an inbox or post in a channel. For most of a day those calls came back slow, came back with an error, or did not come back at all.

After a vendor fails, the question an auditor or a customer asks is not whether it was down. It is what your agent did while it was. This note is about the one outcome most agent records cannot express, and two numbers we measured about who was exposed.

Who was exposed: two numbers we measured

Teams that build agents mostly did not feel this outage in their own inbox. We looked up the public mail records of 209 organisations whose AI agents take actions (payments, ad changes, bookings, messages, record updates). 139 of them, 66.5%, receive their email on Google Workspace. 4, under 2%, are on Microsoft 365.

The businesses agents work for look different. In a separate census of 2,020 US local businesses that advertise online, across 19 sectors from dentists and law firms to heating and cooling, 717, or 35.5%, point their email straight at Microsoft 365, and 127 more most likely reach it through a spam filter: 844, or 41.8%, in all. Counting those, law firms were at 51% and senior living at 62%.

Put together, the agent’s own team stayed online while a large share of the inboxes and calendars its agent works on were failing. The outage did not show up on the team’s screens as an outage. It showed up in the agent’s tool calls, and it is in the tool calls that the record has to explain it.

The outcome most records cannot express

A tool call made during an outage ends in one of four ways, and each needs different handling:

1. Done, and confirmed. The service answered with its own id for the message or the event. Record that id; it is your proof.
2. Not done, and the service said so. An error that means the request was rejected. Safe to try again later.
3. Never sent. The connection failed before the request reached the service. Also safe to try again.
4. Unknown. The request was sent and the answer never came back.

The fourth is the dangerous one, and 12 November produced a lot of it. Microsoft described part of its infrastructure as under elevated load, with servers becoming unexpectedly unavailable. On a server in that state, a request can be carried out and still lose its reply on the way back. Retry it, and a customer may get the same email twice. Mark it failed, and it may have gone out with nothing on your record saying so. The only honest entry is unknown: sent at this time, to this service, followed later by a second entry that says what actually happened.

Most agent records have two outcomes, success and error. A timeout lands in error, and from there it gets retried.

What the entry should hold

A check to run this morning

1. Select every agent action that targeted Microsoft 365 (Graph, Outlook, Teams, SharePoint) from 16:17 UTC on 12 November until Microsoft declares recovery.
2. Group them by outcome. Count the timeouts, and anything recorded as an error after a long wait.
3. For each of those, look at the service itself: Sent Items for mail, the calendar for meetings, the channel for posts. Was it done once, twice, or not at all?
4. Write down what you found as new entries beside the originals. Only then retry, and only the actions you have confirmed were never done.

In SQL, against whatever table your agent writes its actions to:

-- every agent action that touched Microsoft 365 during the outage
select outcome, count(*)
from agent_actions
where target_service in ('graph', 'outlook', 'teams', 'sharepoint')
  and requested_at >= '2026-11-12 16:17:00+00'
  and requested_at <  :microsoft_recovery_time
group by outcome;

-- the ones to reconcile by hand, before anything is retried:
-- timeouts, unknowns, and errors that came back only after a long wait
select action_id, tool, target, idempotency_key, attempts, requested_at, wait_ms
from agent_actions
where target_service in ('graph', 'outlook', 'teams', 'sharepoint')
  and requested_at >= '2026-11-12 16:17:00+00'
  and requested_at <  :microsoft_recovery_time
  and (outcome in ('timeout', 'unknown')
       or (outcome = 'error' and wait_ms >= :your_client_timeout_ms));

Three things not to do

• Retry every failure at once. Some of them were carried out. A bulk retry sends duplicates to customers.
• Edit the original entries. Change “timeout” to “sent” and the record no longer shows what the agent knew at the time, which is exactly what an auditor will ask about.
• Use the vendor’s status page as your record. It says a service was degraded in some regions. It cannot say which of your actions were affected.

How we measured

The 209 organisations were collected on 11 November 2026 from the Y Combinator company directory and the official MCP server registry, each one a company whose agent takes an action in the world rather than only answering. The 2,020 businesses come from a census of 6,613 US business websites listed on OpenStreetMap in 33 metro areas; the sites were read on 10 and 11 November, and a business counted as advertising when its pages carried a Google Ads tag or a Meta pixel.

On 13 November we read two public DNS records for every domain: MX, which names the server that receives its email, and SPF, which names the servers allowed to send it. A domain is on Microsoft 365 when its MX points at Exchange Online (mail.protection.outlook.com, mail.eo.outlook.com or mx.microsoft), or at a spam filter while its SPF names Microsoft. That second pattern usually means Microsoft 365 behind the filter, but SPF only proves Microsoft may send for the domain, so we count it separately. Google Workspace when the MX is Google’s.

What this does not show: a company’s own mail host is not where its agent’s targets live, and the 209 are a list of organisations with a visible agent, not a random sample of everyone building one. The outage timeline is Microsoft’s own running account as reported while it was still going on. Microsoft has not yet published its review of the incident.

Sources

1. Is Microsoft Outlook down? Company investigates error reports, NBC Chicago, read 13 November 2026
2. Microsoft 365 outage, 12 November 2026: what happened and what admins can do, azureblog.co.uk, read 13 November 2026
3. Microsoft 365 Outage, November 12, 2026: What Is Down and the Timeline, On-Site Technology, read 13 November 2026
4. The official MCP server registry and the Y Combinator company directory, read 11 November 2026
5. OpenStreetMap, read through the Overpass API on 10 and 11 November 2026