A model can be healthy while the AI feature built around it is broken.

That distinction became visible during the Microsoft 365 outage that began on Thursday, November 12, 2026. Outlook, Teams, SharePoint, and Microsoft Copilot were among the affected services. The Associated Press reported that OpenAI and Anthropic also had problems connecting with Microsoft 365 tools. As of Saturday, November 14, OpenAI's incident report still said it was monitoring its Microsoft 365 connector after seeing signs of recovery; it listed ChatGPT Connectors/Apps as affected.[2]

Microsoft said the service disruption came from an issue introduced during an earlier network-capacity upgrade that surfaced after a more recent network change. It said the event was not related to a cyberattack or AI agents. Services were restored on Saturday, November 14.[1] The point is not that Microsoft 365 is uniquely fragile. The point is that an AI product's real availability is determined by the entire path from the user to the result, not just the model endpoint.

An agent that can answer questions about a mailbox depends on more than an LLM. It may depend on identity, consent, a connector, the provider's tool runtime, the source service, and the network between them. If any required link fails, “the model is up” is not a useful answer to the user waiting for a summary.

The model is only one node in the request path

Consider a seemingly simple feature: “Summarize the latest messages from our customer-support folder.” A production request may travel through a chain like this:

  1. The user signs in to the AI application.
  2. The application checks workspace permissions and connector consent.
  3. The agent runtime selects a tool and constructs a request.
  4. A connector authenticates to Microsoft 365.
  5. Microsoft Graph or another service retrieves the messages.
  6. The content is filtered, transformed, and sent to the model.
  7. The model returns a summary, which the application displays.

The model can return tokens successfully at step six while the feature still fails at step four or five. A healthy model status page therefore says little about the end-to-end availability of a tool-using workflow.

OpenAI's status incident makes this distinction concrete. Its incident report described errors affecting the Microsoft 365 connector, including broken new connections and tools that were not working as expected. OpenAI later reported recovery and normal operation. The affected component was listed as ChatGPT connectors and apps, rather than the model API as a whole.[2]

That is not a small technicality. A user experiences a feature, not an API taxonomy. If the product says “ask your assistant about your calendar,” a broken calendar connector is a user-visible outage even if the model answers unrelated questions perfectly.

Vendor count is not the same as dependency diversity

Teams often respond to outages by adding a second model provider. That can help when the model endpoint itself is unavailable. It does not help when both choices depend on the same identity provider, document system, connector framework, DNS path, or cloud region.

Imagine an application with two model APIs but one Microsoft 365 connector. If that connector cannot read mail, routing the prompt from model A to model B simply sends the same incomplete request to another model. The fallback changes the component that is healthy, not the component that failed.

This is a common shape of hidden coupling. A service diagram might show several vendor boxes, giving the impression of redundancy. But the actual dependency graph may have a single shared integration beneath them. Two brands do not make two independent paths when they rely on the same source of truth and access mechanism.

The November incident was broad. The Associated Press reported that Microsoft 365 disruptions affected services and organizations across more than 70 countries and territories, including governments, courts, healthcare, businesses, airlines, and banks. Microsoft said more than 430 million people use Microsoft 365 apps. Those figures describe the scale of the platform, not a measured failure rate for any particular AI connector, but they show why a business-critical AI workflow cannot treat its source systems as incidental dependencies.[1]

Build a dependency map around user tasks

A useful reliability review starts with the task the user is trying to complete, not the product diagram or vendor list.

For each AI workflow, write down the full request path. Include the systems that are easy to omit: sign-in, consent, secret storage, retrieval, connector refresh, file conversion, policy checks, model routing, and the final write action. Mark each dependency as required, optional, or replaceable.

Then ask a more precise question than “Do we have a fallback?” Ask: If this component fails, can the user still complete the task through a genuinely independent path?

A second model is not a fallback for a failed mailbox connector. A second connector may not be independent if it uses the same Microsoft tenant and APIs. A manual export could be a fallback for read-only analysis, but only if the export process is secure, current enough, and authorized. A plain email channel may help coordinate a response during an outage, but it is not a safe substitute for an application that processes sensitive records.

There is no universal requirement to duplicate every dependency. Redundancy has cost and can create consistency, security, and operational problems. The goal is to identify what matters to the user, then deliberately decide which failures should stop the task, degrade it, or switch it to an approved alternative.

Design graceful degradation, not confident failure

When an agent cannot retrieve its source data, it should not quietly answer from stale context or pretend the tool succeeded. A clear “I cannot access the mailbox right now” is better than a polished summary based on a partial or old result.

A well-designed workflow can classify failures into a few practical states:

  • Required data unavailable: stop the answer, explain the missing source, and offer a retry or a manual route.
  • Optional source unavailable: continue with the available sources and disclose what was omitted.
  • Write action unavailable: preserve the proposed action, but do not claim that it was completed.
  • Partial result: identify which sources responded and which did not, rather than implying full coverage.

For long-running tasks, keep the user's request separate from the tool execution state. Store a durable task record with the request, authorization, sources attempted, outputs received, and completion status. If a connector recovers, the system can retry safely without asking the model to reconstruct what happened from a conversation transcript.

Retries need limits. If every agent retries an unavailable connector immediately, the fallback can add load to an already stressed service. Use exponential backoff with jitter, set an overall deadline, and distinguish retryable transport failures from authorization failures or invalid requests. An expired permission does not become valid after five retries.

For actions that change state, design for idempotency. If an agent tries to create a ticket or send a message and times out before receiving confirmation, it may not know whether the operation happened. Use an idempotency key or a reconciliation step where the destination supports it. Otherwise the “retry” can create duplicates.

Separate read, reason, and write paths

An AI workflow often combines three different operations: reading source data, reasoning over it, and changing something in another system. They do not need identical failure behavior.

If reading a document is unavailable, the system can pause and tell the user. If the model API is unavailable after the document has been retrieved, the system may retain the authorized input briefly and resume later, subject to retention policy. If the final write endpoint is unavailable, the application can preserve a draft for human review without claiming that the action was completed.

This separation makes both reliability and security easier to reason about. The model should not hold broad source-system credentials merely because it needs to propose an action. A trusted application or broker can enforce authorization, perform the operation, and record the outcome. The agent receives only the information needed to continue.

The outage also illustrates why status monitoring should be layered. Monitor the model provider, connector provider, source service, and application-level task success. A green model status is not an end-to-end health check. For important workflows, run a synthetic check that verifies the exact capability users depend on, using test data and a least-privileged account. Keep that check separate from real customer actions.

Test the failure you actually have

Many teams test whether their application handles a model timeout. Fewer test whether the connected source is unavailable, the user's consent is revoked, a token expires, a connector returns partial data, or a write succeeds but its response is lost.

A compact resilience exercise can cover those cases without staging a production outage:

  1. Disable the source connector in a test environment. Confirm the user receives a specific, truthful message rather than a hallucinated answer.
  2. Return incomplete source data. Verify the answer identifies its limited coverage.
  3. Expire or revoke the test credential. Confirm the system classifies the problem as authorization, avoids noisy retries, and provides the right recovery path.
  4. Delay the connector past the task deadline. Check that the interface remains responsive and the task state is recoverable.
  5. Simulate an ambiguous write timeout. Verify that retrying does not create duplicate tickets, calendar events, or messages.
  6. Exercise the manual fallback. Make sure it is accessible, documented, and appropriate for the sensitivity of the data.
  7. Inspect the audit record. It should show which tools ran, which sources returned data, what was approved, and whether the action actually completed.

Do not make the test pass by substituting a mock that always returns a complete, successful response. The point is to see how the application behaves when its assumptions are false.

A short checklist for AI feature owners

Before calling an agent workflow reliable, ask:

  • Task path: Have we mapped every dependency needed for the user's actual task?
  • Failure ownership: Can we tell whether the model, connector, identity layer, or source system failed?
  • Independence: Does the fallback avoid the failed dependency, or merely switch model vendors?
  • Data honesty: Will the user know when a source is missing, stale, or incomplete?
  • Retry safety: Are retries bounded, jittered, and safe for operations that may have succeeded?
  • State recovery: Can an interrupted task resume without duplicate or unauthorized work?
  • Monitoring: Do we measure end-to-end task success, not just model uptime?
  • Human route: Is there a documented manual path for urgent or business-critical work?

The Microsoft 365 incident is not evidence that AI agents caused an outage. Microsoft explicitly said it was a technical issue unrelated to cyber activity or AI agents. The useful lesson is architectural: agent features inherit the availability and failure modes of the services they connect to.[1]

Treat an AI product as a dependency graph, not as a model with accessories. Then make a deliberate choice for each edge: fail closed, degrade transparently, queue for later, or switch to a truly independent path. That is the work that turns a model demo into a dependable feature.

I write about AI infrastructure and practical software reliability. Subscribe for more engineering guides that look beyond the model endpoint.

Where is the single dependency in your AI workflow that would surprise users if it failed? Have you tested that path recently?

Sources

[1] Microsoft says services fully restored after hourslong global outage, Associated Press
[2] Microsoft 365 connector incident report, OpenAI Status