About
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 the moment you switch models, hit a context limit, or come back on Monday. Pantheon keeps that, in a private repo you own, so the next agent starts where the last one stopped.
A space is a named store — preorders, annotation-design — and what it holds is called a conscience. 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 in a git repo, you can read them on GitHub without us, 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
On a desktop app, Pantheon runs on your machine and reads the session file the agent already keeps — Cursor, Codex, or Claude Code. It does not ask the model to retype anything, and it rejects a transcript that looks like a recap rather than a log.
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 commits and pushes
Every handoff is a commit in your repo, and it reports back which conversation it read — so if it took the wrong one, you see that immediately rather than a fortnight later. If the push 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.
From there it drills in: pantheon_search to find the moment something was decided — it reads tool calls too, so a file is findable by name even if nobody ever typed that name in prose — then pantheon_get_turns for the surrounding stretch, pantheon_get_session for an entire thread, and pantheon_get_artifact for a stored file.
That is the difference from pasting a summary into a new chat. A summary is all you get. A conscience is a summary you can open.
Everything above is memory: what was said, what was decided, what was produced. A skill is the other thing a project accumulates — a lesson that should change what the next agent does before it does it.
The distinction matters because they are read differently. Memory is fetched when an agent goes looking. Every promoted skill's name and trigger is handed over unasked on resume; its full body is fetched only when the work matches. That keeps the guidance available without pouring every instruction into context.
When a handoff adds turns, the agent reviews recurring signals and batch-saves only justified, non-repeating lessons as drafts. Run /pantheon-skills preorders to review again at any time. Approval still happens here in the UI.
Corrections you had to repeat
A pushback in one conversation is a preference. The same pushback in a later one is a rule nobody wrote down — and that is the clearest signal an archive still holds, because what you typed is always kept.
Procedures that keep coming back
A command run across several sessions is either already documented or is something everyone rediscovers. The review checks your AGENTS.md and README and says which — a lesson already written down does not need a second home.
Failures that recurred
The same command failing the same way in separate conversations, then being worked through each time. Detected without a model where the agent records what its tools returned, which is not most of them.
And what is in the room
The conversation being reviewed, which is the only place the errors an agent hit are still visible. This is usually the strongest evidence and the reason the command exists at all.
The awkward part is worth stating plainly, because it shaped the design. A skill should be written from evidence — the command that failed, the output that said why — and most agents never write that down. Cursor records which tools it called and with what, but not a single one of the results: 26,000 archived turns here yielded 4,732 tool calls and no outputs at all.
So the only witness to what actually went wrong is the agent that was there when it did. That is why a review is a judgement made inside a live conversation rather than a scan run over the archive afterwards. The archive contributes what it reliably keeps — what you typed, and what got run — and the agent contributes what it saw.
Against a model's eagerness to be useful there are three checks. It is told, in the tool itself, that writing nothing is the ordinary outcome. Every claim has to cite the turns it came from, and the vault refuses a citation that does not resolve to a real turn — so a plausible-looking session id that was never there is caught at the point of writing. And nothing it writes is a skill yet: it is a draft, inert, until you read it and promote it.
Twelve live skills per space is the ceiling. Not an arbitrary number — every name and trigger is spent from the context budget of future conversations in that space, so a thirteenth is refused rather than quietly dropped.
The 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 by their GitHub handle. 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 conscience to hand over. Every other space in your repo stays invisible — the guest is never given the repo, 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 works on it by name in Cursor, Claude Code or Codex. A bare name resolves to a shared space when only one matches, and asks when more than one does.
Read-only, and refused at the vault
A guest can resume, 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.
You create one private vault repository in your GitHub account and connect Pantheon only to it. Every space is a folder and every handoff is a commit. You own 100% of the saved context. Conversation content is never stored in our database — it holds your account, paired machines, and the credentials needed to connect to your vault, and that is all.
One honest caveat: when a browser agent talks to the hosted endpoint, the server clones your vault for the length of that request in order to answer it. Nothing is written to our database, and the hosted endpoint never reads anything on your machine — it cannot, which is exactly why a web agent's handoff is a summary.
The pattern is always the same — a conversation 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 conscience keeps the argument — including the options you rejected, which no commit message records.
/pantheon-resume checkout-rewriteOne 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 only the memory 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 conscience, and the sharing is a read.
Env files, keys and certificates are never archived, whatever named them — the vault is a repo that gets pushed. 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.
Create one private vault in your GitHub account and connect Pantheon only to it. Your saved context remains readable and under your control.