Skip to main content
A project is a named bucket of context you own. Where your personal context is the always-on base every tool draws on, a project lets you keep a body of context scoped to one effort — a client, a codebase, a side venture — and switch into it when you want that focus.
A project is its own scoped store, exactly like a team — not a tag or a folder over your personal context. Switching projects changes which store a tool saves to and reads from; your personal context comes along as the base.

​
How it fuses

A read against a project is fused with your personal context (personal is the base, the project adds on top), the same way a team read fuses personal + team. So selecting a project never hides your personal context — it adds the project’s, focused on the effort at hand.
  • Save → lands in the active project (or personal when none is selected).
  • Recall / get → the active project + personal, ranked together.

​
Selecting a project

  • Chrome extension — the project selector in the on-page toolbar. Your choice persists, and saves/recalls from that tab scope to it. “Personal” is the default.
  • Web app — the Projects card on Home: create, rename, or archive projects.
  • MCP tools — pass the optional project parameter (the project’s id or slug) to save_context, save_session, get_context, list_context, forget_context, and recall_memory (recall fuses the project with your personal context, same as get_context). See the tool reference.

​
Ownership & isolation

Projects are yours. A project selector only ever resolves to a project the caller owns — a non-owner can’t address someone else’s project, the same authorization gate that protects team stores. Archiving a project hides it from selection and lists while leaving its stored context intact for deliberate reclamation.

​
Projects vs. teams

Personal context remains the always-on base in both cases — projects and teams add focus, they never replace what you already know.