How to Save Your Work Between Claude Accounts (Brain Keys)

Prefer to watch?

▶ Watch this guide as a video (4:06)Browse all 315 videos

▶ Watch on its own page (4:06), with the transcript · More videos in the library →

Key Takeaways

Every Claude account starts each chat completely blank, so switching accounts or hitting a usage limit wipes out all context. Brain keys solve this by storing session state in a shared Postgres table called pr_brain that any account can read and write. Four keys carry a full session: SESSION_CURSOR, SESSION_LOG, ACTIVE_WORKSTREAMS, and OPEN_ITEMS. Any account that reads those four keys is caught up in under a minute and can continue right where the previous account stopped.

• Claude has no shared memory between accounts or chat sessions, so state must live outside the conversation.
• A Brain key is a named row in a single Postgres table that any account can read or write.
• Four keys (SESSION_CURSOR, SESSION_LOG, ACTIVE_WORKSTREAMS, OPEN_ITEMS) carry everything needed to resume a session.
• Account A claims work, updates the cursor as it goes, and journals decisions in real time, not at the end.
• Account B runs the boot protocol, reads the four keys, and picks up from the cursor’s next step in under a minute.
• Key naming conventions (live, learnings, known_bug, backup, SR_SCRIPT) make keys findable without searching through notes.
• Rules like “save on outcome” and “live state lives in the database” keep the system reliable across seats.

Why Claude Accounts Lose Your Work and What to Do About It

Every Claude account starts each chat with zero memory of anything another account or a previous session did. There is no shared context, no handoff log, and no way for one seat to read what a different seat decided. When you switch accounts, hit a usage limit, or lose a connection mid-task, the next account that opens the chat knows nothing: not the decision you made an hour ago, not the step the previous account was on, not the bug it already ruled out and set aside. The fix is to stop storing your working state in the conversation itself and move it into a shared database table that any account can reach. At PushLeads we call that table pr_brain, and the individual rows in that table are Brain keys. Once your state lives there instead of in chat memory, switching accounts stops costing you anything. The next account reads the same rows, sees the same picture, and continues from exactly the right step. This post walks through how that works in practice: what the four session keys hold, how the first account saves as it goes, how the second account recovers in under a minute, and the naming and writing rules that keep the whole system trustworthy.

Chat Memory Versus the Brain: Understanding the Core Problem

Chat memory is locked to one account, disappears when the session drops, and no other seat can read it. The Brain is a shared database table that any account, any seat, can read and write at any time, with every change versioned in a history table so nothing is ever silently lost. That difference changes everything about how you run multi-account or long-running Claude work.

Why does Claude forget everything when I switch accounts?

Claude stores context only inside the active conversation window of a single account. When that conversation ends, or when a different account opens a new chat, there is no mechanism to carry that context over. The model does not have access to what a different account typed or decided. This is a design boundary, not a bug, and the only way around it is to externalize your state before the session ends.

What happens to my work when I hit a Claude usage limit mid-task?

When a Claude account hits its usage limit, the chat session effectively becomes unavailable until the limit resets. Any decisions, steps completed, or bugs ruled out that existed only in that conversation are gone for practical purposes. If you had been writing intermediate results to an external table like pr_brain as you went, a second account could open a fresh chat, read those rows, and continue without starting over.

Is there a way to share Claude context between two accounts at the same time?

There is no native Claude feature for sharing context between accounts. The workaround we use at PushLeads is a shared Postgres table that both accounts have credentials to read and write. Each account writes its current state to named rows in that table as it works, and any other account can read those rows at any point. The table acts as the persistent layer that Claude itself does not provide.

What a Brain Key Actually Is

A Brain key is a single named row in the pr_brain Postgres table. It has a key name and a value, which can be plain text or JSON. The name is unique, so writing to the same key name again updates the row instead of creating a duplicate. Each key also carries a category such as sessions, learnings, or known_bugs, and a priority field. A database trigger copies every change into a history table, so you always have a record of what changed and when.

What is stored in a Brain key value field?

A Brain key value can hold plain text for simple notes or JSON for structured data like a list of workstream owners or a multi-field cursor object. Because the value is flexible, you can store a short decision note or an entire driver script in the same table. The key name and category fields are what make individual rows findable without having to parse every value in the table.

This is part of our AI Overview tracking guide.

How does the history table prevent data loss?

A database trigger fires every time a row in pr_brain is written, and it copies the previous value into a separate history table before the update lands. That means you can always look back at what a key held before the most recent write. If an account overwrites something by mistake, the prior version is still in the history table. Nothing is silently lost because the trigger runs automatically at the database level, not in application code that could be skipped.

Can I store credentials in a Brain key?

We keep credentials out of chat conversations entirely. The rule is to reference the key name in the conversation, not the credential value itself. The actual secret lives in the database row, accessed by the account with appropriate database permissions, but you never paste or repeat the credential text in the chat window where it could be logged or exposed. This keeps sensitive values out of Claude’s context entirely.

The Four Keys That Carry a Whole Session

Reading four specific Brain keys is enough to fully reconstruct what was happening in a previous session and pick up from the right step. SESSION_CURSOR holds the task, the current step, and what comes next. SESSION_LOG for today holds the decisions, corrections, and the reasons behind them. ACTIVE_WORKSTREAMS records which seat owns which job right now. OPEN_ITEMS is a single consolidated list of everything unfinished. Any account that reads those four rows is caught up in under a minute.

What does SESSION_CURSOR store exactly?

SESSION_CURSOR holds three things: the task that is currently in progress, the step the previous account was on when it last wrote the cursor, and the next step to take. Keeping all three together means a new account does not have to infer where work stopped. It reads the cursor and knows the task, knows what was just done, and knows exactly what to do next. The cursor should be updated every time the task or next step changes, not just at the end of a work block.

Why does SESSION_LOG use a date in the key name?

Logging decisions into a dated session log, such as SESSION_LOG_2025_06_15, means you can read the last two logs and get decisions and corrections across two days without reading every log ever written. If all decisions went into a single key, it would grow without bound and become expensive to read. The date suffix also lets a new account quickly find the most recent context by looking for the two most recent dated keys in the sessions category.

How does ACTIVE_WORKSTREAMS prevent two accounts from colliding?

ACTIVE_WORKSTREAMS is a structured value, usually JSON, that maps seat identifiers to the jobs they currently own. Before an account starts working on a task, it checks this key to see if another seat has already claimed that job. If no other seat owns it, the account adds its own entry and proceeds. If another seat is listed as the owner, the accounts coordinate through the Brain before either one continues. This prevents two accounts from writing conflicting changes to the same system at the same time.

How Account A Saves Work While It Goes

The first account follows five steps as it works. It claims the work by adding its seat identifier to ACTIVE_WORKSTREAMS. It updates SESSION_CURSOR every time the task or next step changes. It journals decisions as they happen in real time, one to three lines in the current day’s session log, not in a batch at the end. It backs up any driver script or config to a backup key before editing it. And it logs every shipped change as one row in the changelog. Doing all five in real time means the state in the Brain is always current, not a summary written after the fact.

Why journal decisions in real time instead of at the end?

If an account writes decisions only at the end of a work block, and the session drops before that write happens, all the reasoning from that block is gone. Writing one to three lines to SESSION_LOG each time a decision is made means the log is always accurate up to the last completed step. A new account reading the log sees what was decided and why, not just a status update that says work is in progress.

What goes into a backup key before editing a driver?

Before touching a live driver script or configuration, the account copies the current value into a key following the naming pattern BACKUP_DRIVERNAME_DATE. That row holds the version that was working before any edits started. If the edit introduces a problem, the prior working version is in the Brain and can be restored without digging through version control or trying to reconstruct what the script looked like. The backup write takes one database operation and prevents a whole category of hard-to-recover mistakes.

What is the changelog and how often should it be updated?

The changelog is a Brain key that holds a sequential list of shipped changes, with each entry being one row describing what changed, when, and which seat shipped it. It should be updated every time something actually deploys or changes in production, not on a schedule. Reading the last twenty changelog rows gives any account a clear picture of what has actually shipped recently, which is more reliable than trying to reconstruct history from memory or conversation context.

Key Naming Conventions That Make Things Findable

Key names follow a prefix pattern so that any account can identify what a key is for without reading its value. Keys ending in _LIVE hold the current contract for a running system. Keys in the learnings category record something that proved a previous rule wrong. Keys in the known_bugs category are bugs that are documented but not yet fixed. Keys following the BACKUP pattern are pre-edit copies. SR_SCRIPT keys are runnable driver scripts, including the boot script itself. Following these patterns consistently means a new account can scan the key list and understand the landscape without needing a separate index.

What is a LIVE key and why does it matter?

A LIVE key holds the current authoritative definition of a running system, such as the schema for a database table or the interface contract for a service. Any account that needs to know how the system is structured reads the LIVE key rather than trusting a document that might be out of date. The LIVE key is updated whenever the system itself changes, which keeps it accurate. Documents and notes can drift; the LIVE key reflects what is actually running.

What is the difference between a learnings key and a known_bugs key?

A learnings key records a case where something that was assumed to be true turned out to be wrong, such as a library behaving differently than documented or a service having an undocumented rate limit. It updates the working model for future decisions. A known_bugs key records a specific defect that exists in the current system but has not been fixed yet, so future accounts know to work around it rather than spending time diagnosing it again. Both categories prevent repeated discovery of the same information.

What is an SR_SCRIPT key used for?

SR_SCRIPT keys hold executable driver scripts that accounts can run directly, such as the boot script that rebuilds the system snapshot at the start of each session. Storing scripts in the Brain means every account runs the same version and there is no risk of a local copy being out of sync with what the rest of the system expects. When the boot script is updated, the new version goes into the SR_SCRIPT key and every account that runs boot from that point forward uses the updated script automatically.

How Account B Picks Up the Work in Under a Minute

The second account follows a defined sequence to recover. First, it runs the boot protocol, which reads the SR_SCRIPT boot key and rebuilds the system snapshot. Second, it reads SESSION_CURSOR and ACTIVE_WORKSTREAMS to see what the last seat was doing and what is claimed. Third, it reads the last two dated SESSION_LOG keys to get decisions and corrections, not just the current status. Fourth, it reads the last twenty changelog rows to see what has actually shipped. Then it claims its seat in ACTIVE_WORKSTREAMS and continues from the next step listed in the cursor. The cursor makes recovery a one-line instruction: read the cursor and continue from its next step.

What does the boot protocol actually do?

The boot protocol is a script stored in an SR_SCRIPT key that reads the current state of the Brain and reconstructs the system snapshot the account needs to operate correctly. It pulls the LIVE keys for all relevant systems, reads active workstreams, and sets up whatever local context the account needs before it starts working. Running boot at the start of every session ensures the account is working from current state, not assumptions carried over from a previous session that may no longer be accurate.

Why read two session logs instead of just the most recent one?

Decisions made near the end of one day’s log often set up the next day’s starting point. Reading only the most recent log can miss context that explains why the cursor is positioned where it is. Reading the last two logs gives a complete picture of recent decisions and corrections without having to read the full history. Two logs is usually enough context for a new account to understand what was tried, what was decided, and why the next step is what it is.

What if the cursor shows a step that was already completed?

If the cursor shows a step that looks completed based on the changelog, the new account checks the changelog to confirm the step shipped, then reads the cursor again to see if the next step field points forward. A well-maintained cursor is updated as soon as a step finishes, so the next step field should reflect current reality. If there is a discrepancy between the cursor’s next step and what the changelog shows as shipped, the new account journals the discrepancy in SESSION_LOG before proceeding rather than assuming either source is correct.

The Rules That Keep the Brain Reliable

Four rules prevent the Brain from becoming unreliable over time. Save on outcome: write to the Brain when something is fixed or decided, not after a block of work or at the end of the session. Live state lives in the database: never trust a document or your memory for what is actually running right now. Do not race a live run: if another seat owns a job in ACTIVE_WORKSTREAMS, coordinate through the Brain before proceeding. Keep secrets out of the chat: reference the key name in conversation, not the credential value itself. Following all four rules consistently is what makes the Brain trustworthy enough that any account can pick up any work.

What does “save on outcome” mean in practice?

Save on outcome means writing to the Brain at the moment something changes, not on a timer or at the end of a session. When a decision is made, one to three lines go into SESSION_LOG immediately. When a step finishes, SESSION_CURSOR is updated immediately. When something ships, one row goes into the changelog immediately. This pattern ensures that if the session drops at any point, the Brain reflects everything that actually happened up to the last completed outcome rather than holding a stale snapshot from whenever the last scheduled write happened.

Why can’t I just use a shared document instead of a database table?

A shared document can hold state, but it does not version every write automatically, it does not enforce unique key names, and it is easy to accidentally overwrite or delete content without a trace. A Postgres table with a history trigger gives you automatic versioning on every write, unique key enforcement at the database level, and the ability to query the history table when you need to see what a key held before its last update. Documents work for notes; a database table is more reliable for state that has to be current and auditable.

What happens if two accounts write to the same key at the same time?

Postgres handles concurrent writes through its standard transaction and locking mechanisms, so one write will land first and the second will land after it, not simultaneously. The result is that one account’s write wins and the other’s follows. The history table captures both writes in sequence, so neither is lost. To prevent meaningful collisions, the ACTIVE_WORKSTREAMS key is used to coordinate ownership before either account starts writing to shared session keys, reducing the chance that two accounts are writing to the same key for conflicting reasons.

Frequently Asked Questions

What is a Brain key in the context of Claude accounts?

A Brain key is a named row in a shared Postgres table called pr_brain that any Claude account can read and write. It has a unique key name, a value that can be plain text or JSON, a category, and a priority. A database trigger copies every change into a history table. The key name is what makes a row findable, and writing to the same name again updates the row rather than creating a duplicate.

How many Brain keys do I need to carry a full Claude session?

Four Brain keys carry everything a second account needs to fully reconstruct a session: SESSION_CURSOR for the current task and next step, SESSION_LOG for the day’s decisions and corrections, ACTIVE_WORKSTREAMS for seat ownership, and OPEN_ITEMS for everything unfinished. Reading those four rows takes under a minute and gives any account enough context to continue from exactly the right step without asking for a status update.

Does the Brain work if I am using more than two Claude accounts?

Yes. ACTIVE_WORKSTREAMS is designed to handle multiple seat identifiers simultaneously. Each account claims its job in that key before starting and releases it when done. As long as accounts coordinate through ACTIVE_WORKSTREAMS before starting work on a shared task, any number of accounts can use the same Brain without colliding. The history table keeps a complete record of all writes regardless of which account made them.

How do I set up pr_brain if I do not already have a Postgres database?

You need a Postgres instance that all participating Claude accounts can reach with valid credentials. The table structure is straightforward: a unique key name column, a value column that accepts text or JSON, category and priority columns, and a timestamp. The history table needs key name, value, and a write timestamp. A database trigger on the main table inserts a row into the history table on every update. A Postgres instance on any cloud provider that supports connection strings works for this setup.

What should I do if the SESSION_CURSOR is out of date when I pick up a session?

Read the last two SESSION_LOG keys and the last twenty changelog rows first, then compare what they show was completed against what the cursor’s next step says. If the cursor is behind the changelog, update the cursor to reflect actual current state before proceeding, and journal the correction in SESSION_LOG so the next account knows what happened. Keeping the cursor accurate is the responsibility of each account as it works, not just the last one in the session.

Can I use Brain keys for things other than session continuity?

Yes. The same table works for learnings that update your working model, known bugs that should not be re-diagnosed, backup copies of driver scripts before edits, and runnable scripts stored in SR_SCRIPT keys. Any information that needs to survive beyond a single chat session and be accessible to more than one account is a good candidate for a Brain key. The category and priority fields help you organize keys by purpose so the table stays navigable as it grows.

How do I keep the Brain table from growing too large over time?

The main table stays small because key names are unique and writes update existing rows rather than creating new ones. The history table grows over time and should be pruned on a schedule, keeping recent history and archiving or deleting older rows based on how far back you realistically need to look. For most small business use cases, keeping 90 days of history in the table and archiving anything older is enough to cover any realistic recovery need.

Is this approach specific to Claude or does it work with other AI tools?

The Brain key pattern works with any AI tool that can read from and write to a Postgres database through a connection string or API, because the persistence lives in the database, not in the AI tool itself. Claude accounts use it because Claude’s stateless chat model makes external state storage necessary, but the same table and the same four session keys could serve any other tool that has the same stateless-session limitation.

Put Your State in the Brain Before You Need It

The biggest mistake I see is waiting until a session drops to think about continuity. By then the work is already gone. The Brain key system only works if you are writing to it as you go: update the cursor when the step changes, journal the decision when it is made, claim your seat before you start, back up the driver before you edit it. Do those five things consistently and switching accounts becomes a non-event. You boot, read four keys, claim your seat, and pick up from the cursor’s next step. The work does not restart. The reasoning does not disappear. The bugs you already ruled out stay ruled out. For small businesses and home service contractors running complex tasks across multiple Claude accounts or sessions, this kind of structured continuity is the difference between work that compounds and work that resets every time something interrupts it. If you want help setting up pr_brain for your own workflow, or if you want to talk through how we use it at PushLeads for local SEO and AI search work, reach out to us at https://pushleads.com/contact/ and we can walk through it with you.