↖ Back to writing

The Session Is Single-Player

A carefully maintained AI memory helps one person work with an account. Colleagues need that context too. My session archive grew into shared support investigations and account playbooks that people can use from their own AI sessions.

8 min read

An account manager spends months teaching an agent how to work with their customers. They correct a draft that sounds too familiar, explain who makes the technical decisions, and record a commitment from the last meeting. Some of that ends up in a carefully maintained memory file on their laptop. The next draft needs less correction because the context is there.

Then a colleague needs to contact the same account. They open their own Claude or ChatGPT session. The assistant may have access to the CRM and the meeting notes. It does not necessarily have the guidance the account manager has spent months refining.

Think of two contacts at the same customer. One wants enough technical detail to reproduce a problem. The other needs a short account of its impact and the next update time. Knowing the company name does not tell an assistant which reply to write. Someone on the team already knows, and may already have written that down for their own assistant.

This is where personal AI memory starts to create a team dependency. The person with the best-maintained context becomes the person everyone needs to ask before writing to the customer. Their assistant helps them work faster. Their colleagues still wait for them.

I came to this problem through support investigations. The first version was about keeping my own work. It grew into two services: one for sharing investigations and distilling what they found, and another for maintaining account and contact guidance.

I Started by Keeping the Sessions

I built CMS, now called Context Management Service, to archive agent sessions. A long investigation contains more than the answer at the end. It contains the query that ruled something out, the response that changed the diagnosis, and the correction I made when the model followed the wrong lead. I wanted to be able to find that work again.

The archive lives in a local database. I can search it by what the investigation was about, then read the relevant part of the session. For archived Claude Code sessions, I can also restore the transcript and resume it. The archive makes transcripts from other agents searchable too.

That made previous work available to me. It did not give a colleague a way to search it. Sharing an investigation still depended on me finding the session and passing the useful parts along.

At the offsite I wrote about earlier, teams also built ways to capture and share the reasoning from their AI sessions. People wanted to see how someone reached a conclusion. A final answer was often too little to continue from.

The Next Investigator Needs Two Ways In

The support service gives colleagues access to selected investigations from the archive. Eligible support sessions go through a publication path that checks for secrets and redacts or rejects material before sharing it internally. The personal archive stays local.

A colleague can read the investigation in their own session and inspect what happened. They are not joining my running agent. They are getting a record they can use to continue the work with their own tools and access.

Reading an entire investigation is expensive when all you need is the diagnostic step that settled it. So the other route is a distilled card. It records the symptom, what to check in the current data, the root cause found in the earlier case, and the resolution. The underlying investigation remains available when the short version is insufficient.

A matching symptom is a starting point. Similar failures can have different causes, so the card needs a checkable signature: something the next investigator can compare against this case before applying the fix. It also needs to distinguish an extracted finding from a reviewed conclusion. Distilling an answer does not establish that it was correct.

That gives the next person a choice. Start with the card when the problem looks familiar. Read the investigation when the reasoning needs checking. Both routes reduce the amount of work that has to pass through the person who originally did it.

Account Memory Has a Different Author

Account playbooks grew from the same sharing problem, but the material needs different treatment. An investigation can supply observations for a model to extract. Guidance about how to handle an account needs the people responsible for that relationship to write and maintain it.

The playbook holds the context an account manager or CSM would otherwise repeat before a colleague takes a meeting or drafts a reply. What has been agreed? Which conversations are still open? Who should handle an escalation? Is there something in the CRM that we already know is wrong?

Contact notes add the detail that an account-level summary misses. They record a person’s decision role, preferred channel, communication style, and the level of detail they need. Guidance can differ between two people at the same company. The lookup for a contact returns their handling notes together with the account playbook, so the draft can use both.

These are internal preparation notes. An assistant should use them to choose an appropriate approach, without quoting the handling guidance to the customer. A note about a contact’s preference for concise updates should produce a concise update.

The browser interface and the assistant’s tools read the same maintained record. People can work in separate sessions and still fetch the account guidance their colleagues have contributed. This does not require copying everyone’s personal memory into everyone else’s assistant. The shared part has an account, an owner, and a place to be corrected.

A Correction Needs to Reach the Next Session

Sending a colleague a memory file helps once. After either person edits their copy, there are two versions to keep aligned. A customer changes who owns the technical relationship, one person updates their file, and the other keeps drafting from the old one.

The account-playbook workflow starts with a proposed change. After a meeting, a person can ask their assistant to read the notes and suggest specific updates, with links back to the source. They inspect the before-and-after and confirm what should be saved. The update carries the author’s name and a date. The next session that fetches the playbook receives the revised guidance.

The person still has to decide what belongs there. A meeting agenda does not become permanent account context because an assistant can summarize it. A commitment may belong in an open thread. A correction to the escalation path belongs in the handling guidance. Deciding which is which takes familiarity with the account.

Keeping it useful also means deciding what should stay elsewhere. The playbook points to the source of a live metric instead of preserving last week’s number. Verified facts carry their own verification dates. Confirming that the overall playbook is still useful does not make every old fact newly checked.

There is an owner and a review queue, so maintaining the record becomes assigned work. An account with no authored playbook is reported as unwritten. The assistant should not turn missing guidance into a confident assertion that there is nothing unusual to consider.

Sharing Context Does Not Require Sharing Every Turn

I initially put several needs under the heading of sharing a session. Working through them produced different requirements.

Two people steering an agent at the same time need a live collaboration interface. Someone taking over an investigation needs enough history and access to continue it. Branching an investigation and bringing the findings back raises another set of questions about conflicting changes and conclusions. Shared account memory can be useful without solving any of those execution problems.

The services I built cover shared knowledge and parts of handoff. They do not merge concurrent agent runs or let two people control the same live session. A transcript preserves the conversation; continuing a process may also require its files, credentials, and running tools.

For customer-facing work, I think the separate-session case deserves more attention. An account manager preparing a renewal and a support engineer drafting an incident update have different tasks. They need the relevant account context to agree, even though their conversations with the model should go in different directions.

A shared playbook gives them somewhere to start and somewhere to put a correction. Whether either draft uses that guidance well still needs checking.

The Team Has to Be Able to Maintain It

In When Your Skill Needs to Graduate, the tool outgrew a personal session because other people needed to review and reuse its output. CMS followed a similar path. Preserving a session helped me return to my work. Sharing investigations helped colleagues reuse it. Account playbooks made room for context that the people handling the relationship need to curate themselves.

A carefully maintained personal memory file is useful evidence of what belongs in that record. It shows which details someone kept having to teach the assistant. Making those details available to a team takes ownership and review, along with a way to retrieve them before the next conversation.

The colleague covering an account should be able to prepare a reply from guidance the team has already established. They may still need help with a difficult judgment. They should not need the account owner to repeat everything their assistant already knows.

If your customer-facing team is maintaining account context in separate AI sessions, reach out at hello@escapecommand.com.