From ba08381c1e717fd9f9ca29ef420372448d8df66b Mon Sep 17 00:00:00 2001 From: Dina Berry <41597107+diberry@users.noreply.github.com> Date: Wed, 8 Jul 2026 17:58:07 -0700 Subject: [PATCH 1/7] blog: Portable personal context layer (2026-07-12) Add 'Your AI Second Brain' post on carrying context across Copilot surfaces, plus 11 SVG diagrams in per-post media subfolder. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- .../2026-07-12-portable-personal-context.md | 540 ++++++++++++++++++ .../30-min-timeline.svg | 48 ++ .../architecture.svg | 76 +++ .../before-after.svg | 94 +++ .../context-islands.svg | 50 ++ .../durability-layers.svg | 49 ++ .../file-scope-comparison.svg | 41 ++ .../persona-hierarchy.svg | 57 ++ .../personalization-silos.svg | 76 +++ .../priority-stack.svg | 45 ++ .../retrieval-flow.svg | 59 ++ .../universal-transport.svg | 35 ++ 12 files changed, 1170 insertions(+) create mode 100644 website/blog/2026-07-12-portable-personal-context.md create mode 100644 website/blog/media/2026-07-12-portable-personal-context/30-min-timeline.svg create mode 100644 website/blog/media/2026-07-12-portable-personal-context/architecture.svg create mode 100644 website/blog/media/2026-07-12-portable-personal-context/before-after.svg create mode 100644 website/blog/media/2026-07-12-portable-personal-context/context-islands.svg create mode 100644 website/blog/media/2026-07-12-portable-personal-context/durability-layers.svg create mode 100644 website/blog/media/2026-07-12-portable-personal-context/file-scope-comparison.svg create mode 100644 website/blog/media/2026-07-12-portable-personal-context/persona-hierarchy.svg create mode 100644 website/blog/media/2026-07-12-portable-personal-context/personalization-silos.svg create mode 100644 website/blog/media/2026-07-12-portable-personal-context/priority-stack.svg create mode 100644 website/blog/media/2026-07-12-portable-personal-context/retrieval-flow.svg create mode 100644 website/blog/media/2026-07-12-portable-personal-context/universal-transport.svg diff --git a/website/blog/2026-07-12-portable-personal-context.md b/website/blog/2026-07-12-portable-personal-context.md new file mode 100644 index 0000000..b82d2ef --- /dev/null +++ b/website/blog/2026-07-12-portable-personal-context.md @@ -0,0 +1,540 @@ +--- +slug: /2026-07-12-portable-personal-context +date: 2026-07-12 +canonical_url: https://dfberry.github.io/blog/2026-07-12-portable-personal-context +custom_edit_url: null +sidebar_label: "2026.07.12 Portable context" +title: "Your AI Second Brain: Carry Context Across Every Copilot Surface" +description: "Build a portable personal context layer with markdown and GitHub so Copilot, CLI, Scout, and other AI tools can share your preferences, decisions, and active work." +tags: + - ai + - copilot + - personal context + - github + - markdown + - mcp + - productivity + - architecture +keywords: + - portable personal context + - ai second brain + - copilot context + - cross-surface copilot + - ai memory markdown + - github personal context repo + - decisions ledger + - model context protocol + - portable ai memory + - developer productivity ai +--- + +Every developer I know uses multiple AI surfaces daily. GitHub Copilot in VS Code for coding. Copilot CLI for terminal workflows. Microsoft 365 Copilot for email and meetings. Microsoft Scout for desktop orchestration. Maybe Claude, ChatGPT, or Cursor on the side. + +The problem? **Every time you switch surfaces, you start over.** The AI that just helped you plan a feature in Scout has no idea you exist when you open VS Code. The Copilot CLI that helped you craft a git command doesn't know your branch naming conventions that you already taught VS Code. + +Your context — who you are, what you're working on, how you like to work, and what you've already decided — is trapped in whichever tool you happened to tell it to. + +This post describes how to fix that with a **portable personal context layer**: a structured set of files in a GitHub repo that any AI surface can read, giving every tool your "second brain" from the first interaction. + +--- + +## The Problem: Context Islands + +![Context islands diagram showing isolated AI surfaces](./media/2026-07-12-portable-personal-context/context-islands.svg) + +Here's what context fragmentation looks like in practice: + +| Surface | What it knows about you | Where that knowledge lives | +|---------|------------------------|---------------------------| +| **Copilot in VS Code** | `.github/copilot-instructions.md` in current repo | Per-repo, per-machine | +| **Copilot CLI** | Nothing persistent between sessions | Ephemeral | +| **Microsoft 365 Copilot** | Your M365 Graph data (emails, calendar) | Cloud, not exportable | +| **Microsoft Scout** | Memories, preferences, profile | Local app state | +| **Claude** | `CLAUDE.md` per project, memory | Per-project file + cloud memory | +| **Cursor** | `.cursorrules` per project | Per-project file | + +Notice the pattern: every tool has invented its own format for "things to know about the user," and none of them talk to each other. + +The result: +- You repeat preferences in every tool ("I prefer concise output," "use TypeScript," "don't auto-push to main") +- Decisions made in one surface are invisible to others +- Your expertise and boundaries are only known where you've explicitly stated them +- Switching tools feels like introducing yourself to a new coworker every time + +--- + +## You Already Know What the Solution Feels Like + +If you've set up **Custom Instructions** in M365 Copilot, **Memory** in ChatGPT, or **CLAUDE.md** in Claude — you already know what personal context feels like. You've experienced the difference between an AI that knows you and one that doesn't. + +![Personalization features exist in every tool but are locked to that tool](./media/2026-07-12-portable-personal-context/personalization-silos.svg) + +| Built-in Feature | What it does | The problem | +|---|---|---| +| **M365 Copilot: Custom instructions** | "Be concise, use tables" | Doesn't reach VS Code or CLI | +| **M365 Copilot: Work profile** | Your role, org, skills | Locked in Microsoft Graph | +| **M365 Copilot: Saved memories** | Facts remembered between sessions | Only M365 Copilot sees them | +| **ChatGPT: Memory** | Auto-extracted facts about you | Only ChatGPT sees them | +| **Claude: CLAUDE.md** | Per-project instructions | Only Claude Code sees them | +| **Cursor: Rules** | Coding preferences | Only Cursor sees them | + +Every tool has built its own personalization silo. **Personal context is personalization that travels.** + +``` +Today: + M365 Copilot → knows you like concise output + VS Code Copilot → doesn't know (asks again) + Copilot CLI → doesn't know (asks again) + Scout → has its own separate copy + Claude → has its own separate copy + +With portable personal context: + All surfaces → read from the same source → know you immediately +``` + +--- + +## Why Not Just Use Those Existing Features? + +| | Built-in Personalization | Portable Context | +|---|---|---| +| **Portability** | One surface only | Every surface | +| **Transparency** | Opaque ("View work data") | Human-readable markdown | +| **Exportability** | Can't export | `git clone` anywhere | +| **Versioning** | No history | Full git history | +| **Control** | Platform decides format | You decide format | +| **Decisions** | No structured log | Append-only ledger | +| **Auto-extraction** | Yes (convenient) | Manual (precise) | + +They're complementary. Use built-in personalization where it exists. Use portable context as the canonical source that stays consistent across *everything*. + +--- + +## Why Not CLAUDE.md, copilot-instructions, or .cursorrules? + +Those are **instructions TO the AI** scoped to one project. Personal context is **information ABOUT you** that spans all projects and tools. + +![Scope comparison showing per-tool files as narrow vs personal context as universal](./media/2026-07-12-portable-personal-context/file-scope-comparison.svg) + +``` +.github/copilot-instructions.md → "In this repo, use ESM imports" +personal-context/process/... → "I always prefer ESM over CommonJS" +``` + +The repo-level file says how to work in *that codebase*. Personal context says how to work with *you*. + +--- + +## Why Not Just an Agent or Skill? + +This is the subtlest distinction. Agents and skills are scoped to tasks. Personal context is scoped to **you as a person**. + +![Persona hierarchy showing person above process above skills above agents](./media/2026-07-12-portable-personal-context/persona-hierarchy.svg) + +| | Personal Context | Agent (agent.md) | Skill (SKILL.md) | +|---|---|---|---| +| **Answers** | "Who is this person?" | "How should I behave?" | "How do I do this task?" | +| **Scope** | Everything you do | One role or surface | One repeatable procedure | +| **Lifespan** | Years (grows with you) | Months (evolves with tooling) | Weeks (refined per use) | +| **Portability** | Every surface | One surface | Some surfaces | + +Knowledge flows downward: **person → process → skill → agent**. + +1. You learn something → it becomes **expertise** (personal context) +2. You repeat a process → it becomes a **workflow** (personal context) +3. You formalize the workflow → it becomes a **skill** (SKILL.md) +4. You assign skills to a persona → it becomes an **agent** (agent.md) + +Personal context is the root. Agents and skills are leaves that grow from it. Without personal context, every agent is generic — it doesn't know YOUR quality bar, YOUR boundaries, YOUR past decisions. + +--- + +## Why Not Mem0 or a Cloud Memory Service? + +[Mem0](https://mem0.ai) is a cloud API for persistent AI memory. It solves the same problem but with a different philosophy: + +| | Mem0 (Cloud) | Personal Context Repo | +|---|---|---| +| **Architecture** | Hosted API service | Local-first (files in git) | +| **Data ownership** | Third-party hosted | You own it (your GitHub) | +| **Works offline** | No | Yes | +| **Vendor dependency** | Yes (Mem0 API key) | No (just git) | +| **Human-readable** | No (vector store) | Yes (markdown you can edit) | +| **Versioned** | No (mutable state) | Yes (git history + blame) | +| **Semantic search** | Yes (their strength) | No (not needed at personal scale) | +| **Best for** | App builders serving many users | Individual developers across their own tools | + +Mem0's own research says file-based memory "works beautifully for ≤200 static memories, single user, no concurrency." That's exactly the personal context use case — ~50-150 facts about you, curated deliberately. + +--- + +## The Insight: LLMs Already Speak Markdown + +The solution isn't a complex sync service, a vector database, or a new protocol. It's simpler than that. + +![Markdown plus GitHub equals universal portability](./media/2026-07-12-portable-personal-context/universal-transport.svg) + +Every AI tool can read files. Every AI tool understands markdown. And there's one platform every developer tool already authenticates with: **GitHub**. + +> **A private GitHub repo with structured markdown files IS your portable second brain.** + +Any surface that can read a file from GitHub (which is all of them) gets your full context. No new APIs, no dependencies, no vendor lock-in. + +--- + +## The Architecture: Personal Context as a Repo + +![Architecture diagram showing canonical repo feeding multiple surfaces](./media/2026-07-12-portable-personal-context/architecture.svg) + +``` +github.com/yourname/personal-context (private repo) +│ +├── context.json ← Manifest: what's here + retrieval rules +│ +├── core/ ← RARELY CHANGES (your "constitution") +│ ├── expertise.md # What you know, your domain authority +│ ├── boundaries.md # What stays human, what AI never does alone +│ ├── role.md # Job, scope, organization +│ └── communication.md # How you prefer to interact +│ +├── decisions/ ← APPEND-ONLY (your "ledger") +│ ├── _active.md # Decisions still governing current work +│ ├── 2026-07.md # This month's new decisions +│ └── ... +│ +├── process/ ← STABLE (your "playbook") +│ ├── content-workflow.md # How you create content +│ ├── code-workflow.md # How you write and ship code +│ ├── quality-bar.md # Definition of done per work type +│ └── tool-preferences.md # Preferred tools and patterns +│ +├── active/ ← CHANGES OFTEN (your "whiteboard") +│ ├── projects.md # Current active projects +│ ├── sprint-focus.md # This sprint's commitments +│ └── parking-lot.md # Deferred items +│ +└── .github/ + └── copilot-instructions.md # Tells Copilot how to USE this repo +``` + +### Why Four Layers? + +Not all context is equal. The key insight is separating by **durability** — how often something changes and who's allowed to change it: + +![Four layers diagram showing durability spectrum](./media/2026-07-12-portable-personal-context/durability-layers.svg) + +| Layer | Half-life | Mutability | Example | +|-------|-----------|-----------|---------| +| **Core** | Months/years | Human-only | "I'm a senior developer on the Azure SDK docs team" | +| **Decisions** | Permanent (append-only) | Any surface appends | "Use generation pipeline for MCP namespace files" | +| **Process** | Weeks/months | Propose via PR | "Branch naming: {type}/{id}-{slug}" | +| **Active** | Days/weeks | Any surface overwrites | "Sprint focus: Ship auth-flow feature" | + +--- + +## What Goes in Each Layer + +### Core: Your Constitution + +This is the stuff that rarely changes — your expertise, your boundaries, your communication preferences. Any AI surface reads this to understand *who it's working with* before you say a word. + +**`core/expertise.md`** — What you know: + +```markdown +## Domain Expertise +- Azure SDK documentation across JavaScript, Python, .NET, Java, Go, Rust +- AI developer tools (MCP servers, AI Toolkit, Copilot extensions) +- Content workflow automation and multi-agent orchestration +- Technical writing for developer audiences + +## Not My Expertise (don't assume I know) +- Kubernetes operations / cluster management +- Frontend framework internals (React, Vue, etc.) +- ML model training / fine-tuning +``` + +**`core/boundaries.md`** — What stays human: + +```markdown +## What AI Should Never Do Autonomously +- Push code to upstream repositories (only to forks) +- Send emails, Teams messages, or any outbound communication +- Close or resolve work items without my confirmation +- Delete files, branches, or repos +- Make irreversible changes without showing me the plan first + +## What AI Can Do Without Asking +- Read files, search code, explore repos +- Draft content for my review +- Run tests, linting, builds +- Create branches on my fork +- Propose edits (but not commit without confirmation) +``` + +### Decisions: Your Ledger + +The most valuable layer. Every time you make a decision in any AI surface, it gets appended here. No surface should ever re-ask a question you've already answered. + +**`decisions/_active.md`** — Still-relevant decisions: + +```markdown +### [2026-07-06] Branch naming convention +- **Context:** Inconsistent branch names across repos +- **Decision:** Always use `{type}/{work-item-id}-{brief-slug}` +- **Types:** feat, fix, docs, refactor, test + +### [2026-06-15] Prefer tables over prose for comparisons +- **Context:** AI kept writing long paragraphs comparing options +- **Decision:** When comparing 3+ options, always use a table +- **Supersedes:** Nothing (new preference) + +### [2026-05-28] No hand-written namespace files +- **Context:** Generated files were higher quality than hand-written +- **Decision:** All namespace articles must come from the generation pipeline +- **Implications:** Slower to ship, but deterministically correct +``` + +### Process: Your Playbook + +How you prefer to work. This changes occasionally as you refine your workflow. + +**`process/quality-bar.md`**: + +```markdown +## When Is a Pull Request Done? +- [ ] Work item linked with "Fixes AB#{id}" +- [ ] Meaningful title and description (not just commit messages) +- [ ] No unrelated changes (surgical edits only) +- [ ] CI passes +- [ ] Review comments addressed, not dismissed +- [ ] Staged preview links included for doc changes + +## When Is an Article Done? +- [ ] Technically accurate (verified against product behavior) +- [ ] Code samples run without modification +- [ ] All links resolve (no 404s) +- [ ] Metadata correct (ms.topic, ms.date, ms.service) +- [ ] Reviewed by at least 1 peer +``` + +### Active: Your Whiteboard + +The ephemeral-ish stuff — what you're working on right now. Any surface can overwrite this. + +**`active/sprint-focus.md`**: + +```markdown +## Sprint 14 (2026-07-01 → 2026-07-12) + +### Committed +1. Ship MCP auth namespace docs (AB#4521) +2. Review 3 community PRs on azure-dev-docs +3. Update AI Toolkit quickstart for v0.9 + +### Stretch +- Prototype portable context layer (this project!) +``` + +--- + +## How Surfaces Consume It + +### Selective Retrieval: Only Load What's Relevant + +A surface doesn't dump the entire repo into its prompt. The `context.json` manifest tells it what to load based on the task: + +``` +1. Read context.json (< 1KB, always cached) +2. ALWAYS load: core/boundaries.md + core/communication.md (~400 words) +3. Classify the current task → match to load_by_task +4. Load those 2-3 files (~500 words) +5. Load decisions/_active.md (~300 words) + +Total: ~1,200 words ≈ 1,600 tokens +``` + +That's less than 2K tokens for full personalization. Well within any context window budget. + +![Retrieval flow diagram](./media/2026-07-12-portable-personal-context/retrieval-flow.svg) + +### The Priority Stack + +If different layers contradict, the resolution is deterministic: + +``` +core/boundaries.md ← ALWAYS wins. Non-negotiable. +decisions/_active.md ← Settled questions. Don't re-ask. +process/*.md ← How to do things. Follow unless overridden in-session. +active/*.md ← Informational state. Not authoritative. +``` + +![Priority stack diagram](./media/2026-07-12-portable-personal-context/priority-stack.svg) + +### Writing Back: Closing the Loop + +Any surface can **write decisions back**: + +```bash +# After making a decision in any surface: +cd ~/personal-context +echo " +### [$(date +%Y-%m-%d)] {decision title} +- **Context:** {why this came up} +- **Decision:** {what was decided} +- **Implications:** {what this means going forward} +" >> decisions/_active.md + +git add decisions/_active.md +git commit -m "decision: {brief title}" +git push +``` + +Now every other surface picks it up on next read. Decision made in Scout? VS Code Copilot knows. Decision made in CLI? Scout knows. + +--- + +## Connecting Each Surface + +### GitHub Copilot in VS Code + +In your user-level `settings.json`: + +```json +{ + "github.copilot.chat.codeGeneration.instructions": [ + { "file": "~/personal-context/core/boundaries.md" }, + { "file": "~/personal-context/core/communication.md" }, + { "file": "~/personal-context/decisions/_active.md" } + ] +} +``` + +Or reference the repo in any project's custom instructions: + +```markdown + +For my personal preferences and decisions, reference: +https://github.com/yourname/personal-context +``` + +### Copilot CLI + +Create a shell function that injects context: + +```bash +# ~/.bashrc or $PROFILE +function copilot-ctx() { + local context=$(cat ~/personal-context/core/communication.md) + gh copilot suggest -t shell "$context\n\nTask: $*" +} +``` + +### Microsoft Scout + +Scout's profile can be generated FROM the canonical repo: + +```powershell +# Sync script: pull personal-context → render me.md for Scout +$role = Get-Content ~/personal-context/core/role.md -Raw +$comms = Get-Content ~/personal-context/core/communication.md -Raw +$boundaries = Get-Content ~/personal-context/core/boundaries.md -Raw + +@" +# Personal Profile +$role + +## Communication +$comms + +## Boundaries +$boundaries +"@ | Set-Content ~/.copilot/me.md +``` + +### Microsoft 365 Copilot + +Sync the repo to a OneDrive folder: + +``` +OneDrive/personal-context/ → synced from GitHub repo +``` + +Then M365 Copilot can reference those files when you ask it to "follow my preferences." + +### Any MCP-Enabled Tool (Claude, Cursor, ChatGPT) + +Expose the repo as a simple MCP resource server — or just clone locally and point the tool's config to the files. [MCP](https://modelcontextprotocol.io) is the transport layer; the repo is the data. + +--- + +## Getting Started: 30-Minute Setup + +![Timeline showing 30-minute setup in 4 steps](./media/2026-07-12-portable-personal-context/30-min-timeline.svg) + +### 1. Create the repo (5 minutes) + +```bash +gh repo create personal-context --private +cd personal-context +mkdir -p core decisions process active .github +``` + +### 2. Write your identity (10 minutes) + +Start with `core/role.md` and `core/boundaries.md`. Don't overthink it — write what you'd tell a new team member on day one. + +### 3. Capture your first decisions (10 minutes) + +Think about the last 5 times an AI tool annoyed you by not knowing something. Those are your decisions. Write them in `decisions/_active.md`. + +### 4. Connect one surface (5 minutes) + +Pick your most-used surface and wire it up. VS Code settings, Scout profile, or a CLI alias. Verify it works — ask the AI something it should now know about you. + +### 5. Evolve naturally + +Don't try to write everything upfront. When an AI asks you something it should already know, that's a signal: write it down, commit, push. Your context grows organically from real interactions. + +--- + +## The Payoff + +![Before and after comparison showing repetition eliminated](./media/2026-07-12-portable-personal-context/before-after.svg) + +After two weeks of capturing context: + +| Before | After | +|--------|-------| +| "I prefer concise output" (every session) | AI already knows (from `core/communication.md`) | +| "Use fork-first workflow" (every PR) | AI already knows (from `process/code-workflow.md`) | +| "We decided to use the pipeline" (re-explained monthly) | AI already knows (from `decisions/_active.md`) | +| "My sprint focus is X" (repeated across tools) | Every surface reads `active/sprint-focus.md` | +| Start over in each new tool | Start where you left off, everywhere | + +The compound effect is significant. After a month, you've spent maybe 2 hours total writing context. But you've saved dozens of hours of re-explaining, re-deciding, and re-orienting AI tools that should already know you. + +--- + +## What's Next: The Standard That Doesn't Exist Yet + +Today, this is a pattern you implement yourself. But the industry is converging on this problem: + +- **Mem0** raised $24M to solve "AI memory that persists across sessions" +- **Anthropic** added memory to Claude and `CLAUDE.md` per project +- **OpenAI** added Custom Instructions and Memory to ChatGPT +- **Microsoft** ships Copilot personalization and Scout memories +- **Letta** builds git-backed persistent memory for agents +- **Every coding tool** has its own instructions file format + +What's missing is a **shared standard** — an agreement across tools about where personal context lives and how to read/write it. The [Model Context Protocol](https://modelcontextprotocol.io) standardized tool integration; we need the same for user identity. + +No such standard exists today. There's no "vCard for AI preferences," no "iCal for decisions." This is genuinely unoccupied territory. + +Until that standard emerges, a private GitHub repo with structured markdown is the most portable, most universal, most future-proof approach. Every tool speaks git. Every LLM speaks markdown. Every developer has a GitHub account. + +Your second brain is just a `git push` away from every AI surface you use. + +--- + +*Have thoughts on this approach? I'd love to hear how you're solving context portability across AI tools.* + diff --git a/website/blog/media/2026-07-12-portable-personal-context/30-min-timeline.svg b/website/blog/media/2026-07-12-portable-personal-context/30-min-timeline.svg new file mode 100644 index 0000000..5d139b2 --- /dev/null +++ b/website/blog/media/2026-07-12-portable-personal-context/30-min-timeline.svg @@ -0,0 +1,48 @@ + + + + + + 30-Minute Setup + + + + + + + + + + 1 + 5 min + Create repo + + folders + + + + 2 + 15 min + Write identity + role + boundaries + + + + 3 + 25 min + Capture first + 5 decisions + + + + ✓ + 30 min + Connect one + surface + + + 0 min + Done ✓ + + + You don't need to write everything upfront. Start here, evolve naturally. + diff --git a/website/blog/media/2026-07-12-portable-personal-context/architecture.svg b/website/blog/media/2026-07-12-portable-personal-context/architecture.svg new file mode 100644 index 0000000..fd08f66 --- /dev/null +++ b/website/blog/media/2026-07-12-portable-personal-context/architecture.svg @@ -0,0 +1,76 @@ + + + + + + Portable Context: One Repo, Every Surface + + + + 📦 personal-context + Private GitHub Repository + + + 📄 core/expertise.md + 📄 core/boundaries.md + 📄 decisions/_active.md + 📄 process/quality-bar.md + 📄 active/sprint-focus.md + 📄 context.json (index) + + + + + Copilot in + VS Code + reads + writes + + + + Copilot CLI + reads + + + + Microsoft Scout + reads + writes + + + + M365 Copilot + reads via OneDrive + + + + Cloud + Agent + reads via API + + + + + + + + + + + + + + + + + + + + + + + + + Read (all surfaces) + + + Write back (decisions, state) + diff --git a/website/blog/media/2026-07-12-portable-personal-context/before-after.svg b/website/blog/media/2026-07-12-portable-personal-context/before-after.svg new file mode 100644 index 0000000..599f883 --- /dev/null +++ b/website/blog/media/2026-07-12-portable-personal-context/before-after.svg @@ -0,0 +1,94 @@ + + + + + + + + + BEFORE + + + + 👤 + + + + "I prefer concise output..." + + + "I prefer concise output..." + + + "Use fork-first workflow..." + + + "Use fork-first workflow..." + + + "We decided to use pipeline..." + + + "We decided to use pipeline..." + + + ❓ VS Code + ❓ Scout + ❓ CLI + ❓ Claude + ❓ VS Code + ❓ M365 + + + + + + + + + + + Repeating yourself to every tool, every session + + + AFTER + + + + 👤 + + + + + + + + + + + + personal- + context + 📦 repo + + + + + + + + + + ✓ VS Code + ✓ Scout + ✓ CLI + ✓ Claude + ✓ M365 + + + Write once → every surface knows you + + + One-to-one (exhausting) + One-to-many (effortless) + diff --git a/website/blog/media/2026-07-12-portable-personal-context/context-islands.svg b/website/blog/media/2026-07-12-portable-personal-context/context-islands.svg new file mode 100644 index 0000000..533b6f1 --- /dev/null +++ b/website/blog/media/2026-07-12-portable-personal-context/context-islands.svg @@ -0,0 +1,50 @@ + + + + + + Context Islands: Each Surface Is Isolated + + + + + Copilot in + VS Code + .copilot-instructions.md + + + + Copilot CLI + No persistence + + + + Microsoft Scout + me.md + memories DB + + + + M365 Copilot + Graph data (cloud only) + + + + Claude + CLAUDE.md + memory + + + + Cursor + .cursorrules + + + ✕ + ✕ + ✕ + ✕ + ✕ + ✕ + + + Each surface maintains its own isolated context. Switching tools means starting over. + diff --git a/website/blog/media/2026-07-12-portable-personal-context/durability-layers.svg b/website/blog/media/2026-07-12-portable-personal-context/durability-layers.svg new file mode 100644 index 0000000..24e4c28 --- /dev/null +++ b/website/blog/media/2026-07-12-portable-personal-context/durability-layers.svg @@ -0,0 +1,49 @@ + + + + + + Four Layers: Separated by Durability + + + + + + + + + STABLE + VOLATILE + + + + CORE + Identity, Expertise, Boundaries + Changes: Rarely (months/years) + Mutability: Human-only + Example: "I'm a senior dev on Azure SDK docs" + + + + DECISIONS + Settled questions, directives + Changes: Append-only (never edit) + Mutability: Any surface appends + Example: "Use pipeline for namespace files" + + + + PROCESS + Workflows, quality bar, preferences + Changes: Occasionally (weeks/months) + Mutability: Propose via PR + Example: "Branch naming: {type}/{id}-{slug}" + + + + ACTIVE + Sprint focus, current projects + Changes: Frequently (days/weeks) + Mutability: Any surface overwrites + Example: "Sprint 14: Ship auth namespace docs" + diff --git a/website/blog/media/2026-07-12-portable-personal-context/file-scope-comparison.svg b/website/blog/media/2026-07-12-portable-personal-context/file-scope-comparison.svg new file mode 100644 index 0000000..c44041b --- /dev/null +++ b/website/blog/media/2026-07-12-portable-personal-context/file-scope-comparison.svg @@ -0,0 +1,41 @@ + + + + + + Scope Comparison: Per-Tool Files vs. Personal Context + + + + Personal Context Repo + All projects • All tools • All time + + + + copilot-instructions.md + One repo • One tool family + + + + .cursorrules + CLAUDE.md + One project • One tool + + + + + + + + + BROADER + NARROWER + + + + Per-tool (one project, one tool) + + Repo-level (one repo, one family) + + Personal (all projects, all tools) + diff --git a/website/blog/media/2026-07-12-portable-personal-context/persona-hierarchy.svg b/website/blog/media/2026-07-12-portable-personal-context/persona-hierarchy.svg new file mode 100644 index 0000000..d0ad424 --- /dev/null +++ b/website/blog/media/2026-07-12-portable-personal-context/persona-hierarchy.svg @@ -0,0 +1,57 @@ + + + + + + Personal Context → Process → Skills → Agents + Knowledge flows downward. The person is the root. + + + + YOU — Personal Context + Expertise • Boundaries • Decisions • Quality Bar • Communication Style + Scope: Everything you do, across all tools, all time + Example: "I require surgical edits only" • "Never auto-push to upstream" • "Use tabs for multi-language" + + + + + + + + PROCESS — Documented Workflows + Content workflow • Code workflow • Review standards • Tool preferences + Scope: How you do a category of work, refined over time + Example: "To write content: fork → branch → draft → review cycle → PR → merge" + + + + + + + + SKILLS — Formalized Recipes + pr-review • session-summary • freshness-analysis • monthly-report + Scope: One repeatable task, step-by-step + Example: "Step 1: Check metadata. Step 2: Validate links. Step 3: Run style check..." + + + + + + + + AGENTS — Execution Personas + CDA Cortex • Code Reviewer • Project Coordinator + Scope: One role, one surface, using assigned skills + + + Stable + (years) + + Volatile + (weeks) + + + Knowledge flows down → + diff --git a/website/blog/media/2026-07-12-portable-personal-context/personalization-silos.svg b/website/blog/media/2026-07-12-portable-personal-context/personalization-silos.svg new file mode 100644 index 0000000..fcd5336 --- /dev/null +++ b/website/blog/media/2026-07-12-portable-personal-context/personalization-silos.svg @@ -0,0 +1,76 @@ + + + + + + Personalization Exists — But It's Locked to Each Surface + + + + M365 Copilot + ✓ Custom instructions + ✓ Work profile + ✓ Saved memories + ✓ Chat history + + 🔒 + + + + ChatGPT + ✓ Custom instructions + ✓ Memory (auto) + ✓ Chat history + 🔒 + + + + Claude + ✓ CLAUDE.md (user-level) + ✓ Project instructions + ✓ Auto-memory + 🔒 + + + + Cursor + ✓ Rules + ✓ .cursorrules (legacy) + 🔒 + + + + ✕ + + ✕ + + ✕ + + + + ▼ With Personal Context Repo ▼ + + + + 📦 personal-context repo + One source • Every surface reads it • You own it + 🔓 + + + + + + + + + M365 + ChatGPT + Claude + Cursor + + + ✓ + ✓ + ✓ + ✓ + diff --git a/website/blog/media/2026-07-12-portable-personal-context/priority-stack.svg b/website/blog/media/2026-07-12-portable-personal-context/priority-stack.svg new file mode 100644 index 0000000..fc0a91e --- /dev/null +++ b/website/blog/media/2026-07-12-portable-personal-context/priority-stack.svg @@ -0,0 +1,45 @@ + + + + + + Priority Stack: When Things Conflict + + + + + + active/* + Informational. Not authoritative. + ④ + + + + process/* + Follow unless user overrides in-session. + ③ + + + + decisions/_active.md + Settled questions. Don't re-ask. + ② + + + + core/boundaries.md + ALWAYS wins. Non-negotiable. + ① + + + + + + + + + PRIORITY + + + Higher layers always override lower layers in case of conflict. + diff --git a/website/blog/media/2026-07-12-portable-personal-context/retrieval-flow.svg b/website/blog/media/2026-07-12-portable-personal-context/retrieval-flow.svg new file mode 100644 index 0000000..073a8b3 --- /dev/null +++ b/website/blog/media/2026-07-12-portable-personal-context/retrieval-flow.svg @@ -0,0 +1,59 @@ + + + + + + Selective Retrieval: Load Only What's Relevant + + + + 1. Read context.json + < 1KB manifest + + + + + + + + + + + + 2. Always load + boundaries.md (~200w) + communication.md (~200w) + + + + + + + 3. Classify task + "reviewing a PR" → + match to load_by_task + + + + + + + 4. Load task files + quality-bar.md (~150w) + pr-standards.md (~150w) + + + + Total Context Injected + ~1,200 tokens + (not 25,000 tokens from dumping everything) + + + Full repo dump: + + ~25K tokens + + Selective retrieval: + + ~1.2K tokens (95% smaller) + diff --git a/website/blog/media/2026-07-12-portable-personal-context/universal-transport.svg b/website/blog/media/2026-07-12-portable-personal-context/universal-transport.svg new file mode 100644 index 0000000..a7cc62e --- /dev/null +++ b/website/blog/media/2026-07-12-portable-personal-context/universal-transport.svg @@ -0,0 +1,35 @@ + + + + + + + 📝 + Markdown + Every LLM reads it + natively + + + + + + + + ⚙️ + GitHub + Every dev tool + authenticates with it + + + = + + + + 🌐 + Universal + Portability + No new APIs + No vendor lock-in + + + The simplest possible architecture: files that every tool already knows how to read, on a platform they already connect to. + From 82752bbc509265797150d087400c39b59dc76742 Mon Sep 17 00:00:00 2001 From: diberry <41597107+diberry@users.noreply.github.com> Date: Thu, 9 Jul 2026 06:08:35 -0700 Subject: [PATCH 2/7] updated image --- .../2026-07-12-portable-personal-context/architecture.svg | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/website/blog/media/2026-07-12-portable-personal-context/architecture.svg b/website/blog/media/2026-07-12-portable-personal-context/architecture.svg index fd08f66..91720c2 100644 --- a/website/blog/media/2026-07-12-portable-personal-context/architecture.svg +++ b/website/blog/media/2026-07-12-portable-personal-context/architecture.svg @@ -28,7 +28,7 @@ Copilot CLI - reads + reads + writes @@ -63,8 +63,9 @@ - + + From 0afbaf5d4bf6a81fcc0406d4c2ffdd68b8ace8ea Mon Sep 17 00:00:00 2001 From: Dina Berry Date: Thu, 9 Jul 2026 08:18:47 -0700 Subject: [PATCH 3/7] Add context-vs-memory + hosted-service architecture sections Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- .../2026-07-12-portable-personal-context.md | 160 +++++++++++++++--- 1 file changed, 136 insertions(+), 24 deletions(-) diff --git a/website/blog/2026-07-12-portable-personal-context.md b/website/blog/2026-07-12-portable-personal-context.md index b82d2ef..bc7ab10 100644 --- a/website/blog/2026-07-12-portable-personal-context.md +++ b/website/blog/2026-07-12-portable-personal-context.md @@ -15,6 +15,9 @@ tags: - mcp - productivity - architecture + - personal context vs memory + - mcp facade + - context broker keywords: - portable personal context - ai second brain @@ -26,15 +29,19 @@ keywords: - model context protocol - portable ai memory - developer productivity ai + - personal context vs memory + - context broker + - prompt injection exfiltration + - mcp facade --- -Every developer I know uses multiple AI surfaces daily. GitHub Copilot in VS Code for coding. Copilot CLI for terminal workflows. Microsoft 365 Copilot for email and meetings. Microsoft Scout for desktop orchestration. Maybe Claude, ChatGPT, or Cursor on the side. - -The problem? **Every time you switch surfaces, you start over.** The AI that just helped you plan a feature in Scout has no idea you exist when you open VS Code. The Copilot CLI that helped you craft a git command doesn't know your branch naming conventions that you already taught VS Code. - -Your context — who you are, what you're working on, how you like to work, and what you've already decided — is trapped in whichever tool you happened to tell it to. - -This post describes how to fix that with a **portable personal context layer**: a structured set of files in a GitHub repo that any AI surface can read, giving every tool your "second brain" from the first interaction. +Every developer I know uses multiple AI surfaces daily. GitHub Copilot in VS Code for coding. Copilot CLI for terminal workflows. Microsoft 365 Copilot for email and meetings. Microsoft Scout for desktop orchestration. Maybe Claude, ChatGPT, or Cursor on the side. + +The problem? **Every time you switch surfaces, you start over.** The AI that just helped you plan a feature in Scout has no idea you exist when you open VS Code. The Copilot CLI that helped you craft a git command doesn't know your branch naming conventions that you already taught VS Code. + +Your context — who you are, what you're working on, how you like to work, and what you've already decided — is trapped in whichever tool you happened to tell it to. + +This post **proposes** a fix: a **portable personal context layer** — a structured set of files in a GitHub repo that any AI surface *could* read, giving every tool your "second brain" from the first interaction. Today, no single vendor supports this end-to-end — not even across two surfaces from the same maker. This is a design for what *should* exist, and an invitation to tool builders to make it real. --- @@ -168,6 +175,44 @@ Mem0's own research says file-based memory "works beautifully for ≤200 static --- +## Personal Context Is Not Memory + +Before going further, one distinction that tripped me up when I started — and trips up half the tools in this space: **personal context is not memory.** They feel similar, they overlap, and plenty of products blur them on purpose. Architecturally, though, they're two different animals, and conflating them is exactly why so many "memory" features feel both magical and untrustworthy. + +Here's the one-line version: + +> **Context is your constitution. Memory is your diary.** + +Context is what you *ratified* — declared, curated, authoritative. Memory is what was *observed* — accreted, evidentiary, a byproduct of use. + +| | Personal Context | Memory | +|---|---|---| +| **Origin** | Authored intentionally | Accumulated automatically | +| **Nature** | Curated / declared | Accreted / observed | +| **Authority** | Authoritative ("this is the rule") | Evidentiary ("this is what happened") | +| **Example** | "My branch naming convention is `{type}/{id}-{slug}`" | "Last Tuesday you renamed a branch to `wip-2`" | +| **Volume** | Small, deliberate (~50-150 facts) | High-volume, ever-growing | +| **Governance** | Human-reviewed | Auto-captured | + +They aren't rivals — they're two ends of a **promotion pipeline**: + +``` +observation → candidate → [ratification gate] → context + (memory) (proposed) (a human decision) (canonical) +``` + +Memory is the raw feed. Context is the reviewed, canonical output. The gate in the middle — an explicit human decision — is the whole point. "You renamed a branch to `wip-2` last week" is an observation; it only becomes "my branch naming convention is X" when *I* say so. + +That distinction has real architectural consequences: + +- **Different stores.** Memory wants a high-volume append log optimized for recall. Context wants a small, curated, versioned set — exactly the git repo above. +- **Different precedence.** When they conflict, **context outranks memory.** The constitution beats the diary. If memory "remembers" you pushed to `main` once, that never overrides the boundary that says you don't. +- **Different retrieval, governance, and security.** Context is load-always and trusted; memory is search-when-relevant and treated as evidence, not instruction. + +Why does this matter for the thesis of this post? Because the portable layer I'm proposing is **context, not memory.** Tools like Mem0, Claude memory, and ChatGPT memory solve the *observe-and-recall* half — and they solve it well. What none of them give you is a portable, authored, authoritative layer you *ratify*. They observe; they don't ratify. That gap is the thing this repo pattern is trying to fill. + +--- + ## The Insight: LLMs Already Speak Markdown The solution isn't a complex sync service, a vector database, or a new protocol. It's simpler than that. @@ -393,10 +438,12 @@ Now every other surface picks it up on next read. Decision made in Scout? VS Cod --- -## Connecting Each Surface - -### GitHub Copilot in VS Code - +## Connecting Each Surface (Proposed Integrations) + +The specifics below are illustrative — some work today with manual setup, others would require tool vendors to add support. The point is that the *mechanism* is simple in every case: read a file, inject as context. + +### GitHub Copilot in VS Code + In your user-level `settings.json`: ```json @@ -515,26 +562,91 @@ The compound effect is significant. After a month, you've spent maybe 2 hours to --- -## What's Next: The Standard That Doesn't Exist Yet +## Beyond the Repo: When a Service Makes Sense + +Everything above is deliberately the **floor** — the simplest thing that could possibly work. A flat git repo of markdown is the whole point: no server, no vendor, no API key. So when *would* you reach for something more? + +The honest answer: when a flat repo can't enforce what you need. A git repo hands the whole file to anyone who can read it. A **hosted service** can hand back only the slice the caller is cleared to see. That's the line. + +### What a hosted version would buy you -Today, this is a pattern you implement yourself. But the industry is converging on this problem: +- **Server-side redaction by trust tier.** Split your context into `public` / `work` / `private` tiers and enforce the split *at the server*, not the client. The Copilot CLI on a work machine sees your work tier; a public-facing agent never sees your private tier at all. A flat repo can't do this — anyone with clone access gets everything. +- **Audit and access control tied to real identity.** Who read your context, when, from which surface — logged. Per-surface access bound to an actual identity instead of an honor system. +- **The precedence stack, enforced centrally.** The priority stack from earlier ("context outranks memory," boundaries always win) now runs server-side, so every consumer gets the same resolved answer instead of each surface re-implementing it. -- **Mem0** raised $24M to solve "AI memory that persists across sessions" -- **Anthropic** added memory to Claude and `CLAUDE.md` per project -- **OpenAI** added Custom Instructions and Memory to ChatGPT -- **Microsoft** ships Copilot personalization and Scout memories -- **Letta** builds git-backed persistent memory for agents -- **Every coding tool** has its own instructions file format +### The key design call: contract vs. transport -What's missing is a **shared standard** — an agreement across tools about where personal context lives and how to read/write it. The [Model Context Protocol](https://modelcontextprotocol.io) standardized tool integration; we need the same for user identity. +If you build this, the mistake to avoid is making **MCP the canonical contract.** MCP is a fast-moving adapter for agentic surfaces — the right *transport*, the wrong thing to bet your data model on. -No such standard exists today. There's no "vCard for AI preferences," no "iCal for decisions." This is genuinely unoccupied territory. +Build a **REST/OpenAPI service as the source of truth**, and expose **MCP as a thin, swappable facade** over it. + +> **Build the contract you can't afford to rewrite in REST; expose MCP as a facade you can afford to throw away.** + +The REST contract is the thing you version carefully and support for years. The MCP facade is a convenience layer you can rewrite — or swap for the next protocol — without touching your data model. + +### A plausible stack (an example, not a mandate) + +| Concern | Example choice | Why | +|---|---|---| +| REST + MCP server | Azure Container Apps | Scales to zero, no cluster to run | +| Storage | Cosmos DB serverless | Change feed gives you versioning + audit almost for free | +| Secrets | Key Vault | Keep keys out of the app | +| Auth / identity | Entra ID app registration + managed identity | Real identity, no shared secrets | +| Output scanning (later) | API Management + Azure AI Content Safety / Prompt Shields | Add when you need it, not on day one | -Until that standard emerges, a private GitHub repo with structured markdown is the most portable, most universal, most future-proof approach. Every tool speaks git. Every LLM speaks markdown. Every developer has a GitHub account. +> **MCP is the transport; Entra is the identity.** -Your second brain is just a `git push` away from every AI surface you use. +### What the service actually is: a context broker + +Strip away the stack and the service does four jobs: + +1. **Merge** — combine the layers (core, decisions, process, active) into one view. +2. **Priority** — apply the precedence stack so conflicts resolve deterministically. +3. **Redaction** — return only the caller's trust tier. +4. **Output scanning** — catch a prompt-injection attempt trying to exfiltrate a tier the caller shouldn't see. + +That fourth job names the dominant threat honestly: **prompt-injection exfiltration.** A malicious doc or tool convinces the agent to read your private context and leak it. Server-side tier redaction is the mitigation a flat git repo simply can't offer — the private tier never leaves the server in the first place. + +### Even a service still hits the standards wall + +Here's the deflating part, and it reinforces where this post is headed. Even with a hosted service, consumption stays uneven: + +| Surface | Talks to a remote MCP server? | +|---|---| +| VS Code / Copilot CLI / Foundry | Yes — directly | +| Claude / ChatGPT | Only via an `mcp-remote` proxy | +| Microsoft 365 Copilot | No — it wants Graph connectors / declarative agents | + +So the grown-up version doesn't escape the "no universal standard" problem from the next section — it runs straight into the same wall, just from a more capable starting point. + +And to be clear about scope: for one developer, the repo is usually enough. The service earns its complexity only when you have **multiple trust tiers, multiple consumers, or a real injection threat model.** Short of that, `git push` is the architecture. --- -*Have thoughts on this approach? I'd love to hear how you're solving context portability across AI tools.* +## What's Next: The Standard That Doesn't Exist Yet + +This post is a proposal, not a product announcement. Today, **none of this works automatically** — not even across two Copilot surfaces from the same company. Each tool reads its own context files, in its own format, from its own location. + +But the industry is converging on the problem: + +- **Mem0** raised $24M to solve "AI memory that persists across sessions" +- **Anthropic** added memory to Claude and `CLAUDE.md` per project +- **OpenAI** added Custom Instructions and Memory to ChatGPT +- **Microsoft** ships Copilot personalization and Scout memories +- **Letta** builds git-backed persistent memory for agents +- **Every coding tool** has its own instructions file format + +What's missing is a **shared standard** — an agreement across tools about where personal context lives and how to read/write it. The [Model Context Protocol](https://modelcontextprotocol.io) standardized tool integration; we need the same for user identity. + +No such standard exists today. There's no "vCard for AI preferences," no "iCal for decisions." This is genuinely unoccupied territory. + +The GitHub repo approach described here is a bet: that structured markdown in a well-known location, with a manifest for selective retrieval, is the simplest architecture that *could* work — if tool builders agreed to read it. Every tool speaks git. Every LLM speaks markdown. Every developer has a GitHub account. + +**The ask to tool builders:** Add a `$COPILOT_CONTEXT_PATH` or equivalent. Let users point to a directory of markdown files that your surface reads as additional context. That's the entire integration. The portability follows naturally. + +Your second brain is just a `git push` away from every AI surface you use — once the surfaces agree to look for it. + +--- + +*This is a proposal and a conversation starter. Have thoughts? Disagree with the approach? Building something similar? I'd love to hear how you're thinking about context portability across AI tools.* From f31401162febefacc723c7aa7ef74c638b7d05d3 Mon Sep 17 00:00:00 2001 From: diberry <41597107+diberry@users.noreply.github.com> Date: Thu, 9 Jul 2026 16:54:57 +0100 Subject: [PATCH 4/7] Add SVGs for context-vs-memory, context-broker, and standards-convergence sections Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- .../2026-07-12-portable-personal-context.md | 16 +++- .../context-broker.svg | 93 +++++++++++++++++++ .../context-vs-memory.svg | 73 +++++++++++++++ .../standards-convergence.svg | 74 +++++++++++++++ 4 files changed, 251 insertions(+), 5 deletions(-) create mode 100644 website/blog/media/2026-07-12-portable-personal-context/context-broker.svg create mode 100644 website/blog/media/2026-07-12-portable-personal-context/context-vs-memory.svg create mode 100644 website/blog/media/2026-07-12-portable-personal-context/standards-convergence.svg diff --git a/website/blog/2026-07-12-portable-personal-context.md b/website/blog/2026-07-12-portable-personal-context.md index bc7ab10..c7923fb 100644 --- a/website/blog/2026-07-12-portable-personal-context.md +++ b/website/blog/2026-07-12-portable-personal-context.md @@ -175,8 +175,10 @@ Mem0's own research says file-based memory "works beautifully for ≤200 static --- -## Personal Context Is Not Memory - +## Personal Context Is Not Memory + +![Context vs Memory promotion pipeline](./media/2026-07-12-portable-personal-context/context-vs-memory.svg) + Before going further, one distinction that tripped me up when I started — and trips up half the tools in this space: **personal context is not memory.** They feel similar, they overlap, and plenty of products blur them on purpose. Architecturally, though, they're two different animals, and conflating them is exactly why so many "memory" features feel both magical and untrustworthy. Here's the one-line version: @@ -272,7 +274,7 @@ Not all context is equal. The key insight is separating by **durability** — ho |-------|-----------|-----------|---------| | **Core** | Months/years | Human-only | "I'm a senior developer on the Azure SDK docs team" | | **Decisions** | Permanent (append-only) | Any surface appends | "Use generation pipeline for MCP namespace files" | -| **Process** | Weeks/months | Propose via PR | "Branch naming: {type}/{id}-{slug}" | +| **Process** | Weeks/months | Propose via PR | "Branch naming: `{type}/{id}-{slug}`" | | **Active** | Days/weeks | Any surface overwrites | "Sprint focus: Ship auth-flow feature" | --- @@ -562,8 +564,10 @@ The compound effect is significant. After a month, you've spent maybe 2 hours to --- -## Beyond the Repo: When a Service Makes Sense - +## Beyond the Repo: When a Service Makes Sense + +![Context broker architecture with MCP facade and trust tiers](./media/2026-07-12-portable-personal-context/context-broker.svg) + Everything above is deliberately the **floor** — the simplest thing that could possibly work. A flat git repo of markdown is the whole point: no server, no vendor, no API key. So when *would* you reach for something more? The honest answer: when a flat repo can't enforce what you need. A git repo hands the whole file to anyone who can read it. A **hosted service** can hand back only the slice the caller is cleared to see. That's the line. @@ -625,6 +629,8 @@ And to be clear about scope: for one developer, the repo is usually enough. The ## What's Next: The Standard That Doesn't Exist Yet +![Convergence diagram showing vendors approaching a missing standard](./media/2026-07-12-portable-personal-context/standards-convergence.svg) + This post is a proposal, not a product announcement. Today, **none of this works automatically** — not even across two Copilot surfaces from the same company. Each tool reads its own context files, in its own format, from its own location. But the industry is converging on the problem: diff --git a/website/blog/media/2026-07-12-portable-personal-context/context-broker.svg b/website/blog/media/2026-07-12-portable-personal-context/context-broker.svg new file mode 100644 index 0000000..304bce2 --- /dev/null +++ b/website/blog/media/2026-07-12-portable-personal-context/context-broker.svg @@ -0,0 +1,93 @@ + + + + + + Context Broker: From Flat Repo to Hosted Service + + + CONTEXT LAYERS + + + 📄 core/* + + + 📄 decisions/* + + + 📄 process/* + + + 📄 active/* + + + + + + + + + + + + + + + + + + + Context Broker + REST/OpenAPI service (source of truth) + + + + 1. Merge + Combine all layers + + + 2. Priority + Resolve conflicts + + + 3. Redact + Filter by trust tier + + + 4. Scan + Block exfiltration + + + + MCP Facade + (thin, swappable) + + + + VS Code / CLI / Foundry + + + Claude / ChatGPT + + + + + + TRUST TIERS (server-enforced redaction) + + + 🟢 Public + Role, expertise, preferences + + + 🟡 Work + Sprint focus, decisions, process + + + 🔴 Private + Boundaries, sensitive decisions + + + + Build the contract you can't rewrite in REST. Expose MCP as a facade you can throw away. + diff --git a/website/blog/media/2026-07-12-portable-personal-context/context-vs-memory.svg b/website/blog/media/2026-07-12-portable-personal-context/context-vs-memory.svg new file mode 100644 index 0000000..aa21893 --- /dev/null +++ b/website/blog/media/2026-07-12-portable-personal-context/context-vs-memory.svg @@ -0,0 +1,73 @@ + + + + + + Context vs Memory: The Promotion Pipeline + + + + + + + Observation + (Memory) + "You renamed a branch + to wip-2 last Tuesday" + + + + + + + + + + + + Candidate + (Proposed) + "Should branch naming + be type/id-slug?" + + + + + + + ⚡ + Ratification + Gate + Human decision: + "Yes, that's the rule" + + + + + + + Context + (Canonical) + "Branch naming is + type/id-slug. Always." + + + + + 📓 Memory (Diary) + • Auto-captured, high-volume + • Evidentiary, not authoritative + • Search-when-relevant + • Loses to context when they conflict + + + + 📜 Context (Constitution) + • Human-authored, small (<150 facts) + • Authoritative, versioned in git + • Load-always, trusted + • Outranks memory. Always wins. + + + Memory is the raw feed. Context is the reviewed, canonical output. The gate is the whole point. + diff --git a/website/blog/media/2026-07-12-portable-personal-context/standards-convergence.svg b/website/blog/media/2026-07-12-portable-personal-context/standards-convergence.svg new file mode 100644 index 0000000..a812dcd --- /dev/null +++ b/website/blog/media/2026-07-12-portable-personal-context/standards-convergence.svg @@ -0,0 +1,74 @@ + + + + + + The Standard That Doesn't Exist Yet + + + TODAY: Everyone's Own Format + + + + GitHub Copilot + copilot-instructions.md + + + Anthropic + CLAUDE.md + memory + + + OpenAI + Custom Instructions + + + Microsoft + Scout memories + M365 + + + Cursor + .cursorrules + + + Mem0 + Cloud vector API + + + + + + + + + + + + + + + + + + ? + Shared Standard + "vCard for AI preferences" + Doesn't exist yet + + + + + + Universal Context + + ✓ Structured markdown + ✓ Well-known location + ✓ Selective retrieval + ✓ Git-backed versioning + ✓ Every surface reads it + + + + The Ask: $COPILOT_CONTEXT_PATH + Let users point to a directory of markdown. Read it as context. That's the entire integration. + Every tool speaks git. Every LLM speaks markdown. Every developer has GitHub. + From 55b91fd9f7afdd6dae080ee13de4e230fbd2d9b2 Mon Sep 17 00:00:00 2001 From: diberry <41597107+diberry@users.noreply.github.com> Date: Thu, 9 Jul 2026 16:58:50 +0100 Subject: [PATCH 5/7] Remove Azure stack table from hosted-service section Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- website/blog/2026-07-12-portable-personal-context.md | 12 ------------ 1 file changed, 12 deletions(-) diff --git a/website/blog/2026-07-12-portable-personal-context.md b/website/blog/2026-07-12-portable-personal-context.md index c7923fb..fbe0d0e 100644 --- a/website/blog/2026-07-12-portable-personal-context.md +++ b/website/blog/2026-07-12-portable-personal-context.md @@ -588,18 +588,6 @@ Build a **REST/OpenAPI service as the source of truth**, and expose **MCP as a t The REST contract is the thing you version carefully and support for years. The MCP facade is a convenience layer you can rewrite — or swap for the next protocol — without touching your data model. -### A plausible stack (an example, not a mandate) - -| Concern | Example choice | Why | -|---|---|---| -| REST + MCP server | Azure Container Apps | Scales to zero, no cluster to run | -| Storage | Cosmos DB serverless | Change feed gives you versioning + audit almost for free | -| Secrets | Key Vault | Keep keys out of the app | -| Auth / identity | Entra ID app registration + managed identity | Real identity, no shared secrets | -| Output scanning (later) | API Management + Azure AI Content Safety / Prompt Shields | Add when you need it, not on day one | - -> **MCP is the transport; Entra is the identity.** - ### What the service actually is: a context broker Strip away the stack and the service does four jobs: From 307af75684589689e6313c8399cdf3323824f4f1 Mon Sep 17 00:00:00 2001 From: Dina Berry Date: Thu, 9 Jul 2026 09:46:00 -0700 Subject: [PATCH 6/7] Reframe to AI client surfaces, tighten prose, move release to 2026-07-10 - Broaden framing from Copilot-specific to vendor-neutral AI client surfaces - Tighten prose ~30% against personal voice rubric (no hype, evidence-backed) - Fix MDX render crash from bare {type} braces - Rename post + media folder from 2026-07-12 to 2026-07-10 for tomorrow's release Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- ...> 2026-07-10-portable-personal-context.md} | 1144 ++++++++--------- .../30-min-timeline.svg | 0 .../architecture.svg | 0 .../before-after.svg | 0 .../context-broker.svg | 0 .../context-islands.svg | 0 .../context-vs-memory.svg | 0 .../durability-layers.svg | 0 .../file-scope-comparison.svg | 0 .../persona-hierarchy.svg | 0 .../personalization-silos.svg | 0 .../priority-stack.svg | 0 .../retrieval-flow.svg | 0 .../standards-convergence.svg | 0 .../universal-transport.svg | 0 15 files changed, 546 insertions(+), 598 deletions(-) rename website/blog/{2026-07-12-portable-personal-context.md => 2026-07-10-portable-personal-context.md} (50%) rename website/blog/media/{2026-07-12-portable-personal-context => 2026-07-10-portable-personal-context}/30-min-timeline.svg (100%) rename website/blog/media/{2026-07-12-portable-personal-context => 2026-07-10-portable-personal-context}/architecture.svg (100%) rename website/blog/media/{2026-07-12-portable-personal-context => 2026-07-10-portable-personal-context}/before-after.svg (100%) rename website/blog/media/{2026-07-12-portable-personal-context => 2026-07-10-portable-personal-context}/context-broker.svg (100%) rename website/blog/media/{2026-07-12-portable-personal-context => 2026-07-10-portable-personal-context}/context-islands.svg (100%) rename website/blog/media/{2026-07-12-portable-personal-context => 2026-07-10-portable-personal-context}/context-vs-memory.svg (100%) rename website/blog/media/{2026-07-12-portable-personal-context => 2026-07-10-portable-personal-context}/durability-layers.svg (100%) rename website/blog/media/{2026-07-12-portable-personal-context => 2026-07-10-portable-personal-context}/file-scope-comparison.svg (100%) rename website/blog/media/{2026-07-12-portable-personal-context => 2026-07-10-portable-personal-context}/persona-hierarchy.svg (100%) rename website/blog/media/{2026-07-12-portable-personal-context => 2026-07-10-portable-personal-context}/personalization-silos.svg (100%) rename website/blog/media/{2026-07-12-portable-personal-context => 2026-07-10-portable-personal-context}/priority-stack.svg (100%) rename website/blog/media/{2026-07-12-portable-personal-context => 2026-07-10-portable-personal-context}/retrieval-flow.svg (100%) rename website/blog/media/{2026-07-12-portable-personal-context => 2026-07-10-portable-personal-context}/standards-convergence.svg (100%) rename website/blog/media/{2026-07-12-portable-personal-context => 2026-07-10-portable-personal-context}/universal-transport.svg (100%) diff --git a/website/blog/2026-07-12-portable-personal-context.md b/website/blog/2026-07-10-portable-personal-context.md similarity index 50% rename from website/blog/2026-07-12-portable-personal-context.md rename to website/blog/2026-07-10-portable-personal-context.md index fbe0d0e..207eeee 100644 --- a/website/blog/2026-07-12-portable-personal-context.md +++ b/website/blog/2026-07-10-portable-personal-context.md @@ -1,11 +1,11 @@ --- -slug: /2026-07-12-portable-personal-context -date: 2026-07-12 -canonical_url: https://dfberry.github.io/blog/2026-07-12-portable-personal-context +slug: /2026-07-10-portable-personal-context +date: 2026-07-10 +canonical_url: https://dfberry.github.io/blog/2026-07-10-portable-personal-context custom_edit_url: null sidebar_label: "2026.07.12 Portable context" -title: "Your AI Second Brain: Carry Context Across Every Copilot Surface" -description: "Build a portable personal context layer with markdown and GitHub so Copilot, CLI, Scout, and other AI tools can share your preferences, decisions, and active work." +title: "Portable Personal Context Across AI Client Surfaces" +description: "Build a cross-tool personal context layer with markdown and GitHub so AI client surfaces like Copilot, Claude, Cursor, ChatGPT, M365, Scout, and CLI can share your preferences, decisions, and active work." tags: - ai - copilot @@ -20,627 +20,575 @@ tags: - context broker keywords: - portable personal context - - ai second brain - - copilot context - - cross-surface copilot + - ai client surfaces + - cross-tool ai context + - ai shared context source - ai memory markdown - github personal context repo - decisions ledger - model context protocol - portable ai memory + - copilot context + - cross-surface copilot - developer productivity ai - personal context vs memory - context broker - prompt injection exfiltration - mcp facade ---- - -Every developer I know uses multiple AI surfaces daily. GitHub Copilot in VS Code for coding. Copilot CLI for terminal workflows. Microsoft 365 Copilot for email and meetings. Microsoft Scout for desktop orchestration. Maybe Claude, ChatGPT, or Cursor on the side. - -The problem? **Every time you switch surfaces, you start over.** The AI that just helped you plan a feature in Scout has no idea you exist when you open VS Code. The Copilot CLI that helped you craft a git command doesn't know your branch naming conventions that you already taught VS Code. - -Your context — who you are, what you're working on, how you like to work, and what you've already decided — is trapped in whichever tool you happened to tell it to. - -This post **proposes** a fix: a **portable personal context layer** — a structured set of files in a GitHub repo that any AI surface *could* read, giving every tool your "second brain" from the first interaction. Today, no single vendor supports this end-to-end — not even across two surfaces from the same maker. This is a design for what *should* exist, and an invitation to tool builders to make it real. - ---- - -## The Problem: Context Islands - -![Context islands diagram showing isolated AI surfaces](./media/2026-07-12-portable-personal-context/context-islands.svg) - -Here's what context fragmentation looks like in practice: - -| Surface | What it knows about you | Where that knowledge lives | -|---------|------------------------|---------------------------| -| **Copilot in VS Code** | `.github/copilot-instructions.md` in current repo | Per-repo, per-machine | -| **Copilot CLI** | Nothing persistent between sessions | Ephemeral | -| **Microsoft 365 Copilot** | Your M365 Graph data (emails, calendar) | Cloud, not exportable | -| **Microsoft Scout** | Memories, preferences, profile | Local app state | -| **Claude** | `CLAUDE.md` per project, memory | Per-project file + cloud memory | -| **Cursor** | `.cursorrules` per project | Per-project file | - -Notice the pattern: every tool has invented its own format for "things to know about the user," and none of them talk to each other. - -The result: -- You repeat preferences in every tool ("I prefer concise output," "use TypeScript," "don't auto-push to main") -- Decisions made in one surface are invisible to others -- Your expertise and boundaries are only known where you've explicitly stated them -- Switching tools feels like introducing yourself to a new coworker every time - ---- - -## You Already Know What the Solution Feels Like - -If you've set up **Custom Instructions** in M365 Copilot, **Memory** in ChatGPT, or **CLAUDE.md** in Claude — you already know what personal context feels like. You've experienced the difference between an AI that knows you and one that doesn't. - -![Personalization features exist in every tool but are locked to that tool](./media/2026-07-12-portable-personal-context/personalization-silos.svg) - -| Built-in Feature | What it does | The problem | -|---|---|---| -| **M365 Copilot: Custom instructions** | "Be concise, use tables" | Doesn't reach VS Code or CLI | -| **M365 Copilot: Work profile** | Your role, org, skills | Locked in Microsoft Graph | -| **M365 Copilot: Saved memories** | Facts remembered between sessions | Only M365 Copilot sees them | -| **ChatGPT: Memory** | Auto-extracted facts about you | Only ChatGPT sees them | -| **Claude: CLAUDE.md** | Per-project instructions | Only Claude Code sees them | -| **Cursor: Rules** | Coding preferences | Only Cursor sees them | - -Every tool has built its own personalization silo. **Personal context is personalization that travels.** - -``` -Today: - M365 Copilot → knows you like concise output - VS Code Copilot → doesn't know (asks again) - Copilot CLI → doesn't know (asks again) - Scout → has its own separate copy - Claude → has its own separate copy - -With portable personal context: - All surfaces → read from the same source → know you immediately -``` - ---- - -## Why Not Just Use Those Existing Features? - -| | Built-in Personalization | Portable Context | -|---|---|---| -| **Portability** | One surface only | Every surface | -| **Transparency** | Opaque ("View work data") | Human-readable markdown | -| **Exportability** | Can't export | `git clone` anywhere | -| **Versioning** | No history | Full git history | -| **Control** | Platform decides format | You decide format | -| **Decisions** | No structured log | Append-only ledger | -| **Auto-extraction** | Yes (convenient) | Manual (precise) | - -They're complementary. Use built-in personalization where it exists. Use portable context as the canonical source that stays consistent across *everything*. - ---- - -## Why Not CLAUDE.md, copilot-instructions, or .cursorrules? - -Those are **instructions TO the AI** scoped to one project. Personal context is **information ABOUT you** that spans all projects and tools. - -![Scope comparison showing per-tool files as narrow vs personal context as universal](./media/2026-07-12-portable-personal-context/file-scope-comparison.svg) - -``` -.github/copilot-instructions.md → "In this repo, use ESM imports" -personal-context/process/... → "I always prefer ESM over CommonJS" -``` - -The repo-level file says how to work in *that codebase*. Personal context says how to work with *you*. - ---- - -## Why Not Just an Agent or Skill? - -This is the subtlest distinction. Agents and skills are scoped to tasks. Personal context is scoped to **you as a person**. - -![Persona hierarchy showing person above process above skills above agents](./media/2026-07-12-portable-personal-context/persona-hierarchy.svg) - -| | Personal Context | Agent (agent.md) | Skill (SKILL.md) | -|---|---|---|---| -| **Answers** | "Who is this person?" | "How should I behave?" | "How do I do this task?" | -| **Scope** | Everything you do | One role or surface | One repeatable procedure | -| **Lifespan** | Years (grows with you) | Months (evolves with tooling) | Weeks (refined per use) | -| **Portability** | Every surface | One surface | Some surfaces | - -Knowledge flows downward: **person → process → skill → agent**. - -1. You learn something → it becomes **expertise** (personal context) -2. You repeat a process → it becomes a **workflow** (personal context) -3. You formalize the workflow → it becomes a **skill** (SKILL.md) -4. You assign skills to a persona → it becomes an **agent** (agent.md) - -Personal context is the root. Agents and skills are leaves that grow from it. Without personal context, every agent is generic — it doesn't know YOUR quality bar, YOUR boundaries, YOUR past decisions. - ---- - -## Why Not Mem0 or a Cloud Memory Service? - -[Mem0](https://mem0.ai) is a cloud API for persistent AI memory. It solves the same problem but with a different philosophy: - -| | Mem0 (Cloud) | Personal Context Repo | -|---|---|---| -| **Architecture** | Hosted API service | Local-first (files in git) | -| **Data ownership** | Third-party hosted | You own it (your GitHub) | -| **Works offline** | No | Yes | -| **Vendor dependency** | Yes (Mem0 API key) | No (just git) | -| **Human-readable** | No (vector store) | Yes (markdown you can edit) | -| **Versioned** | No (mutable state) | Yes (git history + blame) | -| **Semantic search** | Yes (their strength) | No (not needed at personal scale) | -| **Best for** | App builders serving many users | Individual developers across their own tools | - -Mem0's own research says file-based memory "works beautifully for ≤200 static memories, single user, no concurrency." That's exactly the personal context use case — ~50-150 facts about you, curated deliberately. - ---- - +--- + +Many developers use multiple AI surfaces daily: GitHub Copilot in VS Code, Copilot CLI, Microsoft 365 Copilot, Microsoft Scout, Claude, ChatGPT, or Cursor. + +The problem: each surface starts without the context you gave the last one. Preferences, current work, boundaries, and decisions stay trapped in whichever tool you told. + +This post proposes a portable personal context layer: structured markdown files in a GitHub repo that AI tools can read. No vendor supports this end-to-end today. + +--- + +## The Problem: Context Islands + +![Context islands diagram showing isolated AI surfaces](./media/2026-07-10-portable-personal-context/context-islands.svg) + +| Surface | What it knows about you | Where that knowledge lives | +|---------|------------------------|---------------------------| +| **Copilot in VS Code** | `.github/copilot-instructions.md` in current repo | Per-repo, per-machine | +| **Copilot CLI** | Nothing persistent between sessions | Ephemeral | +| **Microsoft 365 Copilot** | Your M365 Graph data (emails, calendar) | Cloud, not exportable | +| **Microsoft Scout** | Memories, preferences, profile | Local app state | +| **Claude** | `CLAUDE.md` per project, memory | Per-project file + cloud memory | +| **Cursor** | `.cursorrules` per project | Per-project file | + +The pattern: each tool has its own user-context format. The result: +- Repeated preferences in every tool ("I prefer concise output," "use TypeScript," "don't auto-push to main") +- Decisions invisible outside the surface where they happened +- Expertise and boundaries known only where you stated them + +--- + +## You Already Know What the Solution Feels Like + +![Personalization features exist in every tool but are locked to that tool](./media/2026-07-10-portable-personal-context/personalization-silos.svg) + +| Built-in Feature | What it does | The problem | +|---|---|---| +| **M365 Copilot: Custom instructions** | "Be concise, use tables" | Doesn't reach VS Code or CLI | +| **M365 Copilot: Work profile** | Your role, org, skills | Locked in Microsoft Graph | +| **M365 Copilot: Saved memories** | Facts remembered between sessions | Only M365 Copilot sees them | +| **ChatGPT: Memory** | Auto-extracted facts about you | Only ChatGPT sees them | +| **Claude: CLAUDE.md** | Per-project instructions | Only Claude Code sees them | +| **Cursor: Rules** | Coding preferences | Only Cursor sees them | + +Each tool stores personalization separately. Portable context makes the source shared: + +``` +Today: + M365 Copilot → knows you like concise output + VS Code Copilot → doesn't know (asks again) + Copilot CLI → doesn't know (asks again) + Scout → has its own separate copy + Claude → has its own separate copy + +With portable personal context: + All surfaces → read from the same source → load your preferences +``` + +--- + +## Why Not Just Use Those Existing Features? + +| | Built-in Personalization | Portable Context | +|---|---|---| +| **Portability** | One surface only | Every surface | +| **Transparency** | Opaque ("View work data") | Human-readable markdown | +| **Exportability** | Can't export | `git clone` anywhere | +| **Versioning** | No history | Full git history | +| **Control** | Platform decides format | You decide format | +| **Decisions** | No structured log | Append-only ledger | +| **Auto-extraction** | Yes (convenient) | Manual (precise) | + +Use built-in personalization where it exists; keep portable context as the canonical source. + +--- + +## Why Not CLAUDE.md, copilot-instructions, or .cursorrules? + +Those files are **instructions TO the AI** for one project. Personal context is **information ABOUT you** across tools. + +![Scope comparison showing per-tool files as narrow vs personal context as universal](./media/2026-07-10-portable-personal-context/file-scope-comparison.svg) + +``` +.github/copilot-instructions.md → "In this repo, use ESM imports" +personal-context/process/... → "I always prefer ESM over CommonJS" +``` + +Repo-level files govern a codebase. Personal context governs how to work with *you*. + +--- + +## Why Not Just an Agent or Skill? + +Agents and skills are task-scoped. Personal context is user-scoped. + +![Persona hierarchy showing person above process above skills above agents](./media/2026-07-10-portable-personal-context/persona-hierarchy.svg) + +| | Personal Context | Agent (agent.md) | Skill (SKILL.md) | +|---|---|---|---| +| **Answers** | "Who is this person?" | "How should I behave?" | "How do I do this task?" | +| **Scope** | Everything you do | One role or surface | One repeatable procedure | +| **Lifespan** | Years (grows with you) | Months (evolves with tooling) | Weeks (refined per use) | +| **Portability** | Every surface | One surface | Some surfaces | + +Personal context should feed agents and skills, not duplicate them. Without it, agents start without your quality bar, boundaries, or past decisions. + +--- + +## Why Not Mem0 or a Cloud Memory Service? + +[Mem0](https://mem0.ai) is a cloud API for persistent AI memory. It makes different tradeoffs: + +| | Mem0 (Cloud) | Personal Context Repo | +|---|---|---| +| **Architecture** | Hosted API service | Local-first (files in git) | +| **Data ownership** | Third-party hosted | You own it (your GitHub) | +| **Works offline** | No | Yes | +| **Vendor dependency** | Yes (Mem0 API key) | No (just git) | +| **Human-readable** | No (vector store) | Yes (markdown you can edit) | +| **Versioned** | No (mutable state) | Yes (git history + blame) | +| **Semantic search** | Yes (their strength) | No (not needed at personal scale) | +| **Best for** | App builders serving many users | Individual developers across their own tools | + +For one developer, dozens of curated facts, decisions, and preferences may not need a hosted dependency. + +--- + ## Personal Context Is Not Memory -![Context vs Memory promotion pipeline](./media/2026-07-12-portable-personal-context/context-vs-memory.svg) - -Before going further, one distinction that tripped me up when I started — and trips up half the tools in this space: **personal context is not memory.** They feel similar, they overlap, and plenty of products blur them on purpose. Architecturally, though, they're two different animals, and conflating them is exactly why so many "memory" features feel both magical and untrustworthy. - -Here's the one-line version: - -> **Context is your constitution. Memory is your diary.** - -Context is what you *ratified* — declared, curated, authoritative. Memory is what was *observed* — accreted, evidentiary, a byproduct of use. - -| | Personal Context | Memory | -|---|---|---| -| **Origin** | Authored intentionally | Accumulated automatically | -| **Nature** | Curated / declared | Accreted / observed | -| **Authority** | Authoritative ("this is the rule") | Evidentiary ("this is what happened") | -| **Example** | "My branch naming convention is `{type}/{id}-{slug}`" | "Last Tuesday you renamed a branch to `wip-2`" | -| **Volume** | Small, deliberate (~50-150 facts) | High-volume, ever-growing | -| **Governance** | Human-reviewed | Auto-captured | - -They aren't rivals — they're two ends of a **promotion pipeline**: - -``` -observation → candidate → [ratification gate] → context - (memory) (proposed) (a human decision) (canonical) -``` - -Memory is the raw feed. Context is the reviewed, canonical output. The gate in the middle — an explicit human decision — is the whole point. "You renamed a branch to `wip-2` last week" is an observation; it only becomes "my branch naming convention is X" when *I* say so. - -That distinction has real architectural consequences: - -- **Different stores.** Memory wants a high-volume append log optimized for recall. Context wants a small, curated, versioned set — exactly the git repo above. -- **Different precedence.** When they conflict, **context outranks memory.** The constitution beats the diary. If memory "remembers" you pushed to `main` once, that never overrides the boundary that says you don't. -- **Different retrieval, governance, and security.** Context is load-always and trusted; memory is search-when-relevant and treated as evidence, not instruction. - -Why does this matter for the thesis of this post? Because the portable layer I'm proposing is **context, not memory.** Tools like Mem0, Claude memory, and ChatGPT memory solve the *observe-and-recall* half — and they solve it well. What none of them give you is a portable, authored, authoritative layer you *ratify*. They observe; they don't ratify. That gap is the thing this repo pattern is trying to fill. - ---- - -## The Insight: LLMs Already Speak Markdown - -The solution isn't a complex sync service, a vector database, or a new protocol. It's simpler than that. - -![Markdown plus GitHub equals universal portability](./media/2026-07-12-portable-personal-context/universal-transport.svg) - -Every AI tool can read files. Every AI tool understands markdown. And there's one platform every developer tool already authenticates with: **GitHub**. - -> **A private GitHub repo with structured markdown files IS your portable second brain.** - -Any surface that can read a file from GitHub (which is all of them) gets your full context. No new APIs, no dependencies, no vendor lock-in. - ---- - -## The Architecture: Personal Context as a Repo - -![Architecture diagram showing canonical repo feeding multiple surfaces](./media/2026-07-12-portable-personal-context/architecture.svg) - -``` -github.com/yourname/personal-context (private repo) -│ -├── context.json ← Manifest: what's here + retrieval rules -│ -├── core/ ← RARELY CHANGES (your "constitution") -│ ├── expertise.md # What you know, your domain authority -│ ├── boundaries.md # What stays human, what AI never does alone -│ ├── role.md # Job, scope, organization -│ └── communication.md # How you prefer to interact -│ -├── decisions/ ← APPEND-ONLY (your "ledger") -│ ├── _active.md # Decisions still governing current work -│ ├── 2026-07.md # This month's new decisions -│ └── ... -│ -├── process/ ← STABLE (your "playbook") -│ ├── content-workflow.md # How you create content -│ ├── code-workflow.md # How you write and ship code -│ ├── quality-bar.md # Definition of done per work type -│ └── tool-preferences.md # Preferred tools and patterns -│ -├── active/ ← CHANGES OFTEN (your "whiteboard") -│ ├── projects.md # Current active projects -│ ├── sprint-focus.md # This sprint's commitments -│ └── parking-lot.md # Deferred items -│ -└── .github/ - └── copilot-instructions.md # Tells Copilot how to USE this repo -``` - -### Why Four Layers? - -Not all context is equal. The key insight is separating by **durability** — how often something changes and who's allowed to change it: - -![Four layers diagram showing durability spectrum](./media/2026-07-12-portable-personal-context/durability-layers.svg) - -| Layer | Half-life | Mutability | Example | -|-------|-----------|-----------|---------| -| **Core** | Months/years | Human-only | "I'm a senior developer on the Azure SDK docs team" | -| **Decisions** | Permanent (append-only) | Any surface appends | "Use generation pipeline for MCP namespace files" | -| **Process** | Weeks/months | Propose via PR | "Branch naming: `{type}/{id}-{slug}`" | -| **Active** | Days/weeks | Any surface overwrites | "Sprint focus: Ship auth-flow feature" | - ---- - -## What Goes in Each Layer - -### Core: Your Constitution - -This is the stuff that rarely changes — your expertise, your boundaries, your communication preferences. Any AI surface reads this to understand *who it's working with* before you say a word. - -**`core/expertise.md`** — What you know: - -```markdown -## Domain Expertise -- Azure SDK documentation across JavaScript, Python, .NET, Java, Go, Rust -- AI developer tools (MCP servers, AI Toolkit, Copilot extensions) -- Content workflow automation and multi-agent orchestration -- Technical writing for developer audiences - -## Not My Expertise (don't assume I know) -- Kubernetes operations / cluster management -- Frontend framework internals (React, Vue, etc.) -- ML model training / fine-tuning -``` - -**`core/boundaries.md`** — What stays human: - -```markdown -## What AI Should Never Do Autonomously -- Push code to upstream repositories (only to forks) -- Send emails, Teams messages, or any outbound communication -- Close or resolve work items without my confirmation -- Delete files, branches, or repos -- Make irreversible changes without showing me the plan first - -## What AI Can Do Without Asking -- Read files, search code, explore repos -- Draft content for my review -- Run tests, linting, builds -- Create branches on my fork -- Propose edits (but not commit without confirmation) -``` - -### Decisions: Your Ledger - -The most valuable layer. Every time you make a decision in any AI surface, it gets appended here. No surface should ever re-ask a question you've already answered. - -**`decisions/_active.md`** — Still-relevant decisions: - -```markdown -### [2026-07-06] Branch naming convention -- **Context:** Inconsistent branch names across repos -- **Decision:** Always use `{type}/{work-item-id}-{brief-slug}` -- **Types:** feat, fix, docs, refactor, test - -### [2026-06-15] Prefer tables over prose for comparisons -- **Context:** AI kept writing long paragraphs comparing options -- **Decision:** When comparing 3+ options, always use a table -- **Supersedes:** Nothing (new preference) - -### [2026-05-28] No hand-written namespace files -- **Context:** Generated files were higher quality than hand-written -- **Decision:** All namespace articles must come from the generation pipeline -- **Implications:** Slower to ship, but deterministically correct -``` - -### Process: Your Playbook - -How you prefer to work. This changes occasionally as you refine your workflow. - -**`process/quality-bar.md`**: - -```markdown -## When Is a Pull Request Done? -- [ ] Work item linked with "Fixes AB#{id}" -- [ ] Meaningful title and description (not just commit messages) -- [ ] No unrelated changes (surgical edits only) -- [ ] CI passes -- [ ] Review comments addressed, not dismissed -- [ ] Staged preview links included for doc changes - -## When Is an Article Done? -- [ ] Technically accurate (verified against product behavior) -- [ ] Code samples run without modification -- [ ] All links resolve (no 404s) -- [ ] Metadata correct (ms.topic, ms.date, ms.service) -- [ ] Reviewed by at least 1 peer -``` - -### Active: Your Whiteboard - -The ephemeral-ish stuff — what you're working on right now. Any surface can overwrite this. - -**`active/sprint-focus.md`**: - -```markdown -## Sprint 14 (2026-07-01 → 2026-07-12) - -### Committed -1. Ship MCP auth namespace docs (AB#4521) -2. Review 3 community PRs on azure-dev-docs -3. Update AI Toolkit quickstart for v0.9 - -### Stretch -- Prototype portable context layer (this project!) -``` - ---- - -## How Surfaces Consume It - -### Selective Retrieval: Only Load What's Relevant - -A surface doesn't dump the entire repo into its prompt. The `context.json` manifest tells it what to load based on the task: - -``` -1. Read context.json (< 1KB, always cached) -2. ALWAYS load: core/boundaries.md + core/communication.md (~400 words) -3. Classify the current task → match to load_by_task -4. Load those 2-3 files (~500 words) -5. Load decisions/_active.md (~300 words) - -Total: ~1,200 words ≈ 1,600 tokens -``` - -That's less than 2K tokens for full personalization. Well within any context window budget. - -![Retrieval flow diagram](./media/2026-07-12-portable-personal-context/retrieval-flow.svg) - -### The Priority Stack - -If different layers contradict, the resolution is deterministic: - -``` -core/boundaries.md ← ALWAYS wins. Non-negotiable. -decisions/_active.md ← Settled questions. Don't re-ask. -process/*.md ← How to do things. Follow unless overridden in-session. -active/*.md ← Informational state. Not authoritative. -``` - -![Priority stack diagram](./media/2026-07-12-portable-personal-context/priority-stack.svg) - -### Writing Back: Closing the Loop - -Any surface can **write decisions back**: - -```bash -# After making a decision in any surface: -cd ~/personal-context -echo " -### [$(date +%Y-%m-%d)] {decision title} -- **Context:** {why this came up} -- **Decision:** {what was decided} -- **Implications:** {what this means going forward} -" >> decisions/_active.md - -git add decisions/_active.md -git commit -m "decision: {brief title}" -git push -``` - -Now every other surface picks it up on next read. Decision made in Scout? VS Code Copilot knows. Decision made in CLI? Scout knows. - ---- - +![Context vs Memory promotion pipeline](./media/2026-07-10-portable-personal-context/context-vs-memory.svg) + +Key distinction: **personal context is not memory.** They overlap, but they need different storage, governance, and precedence rules. + +Context is declared, curated, and authoritative. Memory is accumulated from use. + +| | Personal Context | Memory | +|---|---|---| +| **Origin** | Authored intentionally | Accumulated automatically | +| **Nature** | Curated / declared | Accreted / observed | +| **Authority** | Authoritative ("this is the rule") | Evidentiary ("this is what happened") | +| **Example** | "My branch naming convention is `{type}/{id}-{slug}`" | "Last Tuesday you renamed a branch to `wip-2`" | +| **Volume** | Small, deliberate (~50-150 facts) | High-volume, ever-growing | +| **Governance** | Human-reviewed | Auto-captured | + +They are two ends of a **promotion pipeline**: + +``` +observation → candidate → [ratification gate] → context + (memory) (proposed) (a human decision) (canonical) +``` + +Memory is the raw feed. Context is the reviewed output. The ratification gate is the control point. The architecture changes: + +- **Stores.** Memory wants a high-volume append log. Context wants a small, curated, versioned set. +- **Precedence.** Context outranks memory. A remembered exception does not override a stated boundary. +- **Retrieval and governance.** Context is load-always instruction; memory is search-when-relevant evidence. + +This post is about **context, not memory**: authored, reviewed, and portable. + +--- + +## The Insight: LLMs Already Speak Markdown + +![Markdown plus GitHub enables cross-tool portability](./media/2026-07-10-portable-personal-context/universal-transport.svg) + +AI tools read files. LLMs understand markdown. Developer tools commonly authenticate with **GitHub**. + +> **A private GitHub repo with structured markdown files can be the shared context source.** + +Any surface that can read the repo can load the same context. + +--- + +## The Architecture: Personal Context as a Repo + +![Architecture diagram showing canonical repo feeding multiple surfaces](./media/2026-07-10-portable-personal-context/architecture.svg) + +``` +github.com/yourname/personal-context (private repo) +│ +├── context.json ← Manifest: what's here + retrieval rules +│ +├── core/ ← RARELY CHANGES (your "constitution") +│ ├── expertise.md # What you know, your domain authority +│ ├── boundaries.md # What stays human, what AI never does alone +│ ├── role.md # Job, scope, organization +│ └── communication.md # How you prefer to interact +│ +├── decisions/ ← APPEND-ONLY (your "ledger") +│ ├── _active.md # Decisions still governing current work +│ ├── 2026-07.md # This month's new decisions +│ └── ... +│ +├── process/ ← STABLE (your "playbook") +│ ├── content-workflow.md # How you create content +│ ├── code-workflow.md # How you write and ship code +│ ├── quality-bar.md # Definition of done per work type +│ └── tool-preferences.md # Preferred tools and patterns +│ +├── active/ ← CHANGES OFTEN (your "whiteboard") +│ ├── projects.md # Current active projects +│ ├── sprint-focus.md # This sprint's commitments +│ └── parking-lot.md # Deferred items +│ +└── .github/ + └── copilot-instructions.md # Tells Copilot how to USE this repo +``` + +### Why Four Layers? + +Separate by **durability**: how often it changes and who can change it. + +![Four layers diagram showing durability spectrum](./media/2026-07-10-portable-personal-context/durability-layers.svg) + +| Layer | Half-life | Mutability | Example | +|-------|-----------|-----------|---------| +| **Core** | Months/years | Human-only | "I'm a senior developer on the Azure SDK docs team" | +| **Decisions** | Permanent (append-only) | Any surface appends | "Use generation pipeline for MCP namespace files" | +| **Process** | Weeks/months | Propose via PR | "Branch naming: `{type}/{id}-{slug}`" | +| **Active** | Days/weeks | Any surface overwrites | "Sprint focus: Ship auth-flow feature" | + +--- + +## What Goes in Each Layer + +### Core: Your Constitution + +Rarely changing context: expertise, boundaries, communication preferences. + +**`core/expertise.md`** — What you know: + +```markdown +## Domain Expertise +- Azure SDK documentation across JavaScript, Python, .NET, Java, Go, Rust +- AI developer tools (MCP servers, AI Toolkit, Copilot extensions) +- Content workflow automation and multi-agent orchestration +- Technical writing for developer audiences + +## Not My Expertise (don't assume I know) +- Kubernetes operations / cluster management +- Frontend framework internals (React, Vue, etc.) +- ML model training / fine-tuning +``` + +**`core/boundaries.md`** — What stays human: + +```markdown +## What AI Should Never Do Autonomously +- Push code to upstream repositories (only to forks) +- Send emails, Teams messages, or any outbound communication +- Close or resolve work items without my confirmation +- Delete files, branches, or repos +- Make irreversible changes without showing me the plan first + +## What AI Can Do Without Asking +- Read files, search code, explore repos +- Draft content for my review +- Run tests, linting, builds +- Create branches on my fork +- Propose edits (but not commit without confirmation) +``` + +### Decisions: Your Ledger + +Decisions appended from any surface so settled questions stay settled. + +**`decisions/_active.md`** — Still-relevant decisions: + +```markdown +### [2026-07-06] Branch naming convention +- **Context:** Inconsistent branch names across repos +- **Decision:** Always use `{type}/{work-item-id}-{brief-slug}` +- **Types:** feat, fix, docs, refactor, test + +### [2026-06-15] Prefer tables over prose for comparisons +- **Context:** AI kept writing long paragraphs comparing options +- **Decision:** When comparing 3+ options, always use a table +- **Supersedes:** Nothing (new preference) + +### [2026-05-28] No hand-written namespace files +- **Context:** Generated files were higher quality than hand-written +- **Decision:** All namespace articles must come from the generation pipeline +- **Implications:** Slower to ship, but deterministically correct +``` + +### Process: Your Playbook + +Work preferences. Update as workflow changes. + +**`process/quality-bar.md`**: + +```markdown +## When Is a Pull Request Done? +- [ ] Work item linked with "Fixes AB#{id}" +- [ ] Meaningful title and description (not just commit messages) +- [ ] No unrelated changes (surgical edits only) +- [ ] CI passes +- [ ] Review comments addressed, not dismissed +- [ ] Staged preview links included for doc changes + +## When Is an Article Done? +- [ ] Technically accurate (verified against product behavior) +- [ ] Code samples run without modification +- [ ] All links resolve (no 404s) +- [ ] Metadata correct (ms.topic, ms.date, ms.service) +- [ ] Reviewed by at least 1 peer +``` + +### Active: Your Whiteboard + +Current work state, writable by any surface. + +**`active/sprint-focus.md`**: + +```markdown +## Sprint 14 (2026-07-01 → 2026-07-12) + +### Committed +1. Ship MCP auth namespace docs (AB#4521) +2. Review 3 community PRs on azure-dev-docs +3. Update AI Toolkit quickstart for v0.9 + +### Stretch +- Prototype portable context layer (this project!) +``` + +--- + +## How Surfaces Consume It + +### Selective Retrieval: Only Load What's Relevant + +Do not load the whole repo. Use `context.json` to choose task-relevant files: + +``` +1. Read context.json (< 1KB, always cached) +2. ALWAYS load: core/boundaries.md + core/communication.md (~400 words) +3. Classify the current task → match to load_by_task +4. Load those 2-3 files (~500 words) +5. Load decisions/_active.md (~300 words) + +Total: ~1,200 words ≈ 1,600 tokens +``` + + +![Retrieval flow diagram](./media/2026-07-10-portable-personal-context/retrieval-flow.svg) + +### The Priority Stack + +Resolve contradictions deterministically: + +``` +core/boundaries.md ← ALWAYS wins. Non-negotiable. +decisions/_active.md ← Settled questions. Don't re-ask. +process/*.md ← How to do things. Follow unless overridden in-session. +active/*.md ← Informational state. Not authoritative. +``` + +![Priority stack diagram](./media/2026-07-10-portable-personal-context/priority-stack.svg) + +### Writing Back: Closing the Loop + +After human confirmation, any surface can **write decisions back**: + +```bash +# After making a decision in any surface: +cd ~/personal-context +echo " +### [$(date +%Y-%m-%d)] {decision title} +- **Context:** {why this came up} +- **Decision:** {what was decided} +- **Implications:** {what this means going forward} +" >> decisions/_active.md + +git add decisions/_active.md +git commit -m "decision: {brief title}" +git push +``` + + +--- + ## Connecting Each Surface (Proposed Integrations) -The specifics below are illustrative — some work today with manual setup, others would require tool vendors to add support. The point is that the *mechanism* is simple in every case: read a file, inject as context. +Examples only. Some work manually; others need vendor support. The mechanism: read files and inject context. ### GitHub Copilot in VS Code -In your user-level `settings.json`: - -```json -{ - "github.copilot.chat.codeGeneration.instructions": [ - { "file": "~/personal-context/core/boundaries.md" }, - { "file": "~/personal-context/core/communication.md" }, - { "file": "~/personal-context/decisions/_active.md" } - ] -} -``` - -Or reference the repo in any project's custom instructions: - -```markdown - -For my personal preferences and decisions, reference: -https://github.com/yourname/personal-context -``` - -### Copilot CLI - -Create a shell function that injects context: - -```bash -# ~/.bashrc or $PROFILE -function copilot-ctx() { - local context=$(cat ~/personal-context/core/communication.md) - gh copilot suggest -t shell "$context\n\nTask: $*" -} -``` - -### Microsoft Scout - -Scout's profile can be generated FROM the canonical repo: - -```powershell -# Sync script: pull personal-context → render me.md for Scout -$role = Get-Content ~/personal-context/core/role.md -Raw -$comms = Get-Content ~/personal-context/core/communication.md -Raw -$boundaries = Get-Content ~/personal-context/core/boundaries.md -Raw - -@" -# Personal Profile -$role - -## Communication -$comms - -## Boundaries -$boundaries -"@ | Set-Content ~/.copilot/me.md -``` - -### Microsoft 365 Copilot - -Sync the repo to a OneDrive folder: - -``` -OneDrive/personal-context/ → synced from GitHub repo -``` - -Then M365 Copilot can reference those files when you ask it to "follow my preferences." - -### Any MCP-Enabled Tool (Claude, Cursor, ChatGPT) - -Expose the repo as a simple MCP resource server — or just clone locally and point the tool's config to the files. [MCP](https://modelcontextprotocol.io) is the transport layer; the repo is the data. - ---- - -## Getting Started: 30-Minute Setup - -![Timeline showing 30-minute setup in 4 steps](./media/2026-07-12-portable-personal-context/30-min-timeline.svg) - -### 1. Create the repo (5 minutes) - -```bash -gh repo create personal-context --private -cd personal-context -mkdir -p core decisions process active .github -``` - -### 2. Write your identity (10 minutes) - -Start with `core/role.md` and `core/boundaries.md`. Don't overthink it — write what you'd tell a new team member on day one. - -### 3. Capture your first decisions (10 minutes) - -Think about the last 5 times an AI tool annoyed you by not knowing something. Those are your decisions. Write them in `decisions/_active.md`. - -### 4. Connect one surface (5 minutes) - -Pick your most-used surface and wire it up. VS Code settings, Scout profile, or a CLI alias. Verify it works — ask the AI something it should now know about you. - -### 5. Evolve naturally - -Don't try to write everything upfront. When an AI asks you something it should already know, that's a signal: write it down, commit, push. Your context grows organically from real interactions. - ---- - -## The Payoff - -![Before and after comparison showing repetition eliminated](./media/2026-07-12-portable-personal-context/before-after.svg) - -After two weeks of capturing context: - -| Before | After | -|--------|-------| -| "I prefer concise output" (every session) | AI already knows (from `core/communication.md`) | -| "Use fork-first workflow" (every PR) | AI already knows (from `process/code-workflow.md`) | -| "We decided to use the pipeline" (re-explained monthly) | AI already knows (from `decisions/_active.md`) | -| "My sprint focus is X" (repeated across tools) | Every surface reads `active/sprint-focus.md` | -| Start over in each new tool | Start where you left off, everywhere | - -The compound effect is significant. After a month, you've spent maybe 2 hours total writing context. But you've saved dozens of hours of re-explaining, re-deciding, and re-orienting AI tools that should already know you. - ---- - +In your user-level `settings.json`: + +```json +{ + "github.copilot.chat.codeGeneration.instructions": [ + { "file": "~/personal-context/core/boundaries.md" }, + { "file": "~/personal-context/core/communication.md" }, + { "file": "~/personal-context/decisions/_active.md" } + ] +} +``` + +Or reference the repo in any project's custom instructions: + +```markdown + +For my personal preferences and decisions, reference: +https://github.com/yourname/personal-context +``` + +### Copilot CLI + +Create a context-injecting shell function: + +```bash +# ~/.bashrc or $PROFILE +function copilot-ctx() { + local context=$(cat ~/personal-context/core/communication.md) + gh copilot suggest -t shell "$context\n\nTask: $*" +} +``` + +### Microsoft Scout + +Generate Scout's profile from the repo: + +```powershell +# Sync script: pull personal-context → render me.md for Scout +$role = Get-Content ~/personal-context/core/role.md -Raw +$comms = Get-Content ~/personal-context/core/communication.md -Raw +$boundaries = Get-Content ~/personal-context/core/boundaries.md -Raw + +@" +# Personal Profile +$role + +## Communication +$comms + +## Boundaries +$boundaries +"@ | Set-Content ~/.copilot/me.md +``` + +### Microsoft 365 Copilot + +Sync the repo to a OneDrive folder: + +``` +OneDrive/personal-context/ → synced from GitHub repo +``` + +### Any MCP-Enabled Tool (Claude, Cursor, ChatGPT) + +Expose the repo as an MCP resource server, or clone it locally and point the tool config to the files. [MCP](https://modelcontextprotocol.io) is transport. + +--- + +## Getting Started: 30-Minute Setup + +![Timeline showing 30-minute setup in 4 steps](./media/2026-07-10-portable-personal-context/30-min-timeline.svg) + +### 1. Create the repo (5 minutes) + +```bash +gh repo create personal-context --private +cd personal-context +mkdir -p core decisions process active .github +``` + +### 2. Write your identity (10 minutes) + +Write what you would tell a new team member on day one. + +### 3. Capture your first decisions (10 minutes) + +Write five repeated preferences or decisions in `decisions/_active.md`. + +### 4. Connect one surface (5 minutes) + +Wire up VS Code settings, Scout profile, or a CLI alias. Verify it loads context. + +### 5. Evolve naturally + +When an AI asks something it should know, write it down, commit, and push. + +--- + +## The Payoff + +![Before and after comparison showing repetition eliminated](./media/2026-07-10-portable-personal-context/before-after.svg) + +| Before | After | +|--------|-------| +| "I prefer concise output" (every session) | AI already knows (from `core/communication.md`) | +| "Use fork-first workflow" (every PR) | AI already knows (from `process/code-workflow.md`) | +| "We decided to use the pipeline" (re-explained monthly) | AI already knows (from `decisions/_active.md`) | +| "My sprint focus is X" (repeated across tools) | Every surface reads `active/sprint-focus.md` | +| Start over in each new tool | Start where you left off, everywhere | + +Likely payoff: fewer repeated preferences, fewer re-decisions, and faster starts. Keep time-saved claims only if measured. + +--- + ## Beyond the Repo: When a Service Makes Sense -![Context broker architecture with MCP facade and trust tiers](./media/2026-07-12-portable-personal-context/context-broker.svg) - -Everything above is deliberately the **floor** — the simplest thing that could possibly work. A flat git repo of markdown is the whole point: no server, no vendor, no API key. So when *would* you reach for something more? - -The honest answer: when a flat repo can't enforce what you need. A git repo hands the whole file to anyone who can read it. A **hosted service** can hand back only the slice the caller is cleared to see. That's the line. - -### What a hosted version would buy you - -- **Server-side redaction by trust tier.** Split your context into `public` / `work` / `private` tiers and enforce the split *at the server*, not the client. The Copilot CLI on a work machine sees your work tier; a public-facing agent never sees your private tier at all. A flat repo can't do this — anyone with clone access gets everything. -- **Audit and access control tied to real identity.** Who read your context, when, from which surface — logged. Per-surface access bound to an actual identity instead of an honor system. -- **The precedence stack, enforced centrally.** The priority stack from earlier ("context outranks memory," boundaries always win) now runs server-side, so every consumer gets the same resolved answer instead of each surface re-implementing it. - -### The key design call: contract vs. transport - -If you build this, the mistake to avoid is making **MCP the canonical contract.** MCP is a fast-moving adapter for agentic surfaces — the right *transport*, the wrong thing to bet your data model on. - -Build a **REST/OpenAPI service as the source of truth**, and expose **MCP as a thin, swappable facade** over it. - -> **Build the contract you can't afford to rewrite in REST; expose MCP as a facade you can afford to throw away.** - -The REST contract is the thing you version carefully and support for years. The MCP facade is a convenience layer you can rewrite — or swap for the next protocol — without touching your data model. - -### What the service actually is: a context broker - -Strip away the stack and the service does four jobs: - -1. **Merge** — combine the layers (core, decisions, process, active) into one view. -2. **Priority** — apply the precedence stack so conflicts resolve deterministically. -3. **Redaction** — return only the caller's trust tier. -4. **Output scanning** — catch a prompt-injection attempt trying to exfiltrate a tier the caller shouldn't see. - -That fourth job names the dominant threat honestly: **prompt-injection exfiltration.** A malicious doc or tool convinces the agent to read your private context and leak it. Server-side tier redaction is the mitigation a flat git repo simply can't offer — the private tier never leaves the server in the first place. - -### Even a service still hits the standards wall - -Here's the deflating part, and it reinforces where this post is headed. Even with a hosted service, consumption stays uneven: - -| Surface | Talks to a remote MCP server? | -|---|---| -| VS Code / Copilot CLI / Foundry | Yes — directly | -| Claude / ChatGPT | Only via an `mcp-remote` proxy | -| Microsoft 365 Copilot | No — it wants Graph connectors / declarative agents | - -So the grown-up version doesn't escape the "no universal standard" problem from the next section — it runs straight into the same wall, just from a more capable starting point. - -And to be clear about scope: for one developer, the repo is usually enough. The service earns its complexity only when you have **multiple trust tiers, multiple consumers, or a real injection threat model.** Short of that, `git push` is the architecture. - ---- - -## What's Next: The Standard That Doesn't Exist Yet +![Context broker architecture with MCP facade and trust tiers](./media/2026-07-10-portable-personal-context/context-broker.svg) + +The repo is the floor: markdown, git, no server, no vendor, no API key. Use a service only when a flat repo cannot enforce access. Git gives readers the whole file; a **hosted service** can return only authorized slices. -![Convergence diagram showing vendors approaching a missing standard](./media/2026-07-12-portable-personal-context/standards-convergence.svg) +### What a hosted version would buy you -This post is a proposal, not a product announcement. Today, **none of this works automatically** — not even across two Copilot surfaces from the same company. Each tool reads its own context files, in its own format, from its own location. +- **Server-side redaction by trust tier.** Enforce `public` / `work` / `private` tiers at the server. A flat repo cannot do that; clone access gets everything. +- **Identity-based audit and access control.** Log who read context, when, and from which surface. +- **Central precedence.** Resolve boundaries, decisions, process, and active state once instead of per surface. -But the industry is converging on the problem: +### The key design call: contract vs. transport -- **Mem0** raised $24M to solve "AI memory that persists across sessions" -- **Anthropic** added memory to Claude and `CLAUDE.md` per project -- **OpenAI** added Custom Instructions and Memory to ChatGPT -- **Microsoft** ships Copilot personalization and Scout memories -- **Letta** builds git-backed persistent memory for agents -- **Every coding tool** has its own instructions file format +Do not make **MCP the canonical contract.** MCP is useful transport, not the data model. Build a **REST/OpenAPI service as the source of truth** and expose **MCP as a thin facade**. -What's missing is a **shared standard** — an agreement across tools about where personal context lives and how to read/write it. The [Model Context Protocol](https://modelcontextprotocol.io) standardized tool integration; we need the same for user identity. +> **Build the contract you can't afford to rewrite in REST; expose MCP as a facade you can afford to throw away.** -No such standard exists today. There's no "vCard for AI preferences," no "iCal for decisions." This is genuinely unoccupied territory. +Version REST carefully. Treat MCP as replaceable. -The GitHub repo approach described here is a bet: that structured markdown in a well-known location, with a manifest for selective retrieval, is the simplest architecture that *could* work — if tool builders agreed to read it. Every tool speaks git. Every LLM speaks markdown. Every developer has a GitHub account. +### What the service actually is: a context broker -**The ask to tool builders:** Add a `$COPILOT_CONTEXT_PATH` or equivalent. Let users point to a directory of markdown files that your surface reads as additional context. That's the entire integration. The portability follows naturally. +The service has four jobs: -Your second brain is just a `git push` away from every AI surface you use — once the surfaces agree to look for it. +1. **Merge** — combine the layers (core, decisions, process, active) into one view. +2. **Priority** — apply the precedence stack so conflicts resolve deterministically. +3. **Redaction** — return only the caller's trust tier. +4. **Output scanning** — catch a prompt-injection attempt trying to exfiltrate a tier the caller shouldn't see. + +The fourth job addresses **prompt-injection exfiltration**. With server-side redaction, private context never leaves the server. + +### Even a service still hits the standards wall + +The limitation: even with a hosted service, consumption stays uneven: + +| Surface | Talks to a remote MCP server? | +|---|---| +| VS Code / Copilot CLI / Foundry | Yes — directly | +| Claude / ChatGPT | Only via an `mcp-remote` proxy | +| Microsoft 365 Copilot | No — it wants Graph connectors / declarative agents | + +The hosted version still needs a shared standard. For one developer, the repo is usually enough. A service earns its complexity only with **multiple trust tiers, multiple consumers, or a real injection threat model.** --- -*This is a proposal and a conversation starter. Have thoughts? Disagree with the approach? Building something similar? I'd love to hear how you're thinking about context portability across AI tools.* - +## What's Next: The Standard That Doesn't Exist Yet + +![Convergence diagram showing vendors approaching a missing standard](./media/2026-07-10-portable-personal-context/standards-convergence.svg) + +This post is a proposal, not a product announcement. Today, **none of this works automatically**. Each tool reads its own context files, in its own format, from its own location. Vendors are adding memory, custom instructions, project files, and agent profiles, but not a shared context standard. + +What's missing is a **shared standard** for where personal context lives and how to read/write it. The [Model Context Protocol](https://modelcontextprotocol.io) standardized tool integration; user identity needs the same kind of agreement. No shared standard exists today. + +The GitHub repo approach is a bet: structured markdown plus a retrieval manifest could work if tool builders agreed to read it. + +**The ask to tool builders:** Add an `$AI_CONTEXT_PATH` or equivalent. Let users point to markdown context. Portable context works when surfaces agree to read the repo. diff --git a/website/blog/media/2026-07-12-portable-personal-context/30-min-timeline.svg b/website/blog/media/2026-07-10-portable-personal-context/30-min-timeline.svg similarity index 100% rename from website/blog/media/2026-07-12-portable-personal-context/30-min-timeline.svg rename to website/blog/media/2026-07-10-portable-personal-context/30-min-timeline.svg diff --git a/website/blog/media/2026-07-12-portable-personal-context/architecture.svg b/website/blog/media/2026-07-10-portable-personal-context/architecture.svg similarity index 100% rename from website/blog/media/2026-07-12-portable-personal-context/architecture.svg rename to website/blog/media/2026-07-10-portable-personal-context/architecture.svg diff --git a/website/blog/media/2026-07-12-portable-personal-context/before-after.svg b/website/blog/media/2026-07-10-portable-personal-context/before-after.svg similarity index 100% rename from website/blog/media/2026-07-12-portable-personal-context/before-after.svg rename to website/blog/media/2026-07-10-portable-personal-context/before-after.svg diff --git a/website/blog/media/2026-07-12-portable-personal-context/context-broker.svg b/website/blog/media/2026-07-10-portable-personal-context/context-broker.svg similarity index 100% rename from website/blog/media/2026-07-12-portable-personal-context/context-broker.svg rename to website/blog/media/2026-07-10-portable-personal-context/context-broker.svg diff --git a/website/blog/media/2026-07-12-portable-personal-context/context-islands.svg b/website/blog/media/2026-07-10-portable-personal-context/context-islands.svg similarity index 100% rename from website/blog/media/2026-07-12-portable-personal-context/context-islands.svg rename to website/blog/media/2026-07-10-portable-personal-context/context-islands.svg diff --git a/website/blog/media/2026-07-12-portable-personal-context/context-vs-memory.svg b/website/blog/media/2026-07-10-portable-personal-context/context-vs-memory.svg similarity index 100% rename from website/blog/media/2026-07-12-portable-personal-context/context-vs-memory.svg rename to website/blog/media/2026-07-10-portable-personal-context/context-vs-memory.svg diff --git a/website/blog/media/2026-07-12-portable-personal-context/durability-layers.svg b/website/blog/media/2026-07-10-portable-personal-context/durability-layers.svg similarity index 100% rename from website/blog/media/2026-07-12-portable-personal-context/durability-layers.svg rename to website/blog/media/2026-07-10-portable-personal-context/durability-layers.svg diff --git a/website/blog/media/2026-07-12-portable-personal-context/file-scope-comparison.svg b/website/blog/media/2026-07-10-portable-personal-context/file-scope-comparison.svg similarity index 100% rename from website/blog/media/2026-07-12-portable-personal-context/file-scope-comparison.svg rename to website/blog/media/2026-07-10-portable-personal-context/file-scope-comparison.svg diff --git a/website/blog/media/2026-07-12-portable-personal-context/persona-hierarchy.svg b/website/blog/media/2026-07-10-portable-personal-context/persona-hierarchy.svg similarity index 100% rename from website/blog/media/2026-07-12-portable-personal-context/persona-hierarchy.svg rename to website/blog/media/2026-07-10-portable-personal-context/persona-hierarchy.svg diff --git a/website/blog/media/2026-07-12-portable-personal-context/personalization-silos.svg b/website/blog/media/2026-07-10-portable-personal-context/personalization-silos.svg similarity index 100% rename from website/blog/media/2026-07-12-portable-personal-context/personalization-silos.svg rename to website/blog/media/2026-07-10-portable-personal-context/personalization-silos.svg diff --git a/website/blog/media/2026-07-12-portable-personal-context/priority-stack.svg b/website/blog/media/2026-07-10-portable-personal-context/priority-stack.svg similarity index 100% rename from website/blog/media/2026-07-12-portable-personal-context/priority-stack.svg rename to website/blog/media/2026-07-10-portable-personal-context/priority-stack.svg diff --git a/website/blog/media/2026-07-12-portable-personal-context/retrieval-flow.svg b/website/blog/media/2026-07-10-portable-personal-context/retrieval-flow.svg similarity index 100% rename from website/blog/media/2026-07-12-portable-personal-context/retrieval-flow.svg rename to website/blog/media/2026-07-10-portable-personal-context/retrieval-flow.svg diff --git a/website/blog/media/2026-07-12-portable-personal-context/standards-convergence.svg b/website/blog/media/2026-07-10-portable-personal-context/standards-convergence.svg similarity index 100% rename from website/blog/media/2026-07-12-portable-personal-context/standards-convergence.svg rename to website/blog/media/2026-07-10-portable-personal-context/standards-convergence.svg diff --git a/website/blog/media/2026-07-12-portable-personal-context/universal-transport.svg b/website/blog/media/2026-07-10-portable-personal-context/universal-transport.svg similarity index 100% rename from website/blog/media/2026-07-12-portable-personal-context/universal-transport.svg rename to website/blog/media/2026-07-10-portable-personal-context/universal-transport.svg From 4735ceb6c71508fcf9aca3ee018202577c6a6ec1 Mon Sep 17 00:00:00 2001 From: Dina Berry Date: Thu, 9 Jul 2026 10:08:38 -0700 Subject: [PATCH 7/7] Apply reviewer fixes: correct tool facts, scope portability, fix broker/security model Addresses fact-check + coherence review on PR #75: - Fix outdated tool refs (Copilot CLI, Cursor .cursor/rules, Claude/ChatGPT remote MCP) - Correct Copilot CLI persistence and Scout profile claims - Scope portability to shared source + manual wiring - Add threat-model note; enforce trust tiers before retrieval (scanning = defense-in-depth) - Keep Git canonical; broker is derived read facade - Add write-back conflict caveat; fix 'MCP is transport' wording - Remove misleading 'portable ai memory' keyword; label 30-min setup as estimate Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- .../2026-07-10-portable-personal-context.md | 91 +++++++++++-------- 1 file changed, 52 insertions(+), 39 deletions(-) diff --git a/website/blog/2026-07-10-portable-personal-context.md b/website/blog/2026-07-10-portable-personal-context.md index 207eeee..55b78bb 100644 --- a/website/blog/2026-07-10-portable-personal-context.md +++ b/website/blog/2026-07-10-portable-personal-context.md @@ -3,9 +3,9 @@ slug: /2026-07-10-portable-personal-context date: 2026-07-10 canonical_url: https://dfberry.github.io/blog/2026-07-10-portable-personal-context custom_edit_url: null -sidebar_label: "2026.07.12 Portable context" +sidebar_label: "2026.07.10 Portable context" title: "Portable Personal Context Across AI Client Surfaces" -description: "Build a cross-tool personal context layer with markdown and GitHub so AI client surfaces like Copilot, Claude, Cursor, ChatGPT, M365, Scout, and CLI can share your preferences, decisions, and active work." +description: "Build a cross-tool personal context source with markdown and GitHub so AI client surfaces like Copilot, Claude, Cursor, ChatGPT, M365, Scout, and CLI can load your preferences, decisions, and active work when wired to it." tags: - ai - copilot @@ -27,7 +27,7 @@ keywords: - github personal context repo - decisions ledger - model context protocol - - portable ai memory + - portable context source - copilot context - cross-surface copilot - developer productivity ai @@ -41,7 +41,7 @@ Many developers use multiple AI surfaces daily: GitHub Copilot in VS Code, Copil The problem: each surface starts without the context you gave the last one. Preferences, current work, boundaries, and decisions stay trapped in whichever tool you told. -This post proposes a portable personal context layer: structured markdown files in a GitHub repo that AI tools can read. No vendor supports this end-to-end today. +This post proposes a portable personal context source: structured markdown files in a GitHub repo that AI tools can read. No vendor supports this end-to-end today. The storage can be portable; the behavior is not automatic. Each surface still needs its own wiring. --- @@ -52,11 +52,11 @@ This post proposes a portable personal context layer: structured markdown files | Surface | What it knows about you | Where that knowledge lives | |---------|------------------------|---------------------------| | **Copilot in VS Code** | `.github/copilot-instructions.md` in current repo | Per-repo, per-machine | -| **Copilot CLI** | Nothing persistent between sessions | Ephemeral | +| **Copilot CLI** | Local instructions, skills, plugins, MCP servers, and session data | CLI-specific local state | | **Microsoft 365 Copilot** | Your M365 Graph data (emails, calendar) | Cloud, not exportable | | **Microsoft Scout** | Memories, preferences, profile | Local app state | | **Claude** | `CLAUDE.md` per project, memory | Per-project file + cloud memory | -| **Cursor** | `.cursorrules` per project | Per-project file | +| **Cursor** | Project Rules in `.cursor/rules/*.mdc`, plus `AGENTS.md` support | Per-project rules | The pattern: each tool has its own user-context format. The result: - Repeated preferences in every tool ("I prefer concise output," "use TypeScript," "don't auto-push to main") @@ -89,7 +89,7 @@ Today: Claude → has its own separate copy With portable personal context: - All surfaces → read from the same source → load your preferences + Wired surfaces → read from the same source → load your preferences ``` --- @@ -98,7 +98,7 @@ With portable personal context: | | Built-in Personalization | Portable Context | |---|---|---| -| **Portability** | One surface only | Every surface | +| **Portability** | One surface only | Shared source; manual wiring per surface | | **Transparency** | Opaque ("View work data") | Human-readable markdown | | **Exportability** | Can't export | `git clone` anywhere | | **Versioning** | No history | Full git history | @@ -106,13 +106,13 @@ With portable personal context: | **Decisions** | No structured log | Append-only ledger | | **Auto-extraction** | Yes (convenient) | Manual (precise) | -Use built-in personalization where it exists; keep portable context as the canonical source. +Use built-in personalization where it exists; keep portable context as the canonical source you can inspect and version. --- -## Why Not CLAUDE.md, copilot-instructions, or .cursorrules? +## Why Not CLAUDE.md, copilot-instructions, or Cursor Rules? -Those files are **instructions TO the AI** for one project. Personal context is **information ABOUT you** across tools. +Those files are **instructions TO the AI** for one project. Personal context is **information ABOUT you** across tools. Cursor's current model is Project Rules in `.cursor/rules/*.mdc`; `.cursorrules` is legacy. ![Scope comparison showing per-tool files as narrow vs personal context as universal](./media/2026-07-10-portable-personal-context/file-scope-comparison.svg) @@ -136,7 +136,7 @@ Agents and skills are task-scoped. Personal context is user-scoped. | **Answers** | "Who is this person?" | "How should I behave?" | "How do I do this task?" | | **Scope** | Everything you do | One role or surface | One repeatable procedure | | **Lifespan** | Years (grows with you) | Months (evolves with tooling) | Weeks (refined per use) | -| **Portability** | Every surface | One surface | Some surfaces | +| **Portability** | Shared source across wired surfaces | One surface | Some surfaces | Personal context should feed agents and skills, not duplicate them. Without it, agents start without your quality bar, boundaries, or past decisions. @@ -212,7 +212,7 @@ Any surface that can read the repo can load the same context. ![Architecture diagram showing canonical repo feeding multiple surfaces](./media/2026-07-10-portable-personal-context/architecture.svg) ``` -github.com/yourname/personal-context (private repo) +github.com//personal-context (placeholder private repo) │ ├── context.json ← Manifest: what's here + retrieval rules │ @@ -251,9 +251,9 @@ Separate by **durability**: how often it changes and who can change it. | Layer | Half-life | Mutability | Example | |-------|-----------|-----------|---------| | **Core** | Months/years | Human-only | "I'm a senior developer on the Azure SDK docs team" | -| **Decisions** | Permanent (append-only) | Any surface appends | "Use generation pipeline for MCP namespace files" | +| **Decisions** | Permanent (append-only) | Any surface proposes; append after human confirmation | "Use generation pipeline for MCP namespace files" | | **Process** | Weeks/months | Propose via PR | "Branch naming: `{type}/{id}-{slug}`" | -| **Active** | Days/weeks | Any surface overwrites | "Sprint focus: Ship auth-flow feature" | +| **Active** | Days/weeks | Any surface updates after pull-before-push | "Sprint focus: Ship auth-flow feature" | --- @@ -298,7 +298,7 @@ Rarely changing context: expertise, boundaries, communication preferences. ### Decisions: Your Ledger -Decisions appended from any surface so settled questions stay settled. +Decisions can be proposed from any surface so settled questions stay settled after review. **`decisions/_active.md`** — Still-relevant decisions: @@ -394,6 +394,10 @@ active/*.md ← Informational state. Not authoritative. ![Priority stack diagram](./media/2026-07-10-portable-personal-context/priority-stack.svg) +### Threat Model: Retrieval Is the Boundary + +The primary risk is prompt injection causing a surface to retrieve or reveal context it should not have. Trust tiers must be enforced **before retrieval**, by deciding what files or slices enter the prompt. Output scanning is not a security boundary; use it only as defense in depth. Keep two boundary files if needed: shareable operating rules that most tools can load, and private sensitive constraints that only trusted surfaces can retrieve. + ### Writing Back: Closing the Loop After human confirmation, any surface can **write decisions back**: @@ -413,6 +417,7 @@ git commit -m "decision: {brief title}" git push ``` +That simple append is safe only for a single writer with a fresh clone. Multi-surface writes need write intents with IDs and timestamps, pull-before-push, and PR-based reconciliation for stale updates or conflicts. The core layer stays human-only; non-active layers should go through review instead of direct overwrite. --- @@ -439,27 +444,33 @@ Or reference the repo in any project's custom instructions: ```markdown For my personal preferences and decisions, reference: -https://github.com/yourname/personal-context +https://github.com//personal-context ``` ### Copilot CLI -Create a context-injecting shell function: +Use the current standalone `copilot` CLI. Put durable CLI instructions in `$HOME/.copilot/copilot-instructions.md`, then point those instructions at the cloned context repo: ```bash -# ~/.bashrc or $PROFILE -function copilot-ctx() { - local context=$(cat ~/personal-context/core/communication.md) - gh copilot suggest -t shell "$context\n\nTask: $*" -} +mkdir -p ~/.copilot +cat > ~/.copilot/copilot-instructions.md <<'EOF' +For personal preferences and decisions, read: +- ~/personal-context/core/communication.md +- ~/personal-context/core/boundaries.md +- ~/personal-context/decisions/_active.md + +Treat the repo as reference context. Do not rewrite core files without human approval. +EOF ``` +For richer integration, expose the same repo through an MCP server and register it with `copilot mcp`. + ### Microsoft Scout -Generate Scout's profile from the repo: +Scout exposes settings for memory, personality presets, workspace, and permissions. Use those surfaces to mirror the same repo-backed preferences manually or through a sync process. A generated profile file can work as an implementation pattern, but the path below is illustrative, not a documented Scout contract: ```powershell -# Sync script: pull personal-context → render me.md for Scout +# Sync script: pull personal-context → render an illustrative Scout profile $role = Get-Content ~/personal-context/core/role.md -Raw $comms = Get-Content ~/personal-context/core/communication.md -Raw $boundaries = Get-Content ~/personal-context/core/boundaries.md -Raw @@ -473,7 +484,7 @@ $comms ## Boundaries $boundaries -"@ | Set-Content ~/.copilot/me.md +"@ | Set-Content ./scout-profile-example.md ``` ### Microsoft 365 Copilot @@ -486,14 +497,16 @@ OneDrive/personal-context/ → synced from GitHub repo ### Any MCP-Enabled Tool (Claude, Cursor, ChatGPT) -Expose the repo as an MCP resource server, or clone it locally and point the tool config to the files. [MCP](https://modelcontextprotocol.io) is transport. +Expose the repo as an MCP resource server, or clone it locally and point the tool config to the files. [MCP](https://modelcontextprotocol.io) is the integration protocol for tools, resources, and prompts; use it to expose context as resources or tools where supported. --- -## Getting Started: 30-Minute Setup +## Getting Started: Example 30-Minute Setup ![Timeline showing 30-minute setup in 4 steps](./media/2026-07-10-portable-personal-context/30-min-timeline.svg) +This is a rough first-pass estimate, not a guarantee. The ongoing cost is maintenance: review proposed changes, resolve conflicts, and prune stale active context. + ### 1. Create the repo (5 minutes) ```bash @@ -526,11 +539,11 @@ When an AI asks something it should know, write it down, commit, and push. | Before | After | |--------|-------| -| "I prefer concise output" (every session) | AI already knows (from `core/communication.md`) | -| "Use fork-first workflow" (every PR) | AI already knows (from `process/code-workflow.md`) | -| "We decided to use the pipeline" (re-explained monthly) | AI already knows (from `decisions/_active.md`) | -| "My sprint focus is X" (repeated across tools) | Every surface reads `active/sprint-focus.md` | -| Start over in each new tool | Start where you left off, everywhere | +| "I prefer concise output" (every session) | A wired surface can load it from `core/communication.md` | +| "Use fork-first workflow" (every PR) | A wired surface can load it from `process/code-workflow.md` | +| "We decided to use the pipeline" (re-explained monthly) | A wired surface can load it from `decisions/_active.md` | +| "My sprint focus is X" (repeated across tools) | A wired surface can read `active/sprint-focus.md` | +| Start over in each new tool | Start from the same source after each tool is wired | Likely payoff: fewer repeated preferences, fewer re-decisions, and faster starts. Keep time-saved claims only if measured. @@ -550,11 +563,11 @@ The repo is the floor: markdown, git, no server, no vendor, no API key. Use a se ### The key design call: contract vs. transport -Do not make **MCP the canonical contract.** MCP is useful transport, not the data model. Build a **REST/OpenAPI service as the source of truth** and expose **MCP as a thin facade**. +Do not make **MCP the canonical contract.** MCP is the integration protocol, not the canonical data model. Keep Git as the source of truth. If you build a service, make it a derived read facade over the repo, with a REST/OpenAPI contract and MCP exposed as a thin facade where clients support it. -> **Build the contract you can't afford to rewrite in REST; expose MCP as a facade you can afford to throw away.** +> **Keep the contract you can't afford to rewrite in Git and REST; expose MCP as a facade you can afford to replace.** -Version REST carefully. Treat MCP as replaceable. +Version the REST facade carefully. Treat MCP adapters as replaceable. ### What the service actually is: a context broker @@ -563,9 +576,9 @@ The service has four jobs: 1. **Merge** — combine the layers (core, decisions, process, active) into one view. 2. **Priority** — apply the precedence stack so conflicts resolve deterministically. 3. **Redaction** — return only the caller's trust tier. -4. **Output scanning** — catch a prompt-injection attempt trying to exfiltrate a tier the caller shouldn't see. +4. **Defense-in-depth scanning** — flag output that appears to reveal a tier the caller should not see. -The fourth job addresses **prompt-injection exfiltration**. With server-side redaction, private context never leaves the server. +The third job is the security boundary for **prompt-injection exfiltration**. With server-side redaction before retrieval, private context never enters the prompt for an untrusted caller. The fourth job can catch mistakes, but it cannot make unsafe retrieval safe. ### Even a service still hits the standards wall @@ -574,7 +587,7 @@ The limitation: even with a hosted service, consumption stays uneven: | Surface | Talks to a remote MCP server? | |---|---| | VS Code / Copilot CLI / Foundry | Yes — directly | -| Claude / ChatGPT | Only via an `mcp-remote` proxy | +| Claude / ChatGPT | Yes — directly where the surface, plan, and auth model allow remote MCP | | Microsoft 365 Copilot | No — it wants Graph connectors / declarative agents | The hosted version still needs a shared standard. For one developer, the repo is usually enough. A service earns its complexity only with **multiple trust tiers, multiple consumers, or a real injection threat model.**