About
Change the agent. Keep the Context.
Every new chat starts from nothing. The hour you spent explaining the codebase, the four approaches you ruled out, the file the model finally got right — none of it survives a model switch, a context limit, or Monday morning. Pantheon sits underneath those agents: it preserves the work in a GitHub or Google Drive vault you control, orients the next agent with a bounded packet, and lets it retrieve the evidence on demand.
Context continuity is the ability to preserve, carry forward, and selectively reconstruct the state of the work across a fresh chat, a tired window, a different model, another machine, or a colleague. A longer context window stores more tokens. Continuity carries the project when that window ends.
It is not a longer prompt, a chat export, or a summary you paste into the next model. Those lose the record. Pantheon archives first and distils second: the packet that orients the next agent stays short because the conversations and files survive underneath it.
The conversation and the files live outside any one model. A summary sits on top of that record; it never replaces it.
The next agent starts with orientation and a map, not a megabyte of history it may not need.
When the packet is thin, retrieve the turn, the tool call, or the file — and cite it. A summary you cannot reopen is not continuity.
Spaces are ordinary folders in GitHub or Drive. MCP gives Cursor, Claude Code, and Codex the same handoff, resume, and retrieve commands.
Continuity does not mean replaying everything. It means keeping enough evidence that the next agent can assemble the smallest trustworthy context for the work in front of it.
A space is the named store for one project — preorders, annotation-design. It is not a chat export. It is the conversation, the decisions distilled out of it, and the files it produced, kept as ordinary files in a folder:
handoff.mdThe packet the next agent reads first, written for the space rather than the last chat: your summary and the ones before it, the stored file names, the last fourteen spoken turns wherever they happened, and a map of every session. Each handoff rebuilds it from the archive.
memory.mdDurable facts, one bullet per line, only ever appended. This is what survives when a thread is long finished.
handoffs/<time>.mdEvery packet ever written here, each describing the one session that wrote it. Resume replays these as the story so far, and the space packet quotes the most recent of them, so a short final handoff cannot erase the account of what came before it.
sessions/<id>/transcript.jsonlThe conversations themselves, one per folder, one turn per line, including tool calls and any results the client records. Pantheon preserves what the host log actually contains.
sessions/<id>/artifacts/The files that chat produced or you attached, stored as real bytes rather than described in prose.
space.yamlThe name you typed and when the space was created.
Because they are plain files, you can inspect them directly in GitHub or Google Drive and take them with you if you stop using this.
It works out which chat you mean
Agents keep one file per conversation, so Pantheon has to pick. It takes the one you are in — but if the most recently written chat is not the one that mentions the space you named, it stops and asks instead of guessing. Choosing wrong would file one conversation under another's summary, quietly.
It reads the real conversation
Every handoff starts with safe automatic capture. Pantheon uses a verified local adapter when the calling client has one; otherwise the agent automatically sends every real turn still visible to it.
It distils a packet on top
A short summary, the artifact list, and the tail of the conversation, so a resuming agent gets its bearings in a few hundred words instead of loading a megabyte it may not need. The packet is a layer over the archive, never a replacement for it.
It appends rather than replaces
Hand the same chat off again and Pantheon matches what it already holds turn by turn and stores only the new tail. Hand off a different chat and it becomes another session in the same space. A space accumulates; it never truncates.
It saves and reports back
Every handoff is written to your vault, and it reports which conversation it read — so if it took the wrong one, you see that immediately rather than a fortnight later. If synchronization fails you are told, rather than being left believing something was saved.
Resuming does not pour the archive into the model. It hands over a complete map and lets the agent fetch the territory:
The space packet
handoff.md — the space's own summary, rebuilt when a conversation ends.
Every durable fact
memory.md in full, accumulated across every handoff this space has ever had.
The story so far
The packets from earlier handoffs, oldest first, so the narrative survives a short final session.
A map of the archive
Every session with its turn count and dates, plus the total the space holds. Each one can be opened directly.
The file list
Artifact names across every session, fetched on demand rather than loaded up front.
The map matters as much as the summary. A space that has been handed off five times holds five conversations, and the packet only describes the last of them — so resume states how many turns exist in total and names every session, which stops an agent concluding that a thin packet is all there ever was.
For one question, /pantheon-retrieve <space> <question>establishes question-scoped context without a separate resume. It ranks connected evidence from the entire space, verifies the strongest citations with pantheon_get_turns, and answers with session_id#turn_id provenance.
Natural-language questions always start with pantheon_retrieve, including requests for an unknown name, path, command, or quote. pantheon_search is the literal lookup used only after exact text is already known. From either path the agent can open a surrounding turn range, read a whole conversation with pantheon_get_session, or fetch a stored file with pantheon_get_artifact.
That is the difference from pasting a summary into a new chat. A summary is all you get. A space is a packet you can open.
Everything above is memory: what was said, what was decided, what was produced. A skill is the lesson that should change the next agent before it starts — and Pantheon drafts those from the archive after a handoff.
How Pantheon finds skillsThe most useful thing you can hand a colleague is rarely a document. It is the conversation where the thing was worked out — the approaches that failed, the output that explained why, the file that ended up right. Until now the only way to pass that on was to describe it.
From Settings → Sharing you can give one space to another Pantheon user. GitHub users share with their GitHub username; Google Drive users share with the Pantheon handle on their Account page. You confirm the person before the grant. It appears in their list marked Shared by @you, and — this is the part that matters — it resumes in their agents by name, exactly as their own spaces do.
One space, not the vault
You choose which space to hand over. Every other space in your vault stays invisible — the guest is given only the folder you named.
The whole thing, not a summary
They get the packets, the durable facts, every archived conversation, and the stored files. Their agent can search a tool call from three weeks ago and open the turns around it.
In their agents, not just the browser
Their CLI pulls shared spaces alongside their own, so /pantheon-resume and /pantheon-retrieve owner/space <question> work in Cursor, Claude Code or Codex. A bare name resolves when only one space matches, and asks when more than one does.
Read-only, and refused at the vault
A guest can resume, retrieve, search, and open anything. Handoff, park and remember all refuse before writing. Drafts stay private to the owner — a guest sees only the skills you promoted.
Read-only is enforced where it cannot be worked around: a handoff aimed at a space you do not own is refused when the path is resolved, before anything is written, rather than being hidden from a menu. A guest reading your space never touches your working copy either — the server answers them from a separate clone, so nothing they do can collide with a handoff you are making at that moment.
Revoking is immediate and it reaches their machine. Access stops at once, and the next time their CLI syncs, the local copy is deleted rather than left behind — the files are only ever a cache of a permission you still hold.
Developers can use a private GitHub repository created with a temporary broad token that is immediately revoked, followed by a repository-scoped GitHub App installation. Writers, researchers, designers, and product teams can use a visible Pantheon Vault folder under Google's drive.file scope. Every space is a folder. Conversation content is never stored as a separate database archive — the database holds account, pairing, sharing, and encrypted provider credentials.
One honest caveat: when a browser agent talks to the hosted endpoint, the server temporarily materializes the needed vault files for the length of that request. It does not write a second conversation archive to the database, and the hosted endpoint never reads anything on your machine.
The pattern is always the same — work that is worth more than one sitting — but it shows up in very different places.
You have spent an hour narrowing a Safari login loop and the model you are on keeps circling. Hand the thread off, open a different one, and it starts with every failed hypothesis already ruled out instead of suggesting them back to you.
/pantheon-handoff safari-loginA refactor started in Cursor and needs Claude Code's terminal. Both read the same vault, so the second one picks up the same file list and the same reasoning about why the first three attempts were abandoned.
Long sessions degrade before they end. Hand off at the point it is still sharp, start a fresh chat, resume. The new chat gets a short packet and can read any earlier turn on demand rather than carrying all of it.
The code is still there; the argument about why it looks like that is not. A space keeps the argument — including the options you rejected, which no commit message records.
/pantheon-resume checkout-rewriteYou only need the reason behind one old decision, not the full project briefing. Retrieve from the entire space, verify the strongest exact turns, and get an answer with citations in the current chat.
/pantheon-retrieve checkout-rewrite Why did we reject the first checkout flow?One fact at a time, without dumping the chat. Durable notes accumulate in memory.md and every later resume of that space starts with them.
/pantheon-remember api-v2 Safari is 40% of prod trafficDo the hard thinking wherever it is best, then hand off and let something smaller carry out the mechanical part with the full plan in front of it.
Resume the same space in both and they start from an identical position. The differences you see are the models, not the briefing.
Park the incident chat while you are still firefighting. Days later the writeup is drawn from the real sequence of commands and outputs rather than memory.
/pantheon-park incident-0412Nothing runs on your machine, so there is no session file to read. Reading is lossless in both directions — it is only what a web agent writes back that is reduced.
Pantheon has no model of its own and no conversation UI. You keep using whichever agents you already like; this is the continuity layer underneath them.
You can hand a space to another Pantheon user and their agents can read all of it, but nobody writes into a space they do not own. There is no shared vault two people hand off into — one account owns each space, and the sharing is a read.
Env files, keys and certificates are never archived, whatever named them — vaults synchronize beyond the current machine. Nor are dependency and build directories, unrelated scratch files, subagent side-threads, or anything over the eight-megabyte per-file cap. When a file this session made is too big to store, the handoff says so by name instead of leaving you to notice.
Choose a private GitHub vault for development or a visible Pantheon Vault folder in Google Drive for knowledge work.
Use Pantheon when you need to
Move from Cursor to Claude, Codex, or another desktop agent without explaining the work again.
Leave a tired context window without losing decisions, failed approaches, or files.
Share one read-only space instead of writing a summary that drops the evidence.
Turn recurring project lessons into reviewed skills the next agent can fetch when needed.
Context continuity
Pantheon gives desktop agents a continuity layer outside any one context window: the conversation, decisions, files, and reviewed lessons persist, while each new agent loads only what the current task needs.
Long context stores more tokens. Context continuity carries forward the work.
Leave a tired context window without losing the decisions and evidence that made the work coherent.
Resume the same space in another desktop agent through a common MCP tool surface.
The next agent starts with a bounded packet, then searches the underlying turns and files when it needs proof.
An agent remembers nothing of the conversation you had with it yesterday, or the one running in the next window. Whatever you explained, you explain again.
Long sessions degrade before they finish. You open a fresh one to get the quality back, and the reasoning that got you this far does not come with it.
It is a description of a conversation, written afterwards, by the participant with the worst memory of it. The command that failed, the output that explained why, the file that was finally right — none of that survives the retelling.
There has never been more supply of code. What stays scarce is why it looks like that: the three approaches you rejected, what broke last time, what the customer actually said.