Projects

A project is the durable context and sharing boundary for a body of work. Every chat, agent, automation, and dashboard belongs to exactly one project, even when the interface presents the activity as standalone.

This gives all work the same foundation: a stable place for instructions, files, memory, skills, connector activations, external API hosts, and access policy.

Listed and unlisted projects

Creating a project explicitly makes it visible in Projects immediately. Starting a chat, automation, or dashboard without choosing a project creates an unpromoted project instead. That project is fully functional but hidden from the Projects list and represented by the activity it backs.

For a standalone chat, use Save as project to promote that existing context. Promotion changes its visibility and optional name; it does not copy the conversation or create a second set of files. Automations and dashboards do not currently expose that promotion control. A promoted project can be renamed at any time afterwards with Rename from its row on the Projects list; an agent's home project is renamed through the agent instead.

An agent also has a dedicated, promoted home project, but d5s intentionally hides it from the Projects list and project search. Manage that context through the agent, which is the standing workspace resource users interact with.

What belongs in a project

• Instructions state the enduring goal, constraints, terminology, and working rules.
• Project files are reusable source material available across work in the project.
• Memory is maintained by the agent as durable project knowledge and can be inspected from the product.
• Skills provide reusable operating procedures pinned to a specific installed version.
• Connector activations normally begin with the workspace's active credentials and can be removed or added for this project. The home projects of conversationally created agents instead use explicit, draft-reviewed access and do not inherit future connections. Each activation has a stable project-scoped handle, and one connection may be the provider default.
• Network access may add exact external API hosts when the workspace policy delegates that choice to project editors. A host grant covers all ordinary HTTPS API methods and paths; nested CONNECT tunneling is blocked. Approve only APIs you trust. Workspace-wide host rules are inherited automatically.

Conversation history, session uploads, and files received through an agent channel stay with the individual session. Use session scope for one-off material; use project scope only when future work should inherit it.

Workspace agents and unattended runs can also contribute a named, versioned memory entry directly to another project in the same workspace. The contribution is attributed to the source session. This is the durable handoff path for findings, plans, decisions, and review notes; messaging a teammate alone does not automatically copy its eventual result into a project.

Access follows the work

By default, a project can inherit access from the workspace. A project can also be Restricted, with explicit Owner, Editor, or Viewer grants for people and groups. Chats, automations, dashboards, and an agent conversation inherit their base access through the project rather than maintaining unrelated sharing lists. Retained email correspondence follows access to the agent's project; Send copies to affects delivery, not in-product visibility. Other external chat turns can still be narrower because provider membership remains an additional boundary.

In a personal organization, a share manager who is not the organization owner can grant project access only to people who already have access to that workspace and cannot target organization groups. See Sharing and permissions for the full role and targeting rules.

Capability access is separate. A person may be allowed to edit a project while a connector action remains unavailable, denied, or approval-gated by its workspace policy. A project host grant permits credential-free traffic using ordinary HTTPS API methods and any path; nested CONNECT tunneling is blocked, and the grant cannot inject a stored credential.

Favoriting a project is personal to each user. Archiving is workspace-wide and recoverable. Deleting removes the project and its owned work, and d5s refuses deletion while a run in that project is still active.