Own your context. Carry it between agents.

How Pantheon works

Every agent starts empty. Pantheon stores a conscience — the real conversation, the durable facts, and the files you made — in a private GitHub repo on your account. You own that repository and 100% of the context saved inside it. A project conscience is called a space: a short name you choose, like preorders or annotation-design.

This is not a transcript copier. Handoff archives the conversation verbatim and writes a distilled packet on top of it — the packet is a layer, never a replacement. Hand the same chat off twice and only the new turns are added; hand off a different chat and it joins the space as another session. Nothing a space has ever held is overwritten.

Your context belongs to you

The private vault repository is the source of truth—not a backup or export. Pantheon's database stores account and pairing records plus the credentials needed to connect to your vault, but never your conversations, memories, decisions, or artifact contents.

GitHub notes that public repositories remain readable because they are already public. The selected installation gives Pantheon write access only to your dedicated private vault.

Context continuity

A context window is temporary working memory. Context continuity is the system property that carries the state of the work across a fresh chat, a model switch, or a different agent application—and reconstructs only the part the next task needs.

Long context stores more tokens inside one run. Continuity preserves the project when that run ends. The research page reviews the evidence from long-context and long-term-memory benchmarks and documents Pantheon's design boundaries.

Resume and retrieval

Resume does not pour the archive into the model — that would spend the context window it is trying to save. It hands over a complete map and lets the agent fetch what it needs.

sessions and story are what stop a thin handoff hiding a long project. handoff.md is written for the space rather than the last chat — its totals, its stored files, its most recent turns wherever they happened — so ten minutes of tidying cannot overwrite the account of a month’s work. Resume also reports the total turn count across the space and names every conversation in it, so the agent knows the rest exists and can open it.

When the packet does not cover what you are asking about, the agent searches rather than guessing. pantheon_search reads tool calls as well as messages — a file is findable by name even if nobody typed that name in prose — and takes a context window so a hit comes back with the turns around it. From a hit it can widen with pantheon_get_turns or read a whole conversation with pantheon_get_session.

If a resumed agent says it has no context for something you know you discussed, ask it to search the space. Missing context is nearly always unsearched rather than unsaved.

Skills

A skill is a lesson this project already learned, written down so the next agent starts with it. Memory is fetched when an agent goes looking; resume hands over every promoted skill's name and trigger, then the agent fetches the body only when the work matches. That is the whole difference, and it is why there are never many.

When a successful handoff adds turns, the agent compares recurring signals with existing live and draft lessons, reads the cited turns, and batch-saves at most five justified drafts without interrupting you. Run this command to review again at any time:

/pantheon-skills my-project

What it reads: the corrections you had to repeat across conversations, the commands that recur across sessions, and any failure that hit more than once. It also checks your AGENTS.md and README, and will not write something they already say.

The strongest evidence usually is not in the vault at all. Most agents record which tools they called but not what came back — Cursor writes no tool results to disk — so what a command actually printed when it failed exists only in the live conversation. That is why the review runs during handoff, where the agent can weigh what it saw alongside what was stored.

Drafts wait on the space's own page in this app, under Skills, with the turns each one cites listed beside it. Promote one and every future resume of that space names it; retire it and it stops being served. An agent reads the guidance itself with pantheon_get_skill when it is about to work in an area a skill covers — resume only carries the names and triggers, so an unopened skill costs a line rather than a page.

Sharing a space

You can give one space to another Pantheon user, by their GitHub handle, from Settings → Sharing. They get the conscience — every packet, the durable facts, every archived conversation and the stored files — and their agents resume it by name like any other space.

It shows up in their list marked Shared by @you, and on their machine it lands beside their vault rather than inside it, so nothing of yours is ever committed to their repo.

/pantheon-resume preorders/pantheon-resume obirikan/preorders

A bare name is enough when only one space matches. If a shared space has the same name as one of your own, yours wins; if two people have shared a space of that name with you, resume asks which rather than guessing. Qualifying it with the owner's handle settles it either way.

Shared spaces refresh with pantheon sync, and before any handoff or resume, so the copy an agent reads is current. The first pull of a large space fetches every file and takes a moment; after that only what changed comes down.

Data fidelity: what gets saved

Pantheon setup focuses on desktop agents because that is where the real session record exists. A local MCP process can read the conversation the client already stored on disk, including recorded tool activity and files, without asking the model to reconstruct its own history.

Browser-only agents are not offered in the setup flow. A remote server cannot read their session files, tool results, or locally generated artifacts, so a handoff would depend on whatever summary the model chose to send. Resume remains most useful when both the leaving and receiving agents use the desktop connection.

Supported apps

Pantheon supports agent apps that can start a local MCP process. That local process is what gives the handoff enough fidelity to be a conscience rather than another summary.

The complete desktop instructions live at the top under Installation and setup, so there is one setup sequence to follow. After changing any MCP configuration, reload MCP or restart the app before the first handoff.

ChatGPT.app and Codex share ~/.codex/config.toml. ChatGPT Classic is the legacy app and cannot start a local MCP server.

Command reference

/pantheon-handoff <space>

/pantheon-resume [space]

/pantheon-park <space>

/pantheon-remember <space> <fact>

/pantheon-spaces

/pantheon-skills <space>

/pantheon-help

Naming spaces

A space is the short name you give a conscience. Letters, numbers, dots, underscores, hyphens — one token, not a sentence.

• Handoff, park, remember — if you typed the name, the agent calls the tool. First write creates the space. It must not say the space “still needs to be created.”
• Resume — existing spaces only. If you omit the name the agent lists live spaces and asks which one; if the name is not in the vault it should say so rather than pick a neighbour.
• /pantheon-spaces — the live vault list and nothing else. Never memory, this chat, or another app.

Files

If the chat produced a PDF, letter, CV, or spreadsheet, handoff attaches it as an artifact. Naming a .pdf without attaching it is rejected, so a space never promises a file it does not hold. Desktop agents pass an existing local path, agents without a shared filesystem can pass a downloadable HTTPS URL, and inline base64 remains a fallback. Pantheon never needs the agent to regenerate or convert a file for handoff. Named code fences are stored automatically.

Resume lists file names without loading their bytes into the context window. When one is needed, pantheon_get_artifact returns the actual file as an MCP resource. A local desktop agent can instead restore it into the current workspace with save_to; Pantheon confines the destination to that workspace and will not overwrite an existing file.

Host it yourself

The control plane is a Next.js app backed by Postgres. It stores accounts, tokens, and paired machines — never conversation content, which lives only in your own GitHub repo. The App installation is restricted to that dedicated vault and receives no access to your other private repositories. Nothing depends on a persistent disk, so it runs happily on Vercel or any container host.

1. Create a Supabase project and copy the Transaction pooler URI — port 6543, not the direct connection, which resolves to IPv6 only.
2. Put it in DATABASE_URL, then create the schema. Tables live in a dedicated pantheon schema so Supabase never exposes them through PostgREST.

cd apps/webpnpm db:migrate

3. Set NEXT_PUBLIC_APP_URL to your HTTPS origin before building — it is compiled into the client bundle, not read at runtime.
4. Point the GitHub App callback to https://your-domain/api/github/callback and the setup URL to https://your-domain/api/github/setup.
5. On Vercel, set the root directory to apps/web and leave “include files outside the root directory” on — the app depends on workspace packages, so the install has to run at the repo root.

Confirm it came up. A green check here means Postgres is reachable, not merely that HTML is being served.

curl https://your-domain/api/health

Free Supabase projects pause after about a week of inactivity, so point an uptime check at that endpoint — it runs a real query, which keeps the project awake.

Troubleshooting

Open the one that matches what you are seeing.

/mcp

pantheon_handoff

which pantheon

pantheon_local_sessionspantheon_forget_session

pantheon_search

pantheon sync