Projects

Project workspaces in Memory Console

Project Workspaces provide structured contextual boundaries for grouping memories, tracking operational decisions, and managing active tasks across client sessions. In the Memory Console at https://xmemo.dev/me#projects, the Workspace navigation section hosts the Projects panel, designed to "Browse project workspaces, context, and project memories."

• Workspace metrics: The console displays top-level statistics across your workspaces, including Total Projects, Active, Attention Needed, and Archived.
• Workspace provisioning: Selecting Create New Project opens a guided modal requiring a Project Name ("Required, 1-128 characters."). The interface renders a real-time Project Identifier Preview ("Non-authoritative preview. The backend server assigns the authoritative project key.") and accepts an optional Description up to 2000 characters.
• Personal boundary: Projects are personal only today. The backend service rejects workspace creation with team_id (HTTP 400). Documentation makes no Team project promise.
• No numeric limits: Project workspaces carry no numeric plan quotas or artificial creation caps. Accounts provision workspaces based on workflow needs rather than plan quotas.

Memory associations, lifecycle states, and non-destructive removal

Memories are assigned to a project to provide scoped context for connected agents and dashboard review. The Project Detail view aggregates project health metrics and provides fine-grained inspection of linked records:

• Project hero statistics: Each workspace hero bar highlights live aggregates for Memories:, Open TODOs:, and Decisions:.
• Memory lifecycle filtering: The memory explorer categorizes records by lifecycle status: Active, Superseded, Expired, and Archived.
• Non-destructive disassociation: Removing a memory record from a project workspace unlinks the association without destroying the underlying memory. The confirmation dialog affirms: "This memory will be disassociated from this project workspace. The memory content remains in your personal memory archive, but will no longer appear in this project context."
• Diagnostic isolation: Items with missing canonical references or namespace conflicts are quarantined under Diagnostic Isolated Items with badge Unindexed - Troubleshooting Only, preventing corrupted context from leaking into agent recall.

Knowledge vs Working partitions and Attention Needed view

Project workspaces support contextual memory partitioning if enabled for your account (the convergence evaluation mode defaults to off):

• Knowledge partition: Holds durable reference facts, long-term architectural decisions, and project conventions intended for persistent recall.
• Working memory partition: Contains transient task state, in-flight work sessions, and scratchpad context that can be retired upon milestone completion.
• Attention Needed view: Highlights unassigned candidates, suspected duplicates, or records pending attribution when partitioned curation is active for your account.
• Distinction from Knowledge Bases: A project Knowledge partition categorizes episodic conversational memory within a project boundary. In contrast, a Knowledge Base provides curated, multi-revision reference documents managed through independent storage. For curated documentation, see the Knowledge Bases concept guide at /docs/concepts/knowledge-bases.

A project is a scope plus a path convention

For baseline memory scoping, XMemo does not require a separate project object: a project is expressed by the scope a memory is written under and the logical path namespace inside it, so the same account can carry many projects without cross-contamination. On top of that memory boundary, Project Workspaces layer structured project state (Project API, TODO tracking, and recorded decisions) for cross-client collaboration.

• Write project facts under a stable path such as projects/<name>/decisions.
• Pass the project scope on both write and read so retrieval stays bounded.
• Project Workspaces layer structured project state—including Project APIs, durable TODOs, and recorded decisions—over the underlying memory boundary.
• Projects remain personal only today; team-scoped project workspaces are rejected by the API.

Write a project decision

Attach the record to the project path and scope at write time; nothing else has to be configured first.

await client.recordDecision(
  "Remote agents should use network MCP, not SSH stdio",
  { source: "codex", scope: "memory-os" },
);

Continue a project in another client

A second client recalls the same scope and gets the project context back without the user re-explaining it.

const context = await client.recallContext("recent agent integration progress", {
  scope: "memory-os",
  maxItems: 6,
  maxTokens: 1200,
});

Agent tools and client profile access

Authorized agents interact with projects through tools defined in config/mcp-documentation-contract.json across specific client profiles:

• chatgpt-public, generic-public, and public-only: Expose project, get_project_summary, and open_project_workspace.
• claude-plugin: Exposes project and get_project_context.
• cursor-plugin and ordinary-full: Expose get_project_context, update_project_todo, and update_project_decision.
• In-chat widget distinction: The ChatGPT Project Workspace widget opened via open_project_workspace is an interactive in-chat card interface; it is distinct from the full web-based Memory Console at https://xmemo.dev/me#projects.