Chat and Cowork Merged

The Chat and Cowork selector in the message box is now gone, and Claude decides per request whether a message gets an answer or becomes a task. The help-centre article titled “Claude Cowork and chat are one Claude” documents no toggle and provides no mechanism to force either outcome. You type into a single prompt box, and the system evaluates the prompt to determine its mode of execution which is a nice change in my opinion, choice overload is a real problem at the moment.

The rollout is gradual and arrives for Pro and Max users first, so the old selector and the new unified experience will coexist for a few weeks. Your screen may still display the familiar toggle while other workspaces have already moved over to the single input. This staggered release means that guidance written for the split interface will overlap briefly with the reality of the merged system.

---

Backing the More Capable Surface

A company building for agentic work backs the surface that does more, so when the long-term objective is autonomous execution, maintaining a strictly conversational window alongside an active workspace divides focus without much value. A simple text prompt cannot compete with an environment engineered to let models inspect files, run terminal commands, and complete tasks. So Anthropic was always going to direct its resources towards the interface that enables Claude to act rather than respond. Folding the limited dialogue surface into the capable operational one was the sensible and obvious trajectory.

Cowork already had everything Chat had plus a shell, a folder and a browser, so I only really ever opened Chat from my phone. On my desktop, Cowork handled plain prose without friction and offered access to the local machine, project directories, when Cowork came to the phone, it was clear that at some point the two would coalesce.

The August memory unification was the first step and the interface merger is the second. In August, Anthropic consolidated Claude’s memory across surfaces, establishing a continuous state. That update laid the technical groundwork by ensuring the assistant carried a single awareness regardless of where an interaction started. Bringing the user interfaces together completes the architecture. With memory already shared across the product, maintaining separate modes with distinct toggles served only to clutter the product.

---

Unifying the Loop Surfaces

The surfaces section of my original post and the surfaces callout in the template both described three surfaces. I distinguished between Chat, Cowork and Code, treating each as a separate environment with distinct operational bounds. Now Anthropic has collapsed Chat and Cowork into one unified “conversation” interface, my architecture simplifies with it. The two modes are now a conversational Claude interface and Claude Code. Adjusting the documentation to reflect this reduction removes an artificial boundary that previously complicated how we mapped user workflows to the underlying context.

The Cowork setup page under ForClaude was an extension task for a surface that no longer needs setting up. In the initial layout of the template, Cowork required its own bespoke configuration routine because it handled local files, terminal execution and browser automation as an explicit, separate mode. Users had to follow specific steps to authorise and initialise those capabilities before doing any work. With the unified release, those tools belong directly to Claude, invoked autonomously whenever a prompt demands action. A dedicated setup task for an environment that is always active by default is entirely redundant.

The install prompt was written for Chat or Cowork, and the qualification no longer means anything to a new reader. When I originally prepared the installation text, I catered specifically to the differences in how each interface parsed system instructions and handled permissions. To anyone arriving at the platform today, explaining whether to paste instructions into Chat or Cowork is bewildering history rather than practical guidance.

---

Context Systems Versus Second Brains

I also initially called it a second brain in the first post because that was the phrase in circulation, and a video I watched this week showed me the phrase described someone else’s project. The familiar terminology made it easy to introduce, yet it imported assumptions that do not belong to what I actually built. A second brain implies personal knowledge management, archival habits, and an attempt to store everything a human might forget. My system is rather a mechanism to feed specific, working context into an assistant. The shift in terminology from second brain to context system hopefully marks that boundary.

The system exists so that Claude can help me build things without a prompt that re-explains the project or a paste of my last conversation. Starting a fresh session should not require five minutes of administrative throat-clearing, manually copying state updates, or hoping the model infers past decisions from fragmented context. When the working environment provides the state immediately, I can ask Claude to pick up where we paused and expect execution. The work stays centred on the product being built, rather than on the setup required to bring an assistant up to speed on the baseline realities of the project.

It is not Claude’s memory, which Claude now holds itself and consolidated across surfaces in August; it is the context I decide Claude should have. Native model memory belongs to Anthropic’s platform, accumulating passive impressions and broad preferences across sessions behind the scenes. That serves a purpose, but passive recall is not managed project state. The context system provides deliberate, structured, and auditable information that governs the immediate work. Claude does not have to guess what matters or rely on autonomous recollection; the exact boundaries and priorities are explicitly set, reviewed, and updated as the project demands.

Notion holds that context because every surface reads it, Code and the phone included, and so does a colleague’s account or another vendor’s model over the same MCP (including NotionAI, which behaves like a better version of NotebookLM). By anchoring the project history, specifications and notes in a neutral external database, the setup avoids relying on the particular interface Claude presents on any given day. A mobile browser accesses the same pages that Claude Code inspects from the terminal. If I invite a collaborator, their account reaches that store. If I connect a model from another vendor through the same protocol, it inherits the same baseline with minimal friction. The storage layer remains entirely distinct from the human-agent surface.

The Current State page and the session log are the structure Claude navigates instead of a transcript it rereads. When a fresh interaction begins, Claude does not parse thousands of tokens of rambling conversational history to deduce what happened yesterday. It inspects the current state document for the active objectives, then checks the latest log entry to understand where the work paused. That sequence worked identically when Chat and Cowork were distinct modes, and it continues to work now that they share a single prompt box. By organising information into structured records rather than sprawling chat threads, the system shields the workflow from front-end changes. The operational clarity comes from deliberate architecture, not the layout of Anthropic’s user interface.

---

Five Changes to the Loop

The surfaces callout drops to two, Claude and Code, and to differentiate them clearly I now call the primary interface Claude: Conversation. Where the original template distinguished between a quick exchange in Chat and an agentic session in Cowork, Anthropic has collapsed that boundary into a single front door. That leaves two practical modalities for my work. The first is Conversation, which handles dialogue, drafting, and autonomous desktop tasks inside the main application. The second is Code, which remains the specialist environment inside the terminal. Trimming the callout down to these two reflects how the tools operate without clinging to legacy distinctions that no longer exist.

The Cowork setup task folds into the base install, leaving Code as the only extension. In the original structure, the Cowork setup page under ForClaude formed a separate onboarding stage because Cowork required its own directory permissions and browser configurations. Now that every standard Claude conversation possesses the capability to run tools and take on tasks natively, setting up Cowork as an optional layer has become redundant. The primary setup instructions now establish context across the entire standard interface in one pass. Code remains the sole dedicated extension for users working directly against software repositories, making the initial system deployment noticeably leaner.

The install prompt and the Read me first page say Conversation, not Chat or Cowork. Continuing to cite Chat or Cowork in the introductory copy only confuses readers who opened the product after the merger and found only a single text field waiting for them. Purging those outdated labels from the template ensures the documentation matches the interface on screen. When someone copies the install prompt into Claude today, the phrasing reflects a coherent, unified tool rather than a historical transitional phase. The context architecture underneath operates precisely as it did, but the instructions finally speak the language of the current product.

The rule that /session-start runs only when asked matters more, because any conversation can now become a task without you choosing it. Previously, starting Cowork was an explicit decision to take on substantive work, whereas chat served lighter exchanges. Under the unified interface, Anthropic lets the model decide per message whether to answer directly or initiate a multi-step task. If the system ran session initialisation automatically whenever it detected a task, it would pollute Notion with records for minor queries and administrative drift. Constraining /session-start to an explicit command preserves discipline across the workspace. You decide when an exchange warrants formal tracking, regardless of whether Claude treats your prompt as a brief reply or an autonomous execution.

“Second brain” becomes “context system” in the post, the template and the marketplace listing. The old label was borrowed from popular shorthand, but it misrepresents the actual architecture. This setup does not try to replicate human recall or compete with Claude’s native cross-surface memory. Instead, it provides structured, deliberate context that I control, stored in Notion where any surface, account, or external model can inspect it. Calling it a second brain invited comparisons to personal note archives and personal knowledge management workflows that have nothing to do with how this loop operates. Replacing that phrasing clarifies the real purpose of the build, aligning the documentation with the clean separation between model intelligence and project state.

I built the loop for the day the surfaces disappear, and Code is now the last one standing. The context system still stands behind them and is identical to the one running on 11 September. Notion still holds the state, the session logs, and the project documentation, completely indifferent to which interface accesses them. Whether I interact through a browser, a mobile app, or another model over the same protocol, Claude picks up precisely where the last session ended. As providers continue to merge their interfaces into unified agents, only Code remains distinct for local file manipulation.