Personal Context Portability

Personal Context Portability

Personal context portability is the ability for a person or project to move, reuse, inspect, and govern useful working context across AI assistants, devices, chat systems, local clients, cloud services, memory layers, and archives while preserving source provenance, privacy, and operator control.

In AI-assisted work, context includes more than a chat transcript. It may include project goals, files, previous decisions, style preferences, personal background, source artifacts, prompts, contact history, meeting notes, and local working folders. A portable context system tries to make that context available beyond one tool or session without making it unverifiable, stale, or unsafe.

Personal context portability is adjacent to AI memory, personal knowledge management, local-first software, and personal CRM, but it is not identical to any one of them. AI memory is usually controlled by a specific product. Personal knowledge management often centers on notes and links. Personal CRM focuses on relationship memory. Personal context portability describes the broader problem of carrying useful working context across systems while keeping enough control to know what is being used and why.

Background

The topic came from a June 2026 fireside conversation with Adam Kerpelman, where Hypercontext was described as a tool for preserving and moving personal or project context across machines and AI tools. The same session also surfaced context management, memory, and model orchestration as practical pain points in daily AI work.

Those problems are common because AI tools often keep context in product-specific places: chat histories, project workspaces, memory settings, uploaded files, connected apps, local folders, or editor rules. A user may build useful state in one assistant, then lose it when switching machines, models, clients, or workflows. The result is repeated explanation, inconsistent outputs, and weak provenance for claims or preferences.

A durable wiki treatment should treat the fireside as a source anchor, not as the whole frame. The broader topic includes local-first data ownership, file-based context, assistant memory controls, project knowledge bases, context-access protocols, and the lifecycle of sensitive personal information.

Core Concepts

Working context is information that helps a person or AI assistant continue a task. It may include goals, constraints, project state, documents, conversation summaries, style preferences, implementation notes, and links to source artifacts.

Portable context is working context represented in a way that can move between tools, devices, or sessions without losing source meaning. Portability can be simple, such as Markdown files in a local folder, or more complex, such as a database indexed for retrieval by multiple AI clients.

Source artifacts are the evidence behind context. They can include recordings, transcripts, meeting summaries, documents, code files, issues, notes, or previous outputs. Without source artifacts, portable context can become a pile of unsupported memory.

Provenance is the trail that shows where a fact, preference, or summary came from and when it was observed. Provenance matters because portable context can be wrong, stale, private, or inferred. A useful context system should help distinguish first-party notes, source-backed claims, generated summaries, inferred preferences, and open questions.

Context lifecycle describes what happens after context is created. A portable context store needs ways to refresh, correct, archive, delete, or demote old context. This is especially important for personal information and private facts about other people.

Storage And Portability Patterns

Portable context can live in several forms.

Plain files are the most inspectable pattern. Markdown notes, AGENTS.md files, editor rules, style guides, and preference documents can be copied, versioned, reviewed, and used by many tools. Obsidian is one example of a local Markdown vault pattern: notes are stored as plain text files in a local folder.

Local databases can store richer structure, such as entities, timestamps, relationships, embeddings, and source links. They can be harder to inspect directly, but they support search, filtering, and synchronization at larger scale.

Tool-native memory keeps context inside a product. ChatGPT memory and Claude Projects are examples of product-specific context surfaces. These can be useful because they are close to the assistant experience, but the user must understand what is stored, how it is used, how it can be corrected, and whether it can be exported or reused elsewhere.

Project workspaces group context around a task or collaboration. A project may contain uploaded files, chat histories, project instructions, and a knowledge base. This pattern is useful for continuity, but it can still create lock-in if the context cannot be inspected or moved.

Protocol-accessible context uses interfaces that allow AI systems to connect to external tools and data sources. The Model Context Protocol is relevant here because it defines a way for AI applications to connect to local files, databases, tools, prompts, and workflows. MCP is not the same thing as personal context portability, but it can be part of a portability architecture.

Local-First And User Control

Local-first software is a useful reference point for personal context portability. The local-first frame emphasizes ownership, offline use, multi-device sync, long-term preservation, security, privacy, and user control.

A personal context store does not have to be local-only, but local-first principles help clarify the design problem. The user should be able to keep useful context under their control, inspect it without a single vendor, and continue working when a cloud service or AI client changes. Sync should not require surrendering all context to a product that cannot export or explain it.

For AI work, local-first context also changes the trust boundary. If a folder, database, or vault becomes readable by agents, the user needs permissions, review checkpoints, and source labels. A context store that is easy for an assistant to read can also be easy to over-share.

AI Tool Context

Current AI tools expose different forms of durable context.

ChatGPT memory is an example of assistant memory with user controls. OpenAI's Memory FAQ describes memory and chat-history behavior, source views, connected-app context, and deletion controls as of June 2026. These details are freshness-sensitive and should be dated when cited.

Claude Projects are an example of project-scoped context. Anthropic describes Projects as self-contained workspaces with chat histories, knowledge bases, uploaded documents, and project instructions. This pattern helps preserve context within one product and workspace.

Codex AGENTS.md and Cursor rules are examples of file-based or workspace-based instructions for AI coding tools. They show how durable context can be encoded as project guidance rather than hidden in a chat transcript.

Obsidian represents a different pattern: local Markdown files that remain user-readable outside the app. That makes it relevant to portability even when it is not an AI-specific product.

Hypercontext is a source-specific example from the fireside. Its public page describes it as a personal AI context server and universal AI context layer for personalized context, background, content style, and preferences. That public source verifies broad positioning, but not implementation details. A separate Hypercontext page should wait for stronger public documentation.

Provenance, Privacy, And Lifecycle

Portable context increases both usefulness and risk. It can help a person avoid repeating background, maintain continuity across tools, and carry project state between machines. It can also preserve old mistakes, expose private information, or cause assistants to rely on unsupported claims.

A portable context system should mark where each item came from. A transcript, a human-written note, a generated summary, and an inferred preference are different kinds of evidence. They should not be treated as equally reliable.

Privacy is especially important when the context includes other people. Relationship memory, meeting transcripts, chat logs, and contact notes may include sensitive facts or inferred traits. The existing Personal CRM page is a related topic for relationship memory, but personal context portability is broader and should not duplicate that page.

Deletion and correction are also central. If context is copied into files, app memory, vector indexes, summaries, and project workspaces, deleting it from one place may not remove it from all places. A durable context system needs a lifecycle model that says how context is created, reviewed, updated, archived, and removed.

Examples And Related Tools

Personal context portability can be seen as a pattern across several tool classes:

local note and knowledge systems, such as Markdown vaults;

assistant memory systems, such as ChatGPT memory;

project workspaces, such as Claude Projects;

AI coding context files, such as AGENTS.md and editor rules;

protocol-based context access, such as MCP;

relationship-memory systems, such as Personal CRM;

personal context servers, such as Hypercontext.

These examples should not be treated as a single product category. They show different ways of storing, moving, exposing, and governing context.

Open Questions

Which context should be portable as files, which as structured databases, which as tool-native memory, and which should remain temporary?

How should a personal context store handle consent and private facts about other people?

What does deletion mean when the same context exists in chats, summaries, local files, memory systems, and connected apps?

How should stale context be detected, corrected, archived, or expired?

Should Hypercontext become a separate wiki page after more public source verification?

How should source provenance be represented so agents can distinguish first-party facts, summaries, inferred preferences, and old assumptions?

Which current products are durable enough to cite as examples, and which are too volatile to cite beyond current-state notes?

Related Topics

Personal CRM

AI Context Systems

Hypercontext

Local-first Software

Model Context Protocol

Agent Memory

Personal Knowledge Management

Further Reading

Local-first software: https://www.inkandswitch.com/essay/local-first/

Model Context Protocol introduction: https://modelcontextprotocol.io/docs/getting-started/intro

OpenAI Memory FAQ: https://help.openai.com/en/articles/8590148-memory-faq

Claude Projects help: https://support.claude.com/en/articles/9517075-what-are-projects

Codex AGENTS.md guide: https://developers.openai.com/codex/guides/agents-md

Obsidian data storage: https://obsidian.md/help/data-storage

Hypercontext: https://hypercontext.me/

Personal CRM: https://portal.raidguild.org/wiki/personal-crm