- In short
- Separate conversations within the same Claude Project all inherit the Project's standing instructions and knowledge base, but they do not share each other's conversation-specific context. A decision or fact generated in one conversation is not automatically visible in a sibling conversation; to reach another conversation it must be re-entered, saved to the knowledge base, or persisted to Memory. This mirrors how independent agent invocations do not automatically share memory.
Shared setup, isolated threads
A Project makes conversations feel connected -- they share a brief, a knowledge base, and a workstream -- so it is natural to assume they share everything. They do not, and the CCAO-F exam tests this at the analyse level because the boundary is easy to miss and costly to get wrong. Every conversation in a Project inherits the same standing instructions and the same knowledge base, but each conversation's own running context stays isolated from its siblings.
Put plainly: what the Project holds centrally is shared; what a single conversation generates stays in that conversation. A decision reached on Tuesday's thread is not silently present in Thursday's thread just because both live in the same Project. Understanding this requires knowing what a Project actually holds, which is why it builds on project anatomy.
- Conversation isolation inside a Project
- Separate conversations in the same Project inherit its standing instructions and knowledge base but do not share each other's conversation-specific context. Information generated in one conversation is not automatically visible in another; it must be re-entered, saved to the knowledge base, or persisted to Memory to cross the boundary. This parallels independent agent invocations, which also do not automatically share memory.
What is shared and what is not
The line runs cleanly between the Project's central assets and each conversation's local context. Shared, automatically, in every conversation: the standing instructions and the knowledge base. That is the whole point of a Project -- set them once, and every thread starts primed with them.
Not shared: the specific back-and-forth of any one conversation. If you work out a decision, generate a draft, or settle a detail in one thread, a different thread in the same Project has no visibility into it. The knowledge base does not silently update itself with everything said in any conversation, and a sibling conversation does not read your other threads. The isolation is a feature -- it keeps unrelated lines of work from bleeding into each other -- but it means continuity between threads is something you arrange deliberately, not something that happens for free.
Moving information across the boundary
Because nothing crosses automatically, there are three deliberate ways to get a fact from one conversation into another. You can re-enter it directly, pasting the relevant decision or context into the other thread. You can save it to the knowledge base, which then makes it available to every conversation in the Project. Or you can persist it to Memory, so it carries across sessions more broadly, a mechanism explored in memory persistence and curation.
Which route to choose depends on scope. A one-time hand-off suits re-entering. Something that should inform all future conversations in the workstream belongs in the knowledge base. A durable fact that should follow you everywhere belongs in Memory. The mental model that keeps this straight is the parallel the exam draws: independent agent invocations do not automatically share memory with one another either. Each conversation is like a separate invocation drawing on the same shared configuration but running its own isolated context.
What the CCAO-F exam trips candidates on
Two assumptions are tested. The first is assuming a decision made in one conversation is automatically visible to a different conversation in the same Project. A scenario may show someone settling a key point in one thread and then being surprised when a second thread does not know about it. The correct reading is that conversation context is isolated, and the fix is to re-enter, save to the knowledge base, or persist the point.
The second is treating the Project's knowledge base as if it silently updates itself with everything said in any conversation. It does not. The knowledge base changes only when you deliberately add to it. A question may hinge on someone expecting the knowledge base to have absorbed a conversation's output on its own -- it will not have, and that is the error.
Worked example
In a client Project, an analyst finalises a pricing assumption in one conversation. A week later, in a new conversation in the same Project, she asks Claude to build on 'the pricing assumption we agreed' and Claude has no idea what she means, even though the standing instructions and uploaded files are clearly in effect. Why, and what should she have done?
The behaviour is exactly what conversation isolation predicts. The standing instructions and knowledge base are shared, which is why those are clearly in effect in the new conversation. But the pricing assumption was worked out in the running context of a different conversation, and that context does not automatically cross to a sibling thread. The new conversation never saw the agreement, so Claude cannot build on it.
Nothing is malfunctioning; the assumption simply lived in one conversation's local context and stayed there. To make it available, she had three options at the time she settled it. She could have re-entered it into the new conversation when she needed it. Better for a durable decision, she could have saved it to the Project's knowledge base, where every future conversation in the Project would see it. Or, if it were the kind of standing fact that should follow the whole workstream, she could have persisted it to Memory. The knowledge base would not have captured the decision on its own -- it updates only when she adds to it deliberately. The right habit is to save cross-thread decisions to the knowledge base or Memory at the moment they are made, rather than assuming the Project stitches conversations together.
Common misreadings to avoid
Misconception
A decision made in one Project conversation is automatically available in the others.
What's actually true
Misconception
The Project knowledge base absorbs whatever is discussed in any conversation.
What's actually true
How this shows up on the exam
Questions describe someone surprised that a second conversation lacks context from a first, or expecting the knowledge base to have self-updated. Diagnose it as conversation isolation and name the deliberate remedy: re-enter, save to the knowledge base, or persist to Memory. The tell is that shared assets work fine while conversation-specific context does not cross.
This knowledge point deepens project anatomy and connects to memory persistence and curation as the durable route across the boundary. It also underpins the recurring-workflow scenario, where knowing what a Project does and does not carry forward is central to designing the workflow.
Inside a shared Project, a strategist records an important assumption in one conversation. Days later, a different conversation in the same Project cannot reference it, though the Project's instructions and files are clearly active. What explains this and how should it be fixed?
People also ask
Do conversations in the same Claude Project share context?
How do I share information between two conversations in a Project?
Does the knowledge base update itself from conversations?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.