Projects: one home for a goal's workflows, apps, and skills

Projects shipped to every workspace. Projects, which have since become specialists, give a goal that takes several pieces one home: a skill holding the procedure, a workflow running it on a schedule, an app where someone reads the output, and the reference files behind all three. Start a chat inside a project and everything it builds lands there. Read the Projects announcement.

How it works

• One home per resource. A workflow, app, or skill lives in at most one project, and you can move work in or out at any time.
• Chats follow the work. A chat that creates a project moves into it, and @-mentioning a project attaches its inventory to your message.
• Access flows down, and the narrower setting wins. Share a project as viewer, runner, or editor and the role reaches everything inside, while a resource can still carry its own narrower setting.
• Chats stay private. A conversation in a shared project belongs to the person having it; what the project knows lives in its memory and files.
• Project memory. Each project keeps its own memory, refreshed daily from its files, workflows, runs, and chats.
• Everywhere you work. Sidebar, search, @-mentions, the agent's tools, the MCP server, and the CLI.

Access rules are tested in CI against a real Postgres database: 90 tests cover every role, the workspace boundary, and every way of revoking access.