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 select which workspace credentials runs in the project may use.
• 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 and session uploads stay with the individual session. Use session scope for one-off material; use project scope only when future work should inherit it.

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 access through the project rather than maintaining unrelated sharing lists.

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.