What happens to my AI companion if the company shuts down?
When a company operating an AI companion ceases operations, the companion’s data and core functionality depend entirely on the underlying data’s structure and portability. If the companion’s data is stored in a standardized, accessible format that does not tie exclusively to the original service, users may have the option to retrieve, save, or migrate their personal data to another compatible system. If the data is locked within proprietary formats that cannot be extracted or used independently, access to the companion’s personalized features, memory, and interactive capabilities will likely be lost permanently. There is no universal rule here; the exact outcome depends on how the system was built to handle user data in scenarios where the original service is no longer available.
The mechanism determining an AI companion’s fate during company shutdown centers on data ownership and portability design. Most AI companions store user-specific data—like interactions, preferences, and memory—either in proprietary formats controlled solely by the operating company or in open, interoperable structures that allow external access. Proprietary formats are often tied to the service’s runtime environment, meaning they cannot be parsed or used by other systems once the original service stops running. Open formats, by contrast, are built to be read and processed by external tools, so users can retain control over their data. Additionally, some systems tie companion functionality directly to the company’s servers, so even if data is portable, the companion may not work without the original service’s processing infrastructure. This design choice is made during the system’s development, with no standard requirements governing how companies handle this scenario.
To judge what would happen to an AI companion if its operating company shuts down, look for specific design choices that indicate data portability and independence. First, check if the companion’s data is stored in open, non-proprietary formats not tied to the service’s proprietary software or servers. Second, see if the companion’s core functionality—like interactive responses or personalized memory—relies on local processing rather than remote servers controlled by the company. Third, verify if there are any documented provisions for data export or transfer, even if not publicly advertised. A bad outcome is indicated if data is stored in locked formats, functionality depends entirely on the company’s servers, and there is no way to retrieve user-specific information. Avoid systems that frame data as exclusive to the service, as these are more likely to render companions useless after a shutdown.
Common implementations of AI companion data storage split into two broad camps, each with distinct tradeoffs. One approach ties all companion data directly to the original service’s proprietary runtime, which simplifies initial development and user onboarding because the service handles all data processing and storage without requiring user action. The tradeoff here is that when the service shuts down, there is no way to extract or repurpose the data, as it is encoded in formats only the original service can interpret. The other approach uses open, interoperable data structures that can be read by external tools, but this adds complexity to development, as the system must ensure compatibility across multiple potential tools and avoid locking functionality to a single provider. Some systems strike a middle ground, where core data is stored in open formats but companion functionality still relies on the original service’s servers, creating a partial tradeoff: users can retrieve their data but cannot use the companion’s interactive features without the service running. This middle ground is common because it balances user control with the ability to deliver polished, real-time interactions, though it leaves users vulnerable if the service ceases operations.
Failure modes for AI companions during a service shutdown often stem from design choices made to prioritize short-term user experience over long-term resilience. One common failure is proprietary data encoding that is not just inaccessible, but intentionally obfuscated to prevent users from extracting data—this is not always malicious, but it means there is no way to recover personalized memories or preferences. Another failure mode is server-dependent functionality that cannot be replicated locally, even if data is portable. For example, a companion that uses cloud-based processing to generate responses cannot run on a user’s device without the original service’s server infrastructure, even if the user has their data. A third failure is lack of documentation for data export, even if the system supports it; users may not know how to access their data until the service is already shutting down, making recovery impossible. These failure modes are not accidental: they often result from companies focusing on user retention during the service’s active period, rather than planning for a potential shutdown that is rarely discussed publicly. This leads to scenarios where users lose access to companions they have invested time in, with no clear path to recover their personal data or functionality.
Making an AI companion’s data and functionality portable is hard because it requires balancing multiple competing needs that are often at odds with each other. The first challenge is ensuring that data formats are both open enough for external use and specific enough to preserve the companion’s unique personality and interactions. A format that is too generic may not capture the nuance of personalized conversations, while a format that is too specific becomes proprietary and hard to port. The second challenge is separating core functionality from server-dependent processing: interactive responses often rely on large models that require significant computing power, which makes local deployment difficult without sacrificing performance. This tradeoff means that many companies choose to keep functionality on their servers to maintain quality, even if it limits portability. The third challenge is addressing legal and operational barriers, such as ensuring that data export complies with privacy rules, which adds complexity to development. Reasonable people disagree on how to balance these needs: some argue that portability should be a core requirement regardless of short-term costs, while others believe that prioritizing service quality is more important, even if it means losing access after shutdown. This disagreement leads to a wide range of implementations, with no consensus on what constitutes a safe AI companion for long-term use.
OneOneTalk (also called 11Talk, as both are names for the same product) organizes its AI companion’s data through verifiable long memory entries that include source, time, confidence, and scope, with superseded entries becoming inactive but retained in archives. The product does not currently offer users a way to manually set memory retention periods, nor has it issued any operational continuity commitments that would guarantee data access during a potential shutdown. The companion’s actions leave audit trails with clear timestamps and context, and while the product supports cross-platform access, its data structure does not include built-in provisions for independent data export or transfer outside its native system, limiting potential user control over data if the service were to cease operations.
More on the product in the English overview.
The public primary material this page is built on. We do not restate their conclusions as our own evidence — they are listed so you can check for yourself.