Projects and Workspaces
A project is a scoped working context. It ties an assistant or team, its conversations, its memory, and its files to one piece of work, so the work stays organized rather than spread across unrelated chats. When you move into a project, the agent works within that project’s scope instead of a generic global one.
The projects surface
Section titled “The projects surface”The desktop shows your projects as a grid of tiles. You can create a project from a single field for a quick start, or use the New Project wizard when you want to set more up front. Opening a project takes you to its workspace page, where the conversations, activity, and results for that project collect in one place.
A project gives an assistant a stable home. Rather than starting a new chat each time and re-establishing context, you return to the project and the relevant history, memory, and scope are already there.
How projects map to the engine
Section titled “How projects map to the engine”A desktop project corresponds to a project directory in the engine. The engine scopes its work to a project root, which is where it reads and writes per-project memory and where it resolves project context. On the command line, --project-dir sets that root, and the project-context command resolves the project’s instructions.
This mapping is why the two surfaces stay consistent. The project you open in the desktop and the directory you point the CLI at are the same scope, so memory written in one is visible in the other, and the agent’s working context matches.
Project context files
Section titled “Project context files”Within a project root, the engine loads hierarchical instruction files (such as AGENTS.md) by walking up from the working directory. These give the agent project-specific rules without touching the global Constitution. A project can therefore carry its own conventions while the shared rules stay in place.