How to keep a client's context across Claude sessions (without re-pasting)

How to keep a client's context across Claude sessions (without re-pasting)

You opened Claude Monday morning to draft a follow-up email for Acme Widgets. You typed the prompt. Claude asked who Acme Widgets was. You sighed and pasted the kickoff brief. Again. For the seventh time this engagement.

This is the experience most solo consultants have with Claude across a six-week project. The conversation that knew everything about the engagement on Wednesday afternoon has no idea about the engagement on Monday morning. You re-paste. You re-establish. You spend two minutes loading context before every task. Over the course of an engagement that runs 20 distinct AI-assisted tasks, that's 40 minutes of pure re-paste tax.

The fix is to stop trying to make a single Claude conversation remember the engagement, and instead persist the engagement state in a small set of files Claude can re-load on demand. Three files per client, one folder per engagement, one Claude Project that wraps them. This article is the setup, the files, and the discipline that keeps the system working past week two.

Why a single long conversation isn't the answer

Before the setup, the alternative most consultants try first: keep one big Claude conversation open for the whole engagement, treat it as the working memory, and never start a new one. This is the wrong shape, and the previous article in this series — the context-window mistake most consultants make — covers the failure modes in depth. The short version: the conversation gets muddier over time, output quality slowly degrades, and you don't notice until week three.

The right model isn't "keep everything in one conversation." It's "keep everything in files outside the conversation, and load only what's relevant for the current task." The conversation is the working surface for one task; the engagement lives in files.

The folder structure

Every active engagement gets a folder. The path is convention, not enforced:

clients/
  acme-widgets/
    kickoff-context.md
    running-notes.md
    open-questions.md
    transcripts/
      2026-04-28-discovery.md
      2026-05-05-stakeholder-priya.md
      2026-05-12-engineering-walkthrough.md
    deliverables/
      v1-friction-points-draft.md
      v2-friction-points-final.md
    updates/
      2026-05-09.md
      2026-05-16.md
      2026-05-23.md
    invoices/
      2026-04-28-deposit.md
      2026-06-15-balance.md

The folder lives in your local filesystem — wherever you keep work-in-progress. It doesn't have to be in any specific tool. The files are Markdown. They're readable as plain text, version-controllable (if you want), and indexable by any AI tool.

The three files at the top — kickoff-context.md, running-notes.md, open-questions.md — are the load-bearing ones. They're what you re-paste into Claude conversations when you need the engagement's state.

The three files that do the work

kickoff-context.md — written on day one of the engagement. Doesn't change after week two. Contents:

  • Who the client is (company, industry, size).
  • Who the buyer is (name, role, background, communication style).
  • The stated problem and your read on the real problem.
  • The scope you agreed to and the gray edges.
  • Your hourly floor, your billing cadence, the deposit and balance amounts.
  • The non-obvious context — political dynamics, prior consultants, internal disagreements, the failure modes you're worried about.

This file is your version of the engagement before it's been touched by reality. You re-read it in week 4 when something is shifting and you can't remember why you made the call you made on day one. You paste it into Claude when starting a new task that needs the full engagement context.

running-notes.md — append-only across the engagement. New entries land at the top, dated. Contents per entry:

  • What happened today.
  • What you decided.
  • What you committed to.
  • What you noticed about the dynamics.

This is the file that grows. By week 4 it's the engagement's history in chronological reverse. When Claude needs the engagement's recent state, you paste the top 800 words (the last week of entries). When you write the case study, the running notes are the source for the "specific moments worth remembering" section.

open-questions.md — the only file that gets rewritten frequently. It's the current state of what's unresolved. Format: a bulleted list under three headings.

  • Open with the client (things you've asked them, things you're about to ask them, with date due).
  • Open with yourself (decisions you're deferring, calls you haven't made).
  • Watching (concerns that aren't actionable yet but might be).

This file gets reset every week. Last week's open items either resolved (delete) or stayed open (carry forward) or shifted (rewrite). The discipline of rewriting the file weekly is what keeps the engagement from accumulating quiet unresolved tension.

The Claude Project setup

The three files above are the source of truth. The Claude Project is the surface where you do work on the engagement.

One Project per active engagement. Inside the Project:

  • Upload kickoff-context.md (the unchanging context).
  • Upload running-notes.md (refresh the upload every Friday — drag-and-drop replaces the previous version).
  • Upload open-questions.md (refresh every Monday morning).
  • Upload key transcripts as they happen (discovery call, big stakeholder interviews, the wrap retrospective).

The Project's instructions field gets a short note: "You are helping me work on the [Client Name] engagement. The kickoff-context.md file has the original setup; running-notes.md has the chronological history; open-questions.md has what's currently unresolved. Reference these files when answering. Don't invent details not in the files."

That's it. The Project now knows the engagement. Any conversation you start inside the Project can ask Claude about the engagement and get answers grounded in the actual files.

The instructions note above is the minimal version. If you want the fuller one — plus the standing practice files (ICP, offers and rate floor, voice) that sit alongside the per-engagement uploads — the Claude Project Kit ships both finished, with a worked example to calibrate against.

The disciplines that make it work past week two

The setup above is easy. The discipline that makes it useful past week two is the part most consultants skip.

Rewrite open-questions.md weekly. Friday afternoon or Monday morning, sit with the file for five minutes and prune. Resolved items go away. Stale items get rewritten with new context. Whatever's still actually open stays. The file should be readable in under a minute; if it's longer than 15 items, half of them are no longer open.

Append to running-notes.md after every meeting. Three to five lines, dated. "Stakeholder call with Priya. She's frustrated that Engineering isn't moving on the recommendations from last week. We agreed I'll draft a joint status doc for both teams by Wednesday." That kind of entry. Specific, dated, decided.

Re-upload the files to the Project on a cadence. Friday at end-of-day: re-upload running-notes.md so the Project has the week's history. Monday morning: re-upload open-questions.md so the Project has the current open items. Claude won't see your local edits unless you re-upload; the upload step is the sync.

Don't add files to the Project that aren't load-bearing. A consultant who uploads every email, every Slack message, and every meeting transcript ends up with a Project Claude can't reason over well. Three to five high-signal files beat fifty low-signal ones. If you're not sure whether to upload, don't — the running notes will capture what mattered anyway.

What a running-notes entry actually looks like

The hardest part of the system is establishing the habit of appending to running-notes.md. Five entries from a hypothetical week to make it concrete:

## 2026-05-23 (Friday)

Stakeholder call with Priya. She's frustrated that Engineering
isn't moving on the recommendations from last week. We agreed I'll
draft a joint status doc for both teams by Wednesday.

## 2026-05-22 (Thursday)

Spent 90 min on session recordings with Priya + engineering lead.
At about minute 30 both of them landed on the same friction point.
That moment was the engagement turning point — worth keeping for
the case study.

## 2026-05-20 (Tuesday)

CEO surfaced via Priya: he wants conversion to hit 15% by end of Q3,
not the 12% we'd been targeting. Flagging this for the proposal-doc
revision; we may need to renegotiate scope if the 15% target stays.

## 2026-05-19 (Monday)

Sent the friction-points draft v1. Priya replied within 2 hours
with substantive feedback — she's engaged. Engineering hasn't
acknowledged. Watching for whether silence is approval or
disengagement; will surface Thursday if no response by then.

## 2026-05-16 (Friday weekly update sent)

Subject: Friction-points doc lands Tuesday. On track, no blockers.

The entries are 1-3 sentences each, dated, specific. They take about 90 seconds to write per entry. By week 4, the file is the engagement's history — searchable, paste-able, the source for the wrap retrospective and the case-study harvest. Most engagements that go badly go badly because nobody wrote these notes; most that produce a great case study produced it because someone did.

What this lets you actually do

The payoff is the conversations you have with Claude inside the Project. Specifically:

  • "Draft a follow-up email to Priya summarizing where we are." Claude has the running notes; it knows where you are.
  • "What's the most overdue open question on this engagement?" Claude pulls from open-questions.md.
  • "The CEO just asked for a one-page summary of progress to date. Draft it." Claude pulls from running notes and weekly updates.
  • "Help me think through whether to bring up the engineering pushback at Thursday's call." Claude has the context to actually help, not just produce a generic "here are some considerations."

None of these conversations require you to re-paste the kickoff brief. None of them require you to remind Claude who the client is. The Project remembers because the files are inside it.

The implicit win: the artifacts produced by these conversations are also higher quality, because they're grounded in the actual engagement context instead of generic consulting language.

What not to upload to the Project

The common over-correction once consultants learn that Projects can hold uploaded files is to upload everything. This is the wrong move and degrades output quality fast.

Don't upload: every email exchange with the client. The signal-to-noise ratio is wrong — most emails carry administrative content (scheduling, file links) that bloats the Project's context with text Claude has to skim past.

Don't upload: the full transcript of every meeting. Three or four pivotal transcripts, fine. The weekly check-in transcripts that didn't produce new decisions, not worth uploading. The summary lives in running-notes.md; the transcript itself sits in clients/<name>/transcripts/ and gets pulled in only when a specific conversation needs it.

Don't upload: drafts that have been superseded. Once v2-friction-points-final.md exists, the v1 draft can stay in your folder for record-keeping but doesn't need to be in the Project. The Project should reflect the current state of the engagement, not the full history.

Don't upload: PDFs that are mostly formatted content. Claude reads PDFs, but layout-heavy ones (slides, branded reports) are noisier than the underlying text. Convert to Markdown or paste the relevant passages into a .md file.

The rule of thumb: three to five high-signal files per Project beat fifty low-signal ones. If you're not sure whether a file belongs in the Project, leave it out. You can always upload later when a specific conversation needs it; you can't easily un-upload once Claude is reasoning across noisy context.

Where the procedure fits

The folder structure above is part of the operational shape covered in The Solo Operator's SOP Bundle. The SOPs reference clients/<name>/ paths because the SOPs assume you have one. If you don't yet, the kickoff procedure (SOP 01) creates it; the weekly update procedure (SOP 02) maintains it; the retrospective (SOP 04) closes it. The Bundle is the operational system; this article is the Claude-side setup that lets the system run.

For the broader operating model — when AI is the right tool for client work, when it isn't, and how to make the leverage real — The Solo Consultant's AI Playbook is the reading. The Playbook gives you the framing; this article is the specific setup for the file/Project layer of the framing.

The smallest move you can make today: pick one active engagement, create the folder, write the three files (maybe 20 minutes total). Start one Claude Project for it. Upload the files. Run your next task inside the Project. The difference in output quality, from the first task, is the proof.

Back to blog