Projects · Project-Level Workspaces, Multi-Project Context Isolation and Sharing

1. Introduction

1.1. Background

When large models enter an enterprise, the first problem they expose is often not "the model isn't smart enough", but context without boundaries.

In the era without project workspaces, the knowledge scope of a conversation was equal to "whatever the user pasted on the spot". This led to three engineering problems:

1. Repeated assembly: the same set of background materials is pasted again in every session, so token cost grows linearly with the number of sessions.
2. Runaway boundaries: materials from different projects mix together in the same session, contaminating each other's outputs.
3. No accumulation: when a session ends, the context disappears, and the organization cannot cement "the facts this project has already confirmed".

Project workspaces (Projects) are the product form that emerged precisely to solve these three problems: they upgrade "a single conversation" into "a bounded, memory-bearing, permissioned, shareable context container". This form was widely adopted by mainstream platforms between 2024 and 2026, becoming the infrastructure for knowledge and collaboration AI applications.

1.2. Definition

Projects (project-level workspaces): a self-contained collaboration unit with its own chat history, its own knowledge base, its own custom instructions, and its own permission configuration, where one or more users keep working toward the same goal.

According to the definition in the Anthropic official help center: "Projects allow you to create self-contained workspaces with their own chat histories and knowledge bases."

A mature project workspace should provide four kinds of capabilities:

1.3. Positioning in the AI Harness System

图 1-1｜Projects 六层定位：L1 上下文工程主层与瓶颈分布

数据来源：基于本文分析绘制的示意图。

Projects' positioning in the Harness six-layer capability model is: primary layer L1 Context Engineering; secondary layers L4 Memory & State and L6 Governance & Security (this mapping is this article's analysis).

The bottleneck layer: Projects' capability bottleneck is almost entirely concentrated in L1. There are three reasons:

1. Capacity is a hard constraint — the context window determines "how much knowledge can be loaded at once";
2. Isolation semantics are implicit — if the default "do not share" rule is not explicitly designed, it can cause the silent error of "thinking it was shared when it wasn't";
3. Expansion triggers automatically — when nearing the limit it switches to RAG mode automatically; if the engineering side does not understand this mechanism, retrieval quality can shift abruptly without anyone noticing.

Value: Projects turns Harness' context engineering from "assembled ad hoc for every session" into "configured once, reused continuously" — the prerequisite for knowledge AI applications to move from toys to production.

2. Glossary

3. Case Studies

3.1. Claude Projects: 200K Context and Automatic RAG Expansion

3.1.1. Background

Anthropic's Projects was one of the earliest forms to productize the "project workspace". The problem it set out to solve: when a user converses repeatedly around a long-term goal (such as all the materials of a product line, or all of a client's contracts), how to avoid re-pasting background materials every time while ensuring different projects do not interfere with one another.

3.1.2. Approach

Based on the Anthropic official help center and the official release announcement:

• Capacity baseline: each Project includes a 200K context window, which the official announcement phrases as "Each project includes a 200K context window, the equivalent of a 500-page book".
• Automatic expansion: on paid plans, "When your project knowledge approaches context limits, Claude seamlessly enables RAG mode to expand capacity by up to 10x while maintaining response quality".
• Isolation semantics: "Context is not shared across chats within a project unless the information is added into the project knowledge base." — that is, chats within a project do not share context by default; only the parts written into the project knowledge base are shared.
• Memory partitioning: "Claude maintains separate memory summaries for each individual project, as well as a summary including the rest of your non-project chats."
• Permission model (Team/Enterprise): Can view (can view content/knowledge/instructions and chat within the project, but cannot edit) and Can edit (can modify project instructions and knowledge, add/remove members, and update member settings).
• Sharing methods: share individually by email, share by bulk email list, or share organization-wide; Owner / Primary Owner can turn off organization-wide sharing.
• Free-tier limits: free users can create up to 5 projects; RAG expansion is limited to paid plans.

The accompanying productization evolution is two organizational concepts introduced in Claude Cowork: Tasks (work units that run on demand or periodically on a schedule) and Projects (persistent workspaces that carry their own files/links/instructions/memory, where Tasks within a Project inherit its context). The source of this form is a secondary blog, and its release dates (launched January 2026, desktop GA April 9, 2026, expanded to Web/mobile July 7, 2026) are recommended to be double-checked.

3.1.3. Results

Based on the Anthropic official release announcement (vendor customer testimonial; must be noted when cited): management consulting firm North Highland has hundreds of consulting, business development, and marketing employees using Claude; its senior director Luka Anic said "helped our team complete content creation and analysis tasks up to 5x faster than before—turning what was once two weeks of writing and research into minutes of work".

This statement is a customer testimonial and a vendor claim; it lacks an independent third-party measurement methodology and should be treated as a qualitative reference rather than a benchmark.

3.2. McCarthy Holdings: A Project Workspace for 100 Million Engineering Files

3.2.1. Background

McCarthy Holdings is a construction engineering company with about 4,000 full-time employees. Its core pain point is extremely scattered knowledge: 100 million files are dispersed across three systems — SharePoint, Microsoft Teams, and Procore. Site personnel need to quickly retrieve historical plans, specification requirements, and material certifications in construction scenarios, which traditional retrieval could not satisfy.

3.2.2. Approach

Based on the Glean official case page:

• Build a unified retrieval layer covering SharePoint / Teams / Procore, forming an enterprise-level "project + knowledge" workspace.
• The enterprise knowledge graph is automatically built from its own data rather than relying on Microsoft Graph — this is especially critical for knowledge asset governance: permissions and relationship structures come directly from the real metadata of business systems.
• Build agents for specific business scenarios, the most commonly used being the change order review agent.

3.2.3. Results

Based on the Glean official case page (vendor customer case self-reported):

3.3. Storable: Scaling Project-Level Agents

3.3.1. Background

Storable is a provider of self-storage and rental management software. Its customer success (CSM) team frequently performs account audits and implementation preparation, with historical context scattered across Confluence, Jira, and Slack; newly onboarded engineers need several days to catch up on the background.

3.3.2. Approach

Based on the Glean official case page:

• Use Glean as a unified knowledge and agent workspace, covering years of historical context from Confluence / Jira / Slack.
• The engineering team connected the Glean MCP server to Claude Code, bringing historical context directly into the debugging flow — a typical combination of "project workspace + coding scenario", showing that project context can be reused across tools.

3.3.3. Results

Based on the Glean official case page (vendor customer case self-reported):

Also per the Glean official case page, TIME consolidated 100+ years of archives and went live in 3 weeks; its CIO Sharon Milz put it as "We're up and running in three weeks." — this case shows that the deployment cycle of a project workspace can be far shorter than that of traditional knowledge management projects.

4. Practice Standards

4.1. AGENTS.md Specification

The following is the complete, copyable industry-standard AGENTS.md for the Projects direction, following the STYLE Section 8.1 skeleton and reflecting the project workspace's dedicated toolchain (project knowledge base, context boundaries and capacity thresholds, memory partitioning, sharing, and permission tiers).

# AGENTS.md —— Projects（项目级工作空间）

## 角色与边界
- 你是本项目工作空间内的任务智能体。你的上下文边界 = 本项目的知识库 + 本项目的自定义指令 + 当前会话。
- 你可以：检索本项目知识库、读写本项目工件、生成草稿与候选方案、调用本项目白名单工具。
- 你不可以：跨项目检索（除非显式授权）、读取其他项目的记忆摘要、修改项目权限与共享范围、
  把本项目内容复制到其他项目空间、删除项目知识库的历史版本。
- 项目级指令 > 组级指令 > 组织级指令；就近优先（closest AGENTS.md wins），用户显式指令最高。

## 环境假设
- 运行环境提供：项目知识库（含版本/快照标识）、向量索引与关键词索引、对象存储（工件）、
  记忆摘要存储、权限服务（Can view / Can edit 两级）、审计日志。
- 项目知识库具备明确的容量状态读数（已用 Token / 上下文上限），可判断是否触发 RAG 扩容。
- 每个项目拥有独立的记忆摘要，且不与组织级记忆混用。

## 上下文加载顺序（Context Budget）
1. 项目自定义指令与本项目 AGENTS.md（常驻，不压缩）
2. 当前任务契约（目标、产出物、验收标准）
3. 触发的 SKILL.md 正文（渐进式披露：元数据常驻 / 指令触发加载 / 资源按需加载）
4. 项目知识库检索结果（混合召回 + 权限过滤 + 重排，附 doc_id + 版本号 + 片段定位）
5. 本项目记忆摘要与最近一次检查点
6. 其他项目的引用内容（仅在显式共享时，且必须标注来源项目）

## 上下文隔离三原则（硬性）
1. 默认不共享：项目内各会话之间不自动共享上下文；不得假设"上一轮说过所以这一轮知道"。
2. 显式入库才共享：只有写入项目知识库的信息才对项目内所有会话可见。
3. 记忆分域：每个项目独立的记忆摘要；跨项目迁移上下文必须通过显式导出，不得隐式继承。

## 容量与扩容规则
- 项目知识总量 < 200,000 tokens（约 500 页）时，直接全量装配，不做切分召回。
- 接近上下文上限时，系统自动启用 RAG 模式，容量扩展至多 10 倍；此时检索质量可能突变，
  必须在新模式下重跑评测集并记录基线变化。
- 扩容触发当日必须复核：切分参数、重排阈值、引用定位是否仍然成立。

## 工具契约
- 检索工具：必须携带调用者身份，返回已过权限过滤的结果；默认向量 + BM25 混合召回 + RRF 融合。
- 知识库工具：入库走"草稿 → 审批 → 上架"；下架须留版本快照。
- 工件工具：写入对象存储，命名规范 `project_id/artifact_type/yyyy-mm-dd_name_vX.Y`。
- 共享工具：共享范围变更须经项目 Owner 批准，并记录审计事件。
- 脚本工具：解析、切分、统计、格式转换等确定性操作必须调用 scripts/，不得用生成方式替代。

## 任务执行流程（SOP）
1. 确认项目 ID、知识域白名单、密级、产出物与验收标准。
2. 装配上下文并记录 Token 预算表（含被裁剪项与理由）。
3. 检索取证 → 权限过滤 → 重排 → 取 Top-K；无命中执行"无源不答"。
4. 生成草稿，逐条事实性陈述挂载来源标识。
5. 自检：格式、事实一致性、引用完整性、密级、是否误用其他项目上下文。
6. 交付：产出物 + 证据包（来源清单、检索记录、自检表、变更日志）。
7. 归档：写入项目知识库或对象存储，更新项目记忆摘要。

## 验证与证据要求
- 证据包五件套：来源清单、检索过程记录、自检表、评测结果（如适用）、变更日志。
- 必须能够回答"这段结论来自本项目的哪份资料、哪个版本、哪一段"。
- 跨项目引用必须标注来源项目，否则视为越界。
- 记忆摘要更新须记录变更点，便于审阅。

## 失败与升级策略
- 检索零命中 → 输出"未检索到可靠依据"，建议补充项目知识库；禁止用其他项目或通用知识补全。
- 疑似跨项目污染 → 立即停止，输出污染证据，升级至项目 Owner。
- 容量触发 RAG 扩容 → 暂停定稿，重跑评测集，指标达标后继续。
- 权限不足 → 终止并记录审计事件，升级至权限管理员，不得换用高权限账号绕过。

## 安全与合规红线
- 不得绕过项目权限读取其他项目内容。
- 不得把 Can view 权限升级为 Can edit，不得自行变更共享范围。
- 不得把项目内高密级内容输出到项目外的渠道或低密级存储。
- 不得删除或篡改项目知识库的历史版本与审计日志。

## 禁止事项
- 禁止假设会话间上下文共享。
- 禁止在无召回支撑时输出事实性结论。
- 禁止编造 doc_id、版本号、片段定位。
- 禁止使用 XX / XXX / ___ 等非标准占位符（统一用 [待填写] / [待核实]）。
- 禁止复制其他项目的指令作为本项目规范。
- 禁止使用 emoji 与署名。

## 输出格式
- 文档类产出：Front Matter → 标题 → 创建时间 → 目录 → 正文（1 / 1.1 / 1.1.1）→ 信息缺口声明 → 参考资料。
- 表格列名明确，正文数量声明须与表格行数一致。
- 数值带单位；范围用 ~ 连接；中英文之间加空格；中文全角标点。

## 评估与自检
- 九项自检：来源完整可回溯 / 无无源断言 / 数值逐字符一致 / 无非标占位符 /
  数量与表格一致 / 编号可核实 / 密级正确 / 审阅节点齐备 / 信息缺口已声明。
- 每个季度或每次知识库大版本更新后重跑评测集，形成趋势曲线。

4.2. SKILL.md Specification

The following is the complete, copyable industry-standard SKILL.md for the Projects direction, following the STYLE Section 8.2 skeleton.

---
name: project-workspace
description: 在项目工作空间（Projects）内完成任务——装配项目知识库、维护上下文隔离边界、管理工件与记忆摘要、处理共享与权限分级。当用户要求"在这个项目里""基于本项目资料""整理项目上下文""把结论沉淀到项目知识库"或需要在多个项目间划分上下文边界时触发。
version: 1.0
created: 2026-09-12
---

# 项目工作空间任务（Project Workspace）

## 适用场景
- 在既有项目工作空间内检索、起草、分析并沉淀结论。
- 新建项目工作空间：定义知识域、指令、权限与共享范围。
- 多项目上下文划分：判断信息应归属于哪个项目、是否应共享。
- 项目知识库维护：入库、重索引、版本快照、归档。

## 前置条件
- 已确定 project_id，且本项目的 AGENTS.md 已加载。
- 已获得项目知识库访问权（Can view 或 Can edit）。
- 已知项目容量状态（是否接近上下文上限、是否已触发 RAG 扩容）。
- 已声明数据密级与共享范围。

## 输入
- project_id、任务描述、产出物格式、验收标准
- 项目知识域白名单与密级
- 上下文预算（Token 上限与裁剪优先级）
- 可选：需要沉淀回知识库的结论清单

## 输出
- 主产出物（文档 / 表格 / 方案 / 结构化的结论清单）
- 证据包：来源清单（doc_id + 版本号 + 片段定位）、检索记录、自检表、变更日志
- 知识库更新建议（哪些结论应入库、哪些属于会话临时信息不应入库）
- 项目记忆摘要更新要点

## 执行步骤
1. 读取项目自定义指令与就近 AGENTS.md，确认边界。
2. 判断上下文模式：语料 < 200,000 tokens 走全量装配；否则走混合检索 + 重排。
3. 执行检索：向量 + BM25 → 权限过滤 → RRF 融合 → cross-encoder 重排 → Top-K。
4. 生成草稿，逐条挂载来源标识；跨项目信息须标注来源项目。
5. 自检：隔离性（是否误引他项目）、溯源性、一致性、密级。
6. 沉淀：把"项目级长期有效"的结论写入知识库候选清单；会话临时信息不入库。
7. 交付：产出物 + 证据包 + 记忆摘要更新要点，交人工审阅。

## 质量标准（DoD）
- 事实性陈述 100% 附来源标识且可回溯。
- 零跨项目污染：所有信息均可归属到本项目或显式标注的外部来源。
- 隔离三原则执行到位：默认不共享 / 显式入库才共享 / 记忆分域。
- 容量模式切换已记录，且切换后评测指标不低于基线。
- 证据包五件套齐备；无非标准占位符。

## 常见失败与处理
| 失败 | 根因 | 处置 |
|---|---|---|
| 结论无法定位来源 | 引用缺版本号或片段定位 | 判定不合格，剔除或重检索 |
| 混入其他项目内容 | 隐式继承会话上下文 | 停止并清除，输出污染证据，升级至项目 Owner |
| 容量突变导致质量下降 | 自动触发 RAG 扩容未复核 | 暂停定稿，重跑评测集，记录基线变化 |
| 该共享的没共享 | 结论未入库即被其他会话引用 | 走"草稿 → 审批 → 上架"流程补入库 |
| 权限不足 | 仅 Can view 却执行写操作 | 终止并升级至项目 Owner，不得换账号绕过 |

## 示例
用户请求：基于本项目资料，整理 A 客户合同条款变更要点，并沉淀到项目知识库。
执行：
1. 确认 project_id = A 客户合同项目，权限 = Can edit。
2. 检查容量：项目知识 120K tokens < 200K，走全量装配。
3. 检索合同版本 v1.0 与 v2.0，逐条比对条款差异。
4. 输出变更要点表（条款号 / 原表述 / 新表述 / 影响），每条挂 [doc_id][版本][条款号]。
5. 把变更要点作为知识库候选条目，提交"草稿 → 审批 → 上架"流程。
6. 更新项目记忆摘要：已比对 v1.0→v2.0，共 N 处变更，M 处影响付款条件。
约束：不得引用其他客户项目的合同模板；审批通过前不得把要点写入正式知识库。

4.3. Implementation Checklist

5. Summary

Projects is the starting point of the knowledge collaboration group's capabilities and the first concretization of Harness' context engineering layer (L1) in product form. Its engineering value is not "one more folder", but turning three things into configurable engineering objects:

1. Context boundaries: from "past ad hoc every time" to "defined once, reused continuously".
2. Sharing semantics: from "shared by default, investigate when something goes wrong" to "not shared by default, shared only after explicit ingestion".
3. Capacity elasticity: from "crashes when it can't fit more" to "automatically expands up to 10x when nearing the limit".

The two mechanisms most worth referencing for engineering teams are:

• Isolation semantics default to no sharing (Anthropic official help center original text). This means "I assumed it knew" is the most common source of error in project workspaces and must be eliminated through explicit ingestion.
• Small corpora prefer full assembly (Anthropic official statement: < 200,000 tokens needs no RAG). This rule can significantly reduce engineering complexity for small teams — not every project needs a vector store.

At the same time, three unresolved problems must be pointed out:

• No official protocol specification: Projects currently has only product documentation, with no copyable API/protocol-layer specification (information gap).
• No quantitative evaluation of isolation strength: there is no public quantitative evaluation method for the context leakage rate / isolation strength between multiple projects (information gap).
• Dates of related forms need verification: Claude Cowork's release and GA dates come from secondary sources and should not be used as a basis for decisions (information gap).

Information Gap Statement

6. References

1. What are Projects? — Anthropic Help Center. https://support.anthropic.com/en/articles/9517075-what-are-projects
2. How can I create and manage Projects? — Anthropic Help Center. https://support.anthropic.com/en/articles/9519177-how-can-i-create-and-manage-projects
3. Introducing Projects — Anthropic official release announcement. https://anthropic.com/news/projects
4. McCarthy Holdings, Inc. — Glean customer case. https://www.glean.com/resources/customer-stories/mccarthy-holdings-inc
5. Storable — Glean customer case. https://www.glean.com/resources/customer-stories/storable
6. Glean — official website of the enterprise AI platform. https://www.glean.com
7. AGENTS.md — A simple, open format for guiding coding agents. https://agents.md/
8. Equipping agents for the real world with Agent Skills — Anthropic Engineering. https://anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
9. Model Context Protocol Specification Changelog — MCP. https://modelcontextprotocol.io/specification/2025-06-18/changelog
10. What is Claude Cowork — secondary source (date to be verified). https://www.usecarly.com/blog/what-is-claude-cowork