# When Your AI Goes Offline, Who Remembers Who You Are? > Source: > Published: 2026-11-14 19:01:01+00:00 **November 13, 2026** Yesterday, I experienced something that made me think about our growing dependence on artificial intelligence. I was trying to use Microsoft Copilot, my AI assistant at work, when it stopped responding. Initially, it seemed like an ordinary service disruption. You wait a little, refresh the page and try again. Perhaps it is your internet connection. But then I realized something slightly uncomfortable. I had been relying on this assistant to remember the context of my work: ongoing projects, previous discussions, technical decisions, things I had explored and ideas I had not finished developing. It had gradually become a place where a significant amount of my working context lived. Without it, I was not simply missing an AI tool. I was missing the system that helped me remember where I had left off. That led me to a question: **If the AI that knows your context suddenly becomes unavailable, how much of that context can you recover independently?** This question became particularly relevant as Microsoft experienced a widespread disruption across its Microsoft 365 services on November 12–13, 2026. The incident exposed a problem that deserves more attention than another discussion about cloud uptime. We are beginning to outsource not just tasks, but memory and continuity to AI systems. What happens when those systems disappear, even temporarily? On November 12, 2026, Microsoft began investigating widespread connectivity problems affecting Exchange Online. The disruption continued into November 13, affecting users across multiple regions. Microsoft tracked the disruption under two major service incident IDs: EX1550543, concerning users being unable to connect to their Exchange Online mailboxes through multiple connection methods, and MO1550821, concerning connectivity problems across multiple Microsoft 365 services. The impact extended beyond Outlook. Microsoft reported problems affecting Microsoft 365 Copilot, Microsoft Graph, Planner, To Do, Defender XDR, Purview, SharePoint Online, Teams and other connected services. The extent of the disruption varied by product because not every feature depended on the affected Exchange infrastructure. For example, Microsoft said that core Teams messaging and online meetings remained largely functional, while features dependent on Exchange Online, such as calendar and meeting scheduling, could fail. Direct access to files stored in SharePoint also remained functional. The scale was significant. Downdetector recorded nearly 130,000 reports of Outlook problems around the peak of the disruption. These were user-submitted reports rather than a verified count of affected individuals. The outage also affected businesses and public-sector operations. In Japan, government IT infrastructure was reported to have been affected, with officials monitoring the situation. Across other regions, organizations experienced disruption to their normal workflows. The incident demonstrated how deeply Microsoft 365 is embedded in everyday business operations. Email, meetings, documents, task management and AI assistants may appear to be separate products, but their underlying services are interconnected. The incident reports are available through Microsoft’s service status communications and the incident records reproduced by the University of Pennsylvania. The Associated Press also reported on the widespread disruption and its impact on users and organizations. Sources: [Microsoft Service Health](https://status.cloud.microsoft/), [Microsoft incident reports](https://mailservices.isc.upenn.edu/computing/email/penno365/alerts/ms-incidents.html), [Associated Press coverage](https://apnews.com/article/6376045281feb430c0b923e3a4b251c2), and [ITmedia’s Japanese coverage](https://www.itmedia.co.jp/news/article/2611/13/2000003161/). The technical explanation is particularly interesting. In its incident updates, Microsoft reported that a portion of its servers had unexpectedly become unavailable, leaving the remaining infrastructure under elevated load. As more servers became unavailable, the remaining systems had to handle additional requests, increasing pressure on the infrastructure. Microsoft subsequently reported that a process on the affected servers, responsible for establishing secure connections, was becoming overwhelmed and causing those servers to stop processing requests. The company was investigating a recent network configuration change that correlated with the beginning of the disruption, while also working on configuration changes and infrastructure restarts to restore service. Its recovery efforts involved restarting affected servers, validating configuration changes on a subset of infrastructure, redirecting traffic through alternative routes and temporarily limiting traffic in certain locations. Recovery was gradual because some servers risked becoming unresponsive again when traffic was reintroduced. At the time of writing, Microsoft had not published a definitive final root-cause analysis. It is important to distinguish between the failure mechanism identified during the incident and the final explanation of why it happened. There was no established evidence that the outage was caused by a cyberattack. The architectural lesson is that a cloud platform can have enormous infrastructure capacity and still experience a widespread failure when a critical component becomes a bottleneck. Redundancy alone is not enough. Systems must also account for shared dependencies, failure propagation, capacity redistribution, health-check reliability and recovery under real traffic. This is not unique to Microsoft. It is a broader distributed-systems engineering challenge, and it becomes increasingly important as AI applications depend on multiple cloud services working together. The outage made me think about a different kind of dependency. Consider how we use AI assistants today. We ask them to help us write, research, code, plan, organize meetings, explore ideas and make decisions. Over time, an AI assistant may accumulate a surprisingly detailed understanding of its user. It might know what you do professionally, which projects you are developing, what technical decisions you made, why you made those decisions, which ideas you abandoned, what you are currently learning and what you were planning to do next. Some of this information exists in documents and applications. Some exists in conversations. Some exists only in the relationships between those pieces of information. An AI assistant makes it easier to retrieve and connect that context. But what happens when the assistant becomes unavailable? You might still have access to your code, but not remember why a particular architectural decision was made. You might still have your project documents, but not know which version reflects the latest direction. You might have access to your conversation history, but another AI agent may not understand what is important in it. This leads to a distinction I think we need to take seriously: **Data availability is not the same as context availability.** Having access to your files does not automatically mean you can reconstruct your working state. Having access to your chat history does not automatically mean another AI can continue where the previous one stopped. And having an alternative AI provider does not necessarily solve the problem if your context remains locked inside the original platform. We are building increasingly intelligent assistants, but we have not fully solved the question of what happens when we need to replace one. Most AI assistants operate within their own ecosystems. Microsoft Copilot, ChatGPT, Claude and other AI products have different memory mechanisms, integrations, permissions and ways of accessing user information. Some allow users to export conversations or connect external data sources. However, exporting a conversation is not the same as transferring the state of an ongoing collaboration. Imagine moving from one AI assistant to another. The receiving assistant needs more than a transcript. It needs to understand the original objective, what has already been completed, which decisions are final, which constraints must be respected, what remains unresolved and what should happen next. Without this information, the user becomes responsible for reconstructing the entire context manually. I see three related problems here. The first is memory fragmentation: personal and professional context is distributed across different AI providers and applications. The second is the lack of context portability: there is no universally adopted format for transferring a complete human-AI working state between different agents. The third is cloud dependency: even if your information exists somewhere, the service responsible for retrieving, processing or interpreting it might be unavailable. This is why I think we need to separate two things: the intelligence layer, which can change between AI providers, and the context layer, which should remain under the user’s control. This is the product direction I started exploring after the outage. Instead of building another AI assistant, what if we built infrastructure that allowed different AI assistants to share a user’s authorized context? I call this concept **ECHO — Every Context Has an Owner.** ECHO would be a provider-independent memory and continuity layer that sits between the user and their AI agents. Its purpose would be simple: if one AI provider becomes unavailable, another compatible agent should be able to retrieve the user’s context and continue the work. The foundation would be a personal context repository. Rather than storing only entire conversations, it would organize meaningful information about a user’s professional identity, preferences, projects, decisions, research, goals and pending tasks. The repository would become a structured representation of the knowledge accumulated through interactions with different AI systems. Above this repository, a context intelligence layer would transform unstructured conversations and documents into reusable knowledge. For example, a long discussion about a software project could be distilled into a project summary, confirmed decisions, technical constraints, unresolved questions, action items and references to the original discussions. This layer would also need to understand that memories change. A decision made six months ago should not automatically override a decision confirmed yesterday. The system must recognize outdated information, identify contradictions and preserve the history of important changes. The next component would be an agent interoperability layer. It would allow different AI agents to retrieve authorized context through a common interface. The Model Context Protocol (MCP) could be useful here because it provides a standardized way for compatible AI applications to interact with external tools and context sources. However, MCP alone does not provide portable memory, reliable checkpointing or automatic recovery. Those would be additional capabilities that ECHO would need to implement. Finally, a continuity and recovery layer would periodically capture the state of a human-AI collaboration. If an agent became unavailable, another compatible agent could retrieve the latest checkpoint and reconstruct the task. The objective would not be to reproduce the original AI’s personality or internal reasoning. It would be to restore enough verified context for the user to continue working. I would introduce a concept called a **Human-AI Continuity Capsule (HACC)**. Think of it as a portable package containing the information another AI agent needs to continue a user’s work. Instead of transferring thousands of messages, the system creates a structured snapshot of the collaboration. Imagine you are developing an EV battery traceability application. Your capsule could record the project’s objective, its current progress, the architecture decisions already made, the technical constraints, the open questions and the next planned action. It would also include references to the original documents and discussions from which this information was derived, along with a timestamp indicating when the context was last confirmed. Now imagine the original AI assistant becomes unavailable. You open another compatible assistant and connect it to the context repository. The new agent retrieves the capsule and responds: “I have restored your project context. Your last confirmed decision was to use DID/VC-based identity. Credential issuance and verification are implemented. Your next planned action was to test the verification workflow. Would you like to continue?” That is a very different experience from asking an entirely new AI to read your old conversations. For this to work, a continuity capsule must be independent of any single model provider, versioned so previous working states can be recovered, and traceable so important memories link back to their original sources. It must also be permission-controlled, time-aware and capable of distinguishing confirmed facts from AI-generated inferences. The receiving AI should not blindly trust a summary. It should be able to inspect the sources, identify uncertainty and ask the user to confirm conflicting information. The real innovation is not simply memory storage. It is the ability to restore the state of a collaboration. A possible architecture would place the user at the center, with a personal context repository connected to a context retrieval API. Different AI agents could access this API through authorized integrations. A prototype could use Next.js for the frontend, Python and FastAPI for the backend, PostgreSQL for structured memory and pgvector for semantic retrieval. SQLite could provide local storage, while MCP could provide an interface for compatible agents. Provider-independent adapters could connect different AI models, and a local model running through a framework such as Ollama could provide basic assistance when cloud services are unavailable. One design principle matters more than the technology choices: **the context repository must not depend on the AI provider it is supposed to protect against.** I would use a local-first architecture. Essential context would remain accessible on the user’s device, while encrypted synchronization could keep multiple devices updated when connectivity is available. This creates two levels of continuity. The first is information continuity: even without cloud AI, the user can search memories, read project histories, retrieve decisions and access pending tasks. The second is intelligence continuity: if one cloud AI provider becomes unavailable, another compatible provider can retrieve the same authorized context. If internet access is also unavailable, a local model could provide basic assistance where the user’s hardware permits. These are different failure scenarios, however, and should be tested independently. There is another aspect of ECHO that I find particularly interesting. If we are building a system that maintains a representation of a person’s professional and personal context, who owns that information? And who gets to decide which AI agent can access it? This is where decentralized identity and verifiable credentials could become relevant. Decentralized Identifiers (DIDs) could provide a portable identifier associated with the context owner. Verifiable Credentials could support verifiable claims about professional qualifications, identity attributes or other information. Selective disclosure could allow users to share only the information needed by a particular agent. OpenID Connect could support authentication between users and applications, while encryption and access policies could protect private context and define what each agent is permitted to retrieve. Imagine authorizing a coding agent to access your technical project history without exposing your personal conversations. Or allowing a career assistant to retrieve your professional profile without giving it access to confidential company information. This is a natural extension of user-controlled digital identity. However, there are important distinctions. A verifiable credential can establish who issued a claim and whether it has been altered. It does not automatically prove that the underlying information is factually true. Similarly, proving who owns a context repository does not automatically authorize every AI agent to read it. Identity, authentication, authorization and data provenance must work together. The broader idea is that your relationship with AI should not require surrendering ownership of your context. A new protocol will take time to develop, but organizations do not need to wait for one to improve AI resilience. They can begin by maintaining approved alternative workflows when a primary assistant becomes unavailable, recording important project decisions outside AI conversations and keeping recoverable copies of critical information. They can establish alternative communication channels, include AI assistant outages in business continuity plans and identify which AI features depend on email, identity systems, APIs and cloud storage. Organizations should also simulate provider outages and measure how quickly teams can recover their work. These exercises should test not only whether employees can access their documents, but whether they can understand the current state of a project and continue without the original AI assistant. One recommendation is particularly important: **no critical business decision should exist exclusively inside an AI conversation.** AI can help generate, organize and retrieve information, but important decisions should be recorded in an approved knowledge repository. Organizations must also establish clear rules about transferring information between AI providers. A fallback agent should never receive confidential data simply because the primary service is unavailable. Resilience should not come at the cost of security. I see a larger opportunity emerging from this problem: the development of portable AI memory standards. We need common ways to represent user preferences, project states, decisions, tasks, goals and memory provenance. Without common schemas, every AI provider will continue to interpret user context differently. A portable representation would make it easier to move between agents without starting from zero. The second opportunity is AI disaster recovery. Organizations already have disaster recovery strategies for databases, infrastructure and cloud services. AI systems need similar strategies, including automatic context checkpointing, provider health monitoring, alternative model routing and measurable recovery objectives. The third is personal knowledge sovereignty. Users should be able to leave an AI platform without losing the knowledge they accumulated while using it. This means more than exporting chat history. It means maintaining a structured representation of their knowledge that can be accessed through different applications. The fourth opportunity is persistent human-agent relationships. As AI agents become more autonomous, they will participate in longer-running workflows. The next agent should understand the history, constraints and intentions of the previous one. Users should not have to repeatedly explain the same background information. Finally, this could enable more interoperable autonomous agents. Imagine working with multiple specialized agents: a research agent, a coding agent, a project management agent, a personal assistant and a career assistant. They could operate independently while accessing a shared, permission-controlled context layer. This could make multi-agent systems more useful without requiring every agent to maintain a separate, fragmented representation of the user. I would not start by building a complete platform. I would build a small experiment to test one fundamental assumption: **Can one AI agent reliably reconstruct and continue the working state of another AI agent?** The prototype would begin with a multi-step project discussion with AI Agent A. During the discussion, the user and agent would establish technical decisions, constraints and next steps. The system would then generate a Human-AI Continuity Capsule and store it in an independent context repository. Next, Agent A would be made unavailable. The user would connect AI Agent B to the same repository and ask it to continue the original task. The experiment would compare Agent B’s understanding with the original project state. Did it recover the important decisions accurately? Did it respect the previously established constraints? Could it identify the correct next action? How much information did the user have to correct manually? How long did recovery take? I would also test less straightforward situations, such as outdated memories, missing sources, conflicting decisions and expired permissions. A successful demonstration should show that context can survive the failure of an individual AI provider without compromising privacy or accuracy. This would be a meaningful starting point for a larger research and product effort. The Microsoft outage was a reminder of how much of our everyday work depends on cloud infrastructure. But my experience with Copilot made me think about something more personal. We are entering a period where AI assistants increasingly understand our work, remember our preferences, organize our thoughts and help us make decisions. Over time, they become more than tools. They become part of how we organize information and maintain continuity. That creates a responsibility for the people building AI infrastructure. We need systems that ensure the value accumulated through human-AI interactions remains accessible to the human, rather than being permanently tied to one application or provider. A cloud outage should interrupt a service. It should not interrupt someone’s ability to understand their own work. I do not think the answer is to stop depending on AI. The answer is to make that dependency more resilient, portable and user-controlled. Perhaps the next generation of AI infrastructure should not focus only on making agents smarter. It should also focus on making them replaceable. **Your AI can go offline. Your context shouldn’t.** For the incident itself, see [Microsoft Service Health](https://status.cloud.microsoft/), the [Microsoft incident reports reproduced by the University of Pennsylvania](https://mailservices.isc.upenn.edu/computing/email/penno365/alerts/ms-incidents.html), the [Associated Press report](https://apnews.com/article/6376045281feb430c0b923e3a4b251c2), and [ITmedia’s coverage in Japan](https://www.itmedia.co.jp/news/article/2611/13/2000003161/). For the technical foundations behind the proposed architecture, see the [Model Context Protocol documentation](https://modelcontextprotocol.io/), the [W3C Decentralized Identifiers specification](https://www.w3.org/TR/did-1.0/) and the [W3C Verifiable Credentials Data Model](https://www.w3.org/TR/vc-data-model-2.0/). *Editor’s note: ECHO (Every Context Has an Owner) is a proposed product and architectural concept, not an existing standardized protocol. The Microsoft incident details reflect information available on November 13, 2026. Microsoft’s final post-incident analysis may provide further clarification.* [When Your AI Goes Offline, Who Remembers Who You Are?](https://pub.towardsai.net/when-your-ai-goes-offline-who-remembers-who-you-are-c5848a2fd228) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.