Duplicate a workspace: start the next project from your base

An information security management system has a scope. ISO/IEC 27001:2022 (published October 2022) says so in clause 4.3: the organization determines the boundaries and applicability of the ISMS. One company, one set of interested parties, one set of interfaces. A consultant running several ISO 27001 implementations is running several scopes. An in-house team covering two legal entities may need two, depending on how those entities are bounded.

A workspace that holds both is not two scopes. It is one pile. Last month's Client A access-control debate sits in the same context as this morning's Client B Statement of Applicability. The assistant does not know where one engagement ends. After a few weeks, neither do you.

The other failure is the blank workspace. You open a fresh one for the new engagement, then spend the first hour re-uploading the same policy pack, re-pasting the same instructions, re-teaching the same memories. The base set forks by accident: Client B's access-control policy is last month's wording plus whatever you remembered to copy. That is how documented information drifts. Clause 7.5.3 of the same 2022 standard requires documented information to be available where it is needed, protected from improper use, and controlled through changes, including version control. Re-uploading a pack by hand is how that control usually slips: a copy of last month's wording, without a record of which version you meant.

What we shipped

You can duplicate a workspace you own into a new, independent workspace.

The copy carries the base:

• Custom instructions and the workspace persona
• Pinned documents you uploaded, the ones that finished processing
• Saved memories, both the ones you added and the ones the assistant learned in that workspace
• Pinned links, with the snapshot of each site that was already fetched

It does not carry the conversation. Chat history stays in the original, and so do the documents generated from those chats. The new workspace opens empty, with the base already in place, so you add only what is specific to this project.

The copy is a snapshot. Later edits to the original do not flow into copies you already made. Edits in a copy do not write back. That is deliberate. A live shared library (one Statement of Applicability attached by reference to many workspaces) is a different product. Duplicate takes the controlled set as it stands today, starts the next engagement from that, and leaves last month's chat behind.

The new workspace is named after the original with (copy) on the end. Rename it to the client or the department. Files that were still processing when you duplicated are skipped, and a toast tells you how many were skipped.

This sits next to company context. Company context is who you are, once, at the account. The workspace is the overlay for this engagement: this client's instructions, this entity's pinned pack, this project's memories. Duplicate is how that overlay becomes reusable without becoming a shared pile.

Before and after

Before, the two honest options were bad in opposite ways. Keep one long-lived workspace until it bogs down, mixing scopes as you go. Or create a fresh workspace and rebuild the base by hand: re-upload, re-paste, re-teach. People doing this for every new client or entity were doing document-control work in the worst possible place, the upload dialog.

After, you build the base once. Instructions, pinned policies, memories, pinned links. Duplicate. Rename. Add the documents that belong only to this engagement. ISO/IEC 27002:2022 (published February 2022) control 5.33, Protection of records, is the guidance for keeping records from unauthorized access and unauthorized release. Keeping Client A's files out of Client B's workspace is the basic form of that. Starting Client B from a copy of your methodology, not from Client A's thread, is how you keep the method without importing the wrong records.

Why a snapshot, not a reused thread

Frontier models are good at continuing a conversation. That is the wrong default for a new engagement. The valuable thing in the old workspace is not the chat. It is the controlled set: the instructions that say how you work, the pinned pack that is the current baseline, the memories that are facts about the method rather than facts about last Tuesday's argument.

Finding a past conversation is how you get back to a decision you already made. Duplicate is how you refuse to drag that decision, and the files around it, into a scope where it does not belong.

Honest scope

Duplicate is available on workspaces you own. Team-shared workspaces do not show the button. The copy is always personal to you.

It is a snapshot, not a linked library. If you later tighten a policy in the original, existing copies do not pick up the change. Open the copy and update it, or duplicate again from the revised base.

Only completed, content-bearing pinned files copy. A file still processing, or one that failed to extract, is skipped rather than silently dropped.

The help page covers the same limits.

Who it is for

• Consultants running one workspace per client, who already keep engagements separate and were rebuilding the same base set every time.
• In-house teams covering more than one entity or department, who want the same ISMS pack as the starting point and different evidence in each copy.
• Anyone who has been stretching a single workspace because starting over meant losing the instructions and the pinned pack.

If you only keep one workspace and finish the work inside it, you do not need this. Duplicate earns its keep the moment the next project would otherwise inherit last month's chat, or inherit nothing.

Try it

Open Workspaces. On a personal workspace that already has your base set, click Duplicate, confirm, and rename the copy. Then pin the documents that belong only to this project.

A new engagement should start from the controlled set. It should not start from last month's thread, and it should not start empty.