Claude Cowork Now Remembers Your Chat Context

By Lazar Milicevic · Published September 15, 2026 · 9 min read

You brief Claude on your codebase in the chat app on Monday. Tuesday you open Cowork to run an agent against the same repo and it has no idea what you told it — the naming conventions, the deploy target, the client's "don't use emojis in Slack" rule. You paste the context again. And again next week. Anthropic is finally fixing this: Claude now shares memory across chat and Cowork, which changes how you should design agents that actually retain project state.

If you build automations for a living, this is not a UI tweak. It's a shift in where context lives, who owns it, and how you architect a multi-agent workflow that doesn't leak knowledge between surfaces.

What actually changed

Claude previously kept memory siloed. The chat app had its own "projects" and memory features. Cowork (the agentic workspace where Claude runs tasks, edits files, and coordinates subagents) had its own working context per session. The two didn't talk. If you told chat "we ship on Fridays, staging deploys need approval from Priya," Cowork was blind to it.

The new model treats memory as a user-scoped store that both surfaces read from and write to. Practical implications for a builder:

• Context you drop into chat during a planning conversation is available when you kick off a Cowork run against the same project.
• Preferences ("always use pnpm, never npm", "our style guide forbids default exports") persist across surfaces.
• Corrections you make in one place — "no, our production DB is in us-east-2, not us-west-1" — should not need to be repeated in the other.

The important thing: this is shared user memory, not a shared agent runtime. Two agents in Cowork still have separate short-term working memory. What they share is the persistent facts about you, your projects, and your preferences. That distinction matters when you design workflows.

Why this changes agent architecture

Before this shift, if you wanted persistent project context in a Claude agent, you had three ugly options:

1. Stuff a giant system prompt into every run. Expensive, brittle, and it truncates when the prompt drifts near the context limit.
2. Build your own memory layer — vector store, retrieval, injection at runtime. Works, but you own the plumbing.
3. Paste context into the chat and pray the user does the same in Cowork.

Now you can lean on Claude's own memory for the boring stuff (preferences, glossary, project facts) and reserve your custom memory layer for the parts you actually need control over: audit trails, structured business data, RAG over documents.

Here's the mental model I use now when designing an agent:

memory_layers:
  claude_native:
    purpose: user + project preferences, style rules, glossary
    updates: conversational, by the user
    trust: medium — good enough for tone and defaults
  app_owned_kv:
    purpose: structured facts (client IDs, invoice states, deploy targets)
    updates: programmatic via MCP tools
    trust: high — audited, versioned
  rag_store:
    purpose: docs, tickets, historical decisions
    updates: nightly sync + on-demand
    trust: medium-high — cited in outputs
  session_scratch:
    purpose: current task state
    updates: agent working memory
    trust: ephemeral

The mistake I keep seeing is teams pushing everything into layer one because it's new and shiny. Don't. Claude's shared memory is great for "Priya prefers Loom over meetings." It's not where you store which invoices are unpaid.

The concrete win for solo builders and small teams

If you're a solopreneur running Claude across chat (for thinking, drafting, planning) and Cowork (for actually executing tasks against a repo or docs), the daily friction was re-briefing. A realistic before/after for a two-person consultancy running ~15 agent tasks a week:

The biggest saving isn't tokens — it's the cognitive tax of remembering what you already told the AI. For a solo operator running five to ten sessions a day, that's the difference between the tool feeling like a colleague versus an intern who forgot everything overnight.

How to actually use it without getting burned

Shared memory is a foot-gun if you don't have hygiene. A few rules I now bake into every Claude-based project I build for clients:

1. Be explicit about what goes into memory. Don't let it be implicit. When you want Claude to remember something long-term, say so: "Remember for this project: our production database is Postgres 16 on RDS in us-east-2." Otherwise you'll find it "remembered" something offhand you said once and now defaults to it.

2. Audit memory periodically. Ask Claude what it remembers about a project. Read it. Delete what's stale. This is a five-minute weekly ritual, not optional. Stale memory is worse than no memory because it looks authoritative.

3. Separate personal from project memory. "I prefer bullet lists" is personal. "Client X uses Stripe Connect for payouts" is project-scoped. Keep them logically distinct in how you brief Claude, so pruning one doesn't blow up the other.

4. Never store secrets there. Passwords, API keys, PII beyond what's already in your CRM — none of it. Treat shared memory like a shared Notion doc: assume anyone with access to your Anthropic account can read it, because they can.

5. Version-control the important stuff elsewhere. If a preference matters enough that a future contractor should know it, it belongs in your repo's AGENTS.md or CLAUDE.md, not just in Anthropic's memory. Memory is a convenience layer, not a source of truth.

Here's a CLAUDE.md I now ship in most client repos, which lives alongside whatever Claude has in its own memory:

# Project: acme-invoicing

## Stack
- Python 3.12, FastAPI, Postgres 16
- Deployed via GitHub Actions → ECS Fargate (us-east-2)
- Secrets via AWS Parameter Store, never .env in production

## Conventions
- Use `ruff` for lint/format, not black
- Type hints required on all public functions
- Test naming: `test_<module>_<behavior>_<expected>`

## Do not
- Introduce new runtime dependencies without a note in PR description
- Modify `alembic/versions/*` — migrations are hand-written
- Run destructive SQL from an agent session without explicit approval

## Escalate to human
- Any change touching billing_service.py
- Any migration
- Any commit that changes CI configuration

That file is the contract. Shared memory is the softer layer of "here's how Priya likes her PR descriptions."

Building agents that exploit persistent memory

Where this gets interesting is when you're chaining Claude into an MCP-based agent system. Model Context Protocol lets a Claude agent call your tools — read a database, hit an API, open a ticket. With persistent user memory, your MCP tools can now assume a baseline of context and stop asking dumb questions.

A worked example: a lead-triage agent for a small B2B SaaS. Before, every run started by re-establishing "what counts as a qualified lead for us." Now that lives in memory, and the MCP tool just does the work.

# mcp_tools/lead_triage.py
from mcp import Tool
from typing import Literal

@Tool(
    name="triage_lead",
    description=(
        "Classify an inbound lead as hot, warm, or cold. "
        "Uses the project's qualification criteria from Claude's memory "
        "(company size, tech stack, urgency signals). "
        "Returns the classification plus a one-line reason."
    ),
)
def triage_lead(
    lead_id: str,
    email_body: str,
    company_domain: str,
) -> dict:
    signals = extract_signals(email_body, company_domain)
    # Note: we do NOT re-fetch qualification criteria here.
    # Claude carries them from user memory into the prompt that
    # calls this tool. Our job is to score against what Claude passes in.
    return {
        "lead_id": lead_id,
        "signals": signals,
        "requires_llm_scoring": True,
    }

The tool is now dumber and more reusable. Qualification criteria live where they belong — with the user, in memory — and change without a deploy. When the founder decides "we're going upmarket, minimum 50 seats now," they say it in chat. Next agent run picks it up.

The pattern I encourage: MCP tools should be about capability, not policy. Capability (fetch a lead, send an email, open a PR) lives in code. Policy (what counts as qualified, what tone to use, when to escalate) lives in memory and prompts. Persistent memory finally makes that separation clean.

Where it still falls short

Being honest about limits:

• No team-level memory yet. If you're a two-person shop, you each have your own memory. There's no clean "team knows this" store from Anthropic. For now, that role goes to your repo's CLAUDE.md, a Notion doc, or a shared vector store.
• No structured queries. You can't SELECT against memory. It's read by Claude as context, not queried by your code. If you need "list every preference tagged as 'billing'", build your own KV store.
• Cross-project bleed is possible. If you don't name projects explicitly, preferences from one client can leak into another. Be disciplined about project scoping.
• Audit surface is thin. You can read what Claude remembers, but there's no diff view or change log at the level of rigor an enterprise compliance team would want. For regulated work, keep your own log.
• It's not a substitute for RAG. Memory is for facts and preferences. Documents, tickets, historical decisions — those still belong in a proper retrieval store you control.

Any vendor's memory feature will have these edges for a while. Plan around them; don't wait for them to be perfect.

A migration checklist for existing Claude workflows

If you have Claude-based automations running today, here's the practical work to do this month:

1. Inventory your prompts. Find every long system prompt where you're stuffing user/project context. That's the candidate to move into memory.
2. Split preferences from capabilities. For each prompt, mark which lines are "how we work" (memory candidates) versus "what to do" (keep in prompt/code).
3. Migrate incrementally. Move preferences to memory one project at a time. Test that agent output stays consistent. Don't do a big-bang cutover.
4. Add a memory audit ritual. Weekly, dump what Claude remembers per project. Prune. This is the new "log rotation."
5. Update your CLAUDE.md / AGENTS.md. Everything critical still belongs in the repo. Memory is the soft layer.
6. Document escalation rules explicitly. Now that agents have more baseline context, they'll try to do more. Be sharp about what still needs a human.
7. Re-test your MCP tools. Any tool that used to take a "context" argument because the agent had no memory — consider whether that argument is still needed, and simplify.

If you're starting fresh, design for this from day one. Prompts stay short. Preferences live in memory. Facts live in your KV. Documents live in RAG. Tools do work.

How BizFlowAI approaches this

We build Claude-based agents and MCP integrations for solopreneurs and small teams — lead triage, invoice reconciliation, onboarding doc generation, support routing. Persistent memory is not a feature we bolt on; it's a layer we designed around from the first job. In practice that means every agent we ship has an explicit memory contract (what's stored, where, who can edit it, when it gets audited) alongside the usual repo-level CLAUDE.md and MCP tool suite.

The clients getting the most out of Claude's shared memory are the ones who already had disciplined project scoping. If you're running five Claude sessions a day but treating them like anonymous chats, memory will amplify the mess. If you want a walk-through of how we set this up for a working automation — including the failure modes and what we don't put in memory — book a discovery call and bring one repetitive task you'd like to hand off.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Book a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.