Projects

A project is the box round one initiative's work: one client, one product, one house move. Say "make me a project for Halton" and Player One creates it, gives it its own working file area, switches you into it and opens a fresh chat already assigned to it.

From then on, what you do while Halton is selected belongs to Halton. Your chats, agents, files and automations narrow to it, and the assistant works with Halton's knowledge in front of it rather than everybody's.

What belongs to one

Every chat sits in exactly one project, and whatever an agent makes in that chat lands there too. A project holds:

Chats, and the folders you group them into.
Agents. One agent can belong to several projects at once, and adding it to a project brings its own memory and files with it. Your main assistant and the system agents are in every project already.
Workspaces. Each project gets its own working file area from the moment it is created, which is where a job puts its files unless it is told otherwise.
Memory Spaces connected as knowledge, so an agent searching for background finds this client's and not the others'.
Jobs, flows and scheduled tasks. A job or a scheduled task lives in one project at a time, so putting one somewhere else moves it.
Contact lists, though the contacts inside them stay shared.
Skills owned by the project, which beat a site-wide skill of the same name for anyone working inside it.
Standing instructions, one file that every agent and chat in the project reads.

Your AI accounts, your models, the vault, your account settings and your site-wide skills and instructions belong to the whole installation. Choosing a project never changes which AI you are talking to, and passwords in the vault keep their own access rules wherever the work goes. Anything unfiled lives in Default Project.

A project organises; it is not a security wall. Organising with projects covers when to make one and what that distinction means in practice.

Projects inside projects

Say "make Rebrand a sub-project of Halton", or choose a Parent project when you create it. Rebrand now sits indented under Halton in every project picker, and the shared knowledge connected to Halton is in its reach as well as its own.

A project has at most one parent, and the tree goes three levels deep: Halton › Rebrand › Launch emails, say. A project with a parent is a sub-project. Default Project stays outside the tree, because every unfiled chat lands there: it can neither have a parent nor be one.

What passes down is knowledge. A sub-project gets the shared Memory Spaces, standalone workspaces and Fold sources connected to the levels above it, and the project skills of those levels as well. Agents, chats, jobs, flows, scheduled tasks, contact lists, standing instructions and vault items do not pass down, so each sub-project has its own. Nothing passes up or sideways: Halton does not get Rebrand's knowledge, and two sub-projects of Halton do not get each other's. Selecting a parent does not pull its sub-projects' chats or jobs into its lists.

Passing knowledge down is tidiness, not privacy. A sub-project reads what it gets from above exactly as it would read something connected to it directly, so do not use the tree to keep anything from anyone.

Moving a project under a different parent takes its sub-projects with it, and changes no chat, agent, file or instruction. Player One refuses a move that would make a project its own parent, put it under one of its own sub-projects, or take the tree past three levels, and says which in a sentence. A project with sub-projects cannot be deleted until they have moved elsewhere.

The selector at the top

The project you are in is the title row of the sidebar: an avatar, and beside it the name with a chevron and a line underneath. For a sub-project the line shows the projects above it ("Halton › Rebrand"); for any other it shows the description. The avatar opens the Dashboard (/dashboard). The name and chevron open the picker, where you search your projects, pin the ones you use daily and create a new one from the footer. The pencil on a row selects that project and opens its Overview.

The picker draws the tree. Sub-projects sit indented under their parent, pinning a parent brings its whole group to the top, a pinned sub-project stays under its parent, and a search match is shown with the projects above it. Every other place that asks you to choose a project, such as Move to project on a chat or the Parent project field, shows the same tree.

The first option is All projects, a browsing mode rather than a project. Every list widens to the whole installation. Nothing has a project while you are in it, so New chat and the Project menu row are hidden, and anything that would have to be filed somewhere is greyed out with a tooltip such as "Choose a project to create one" or "Pick a single project first". A chat you already have open stays open. The selector turns red, with a red globe for its avatar, so the wider scope is unmistakable, and the first card on the Dashboard says so too.

The Manage Project page

Manage > Project (/project) manages whichever project is currently selected. There is no address for a particular project and no list page: you switch in the header, then manage the one you are in. It has seven tabs.

Overview (/project) is the project itself: name, description and avatar edited in place, headline counts, recent chats and a list of everything it holds. The avatar takes your own logo, a searchable icon or plain initials. A sub-project's Overview shows its path, a parent's shows its Sub-projects, and the Parent project field changes the parent at once, taking the project's sub-projects with it. Default Project has neither.
Agents (/project/agents) adds and removes agents.
Automations (/project/automations) carries jobs, flows (/project/automations/flows) and scheduled tasks (/project/automations/scheduled-tasks), with Move here for the two that belong to one project at a time.
Resources (/project/manage) holds contact lists, and the project's own skills at /project/manage/skills.
Knowledge (/project/knowledge) is what the project may search. It has three tabs: shared Memory Spaces here, workspaces at /project/knowledge/workspaces, and Fold sources at /project/knowledge/fold-sources, which are indexed material such as a code repository connected to the project directly. A Memory Space is connected as Use as knowledge or Use and update, and a workspace as Use files or Use and update files.
Instructions (/project/instructions) is the standing instruction file for this project, read on every turn by every agent in it. A sub-project reads its own and not its parent's.
Advanced (/project/advanced) is deletion. It shows what would be affected, asks where the work should go instead, and hands the rest to a logged review that waits for your confirmation before writing anything. If the project has sub-projects, the page names each one as a link to its Overview and keeps the review button off until they have moved.

For the steps, see Organise work with projects. For what the pieces themselves are, see Agents, Workspaces and files and Memory.

What a sub-project gets from above

Open the Knowledge page while Rebrand is selected and its own connections come first. After them, nearest level first, come the items it gets from Halton, each with a From Halton chip. A row marked Inherited is something else: it is connected to every project, not passed down from a parent.

The row's access control has the same words as any other, plus Remove. A sub-project can take less than the level above has, never more. An option above what Halton allows stays in the list but is greyed, with the reason beside it: "Halton only uses this as knowledge, so Rebrand can't update it." For a workspace the reason reads "Halton only uses these files, so Rebrand can't update them." A Fold source offers only Use as knowledge and Remove. Remove is described as "Stop getting this from Halton. You can bring it back", and the removed rows fold into one line at the foot of the list, "2 items from Halton removed · Show", where Show brings them back.

On a project that has sub-projects, each row also has a ⋮ menu with Pass on to sub-projects, switched on for everything by default. Its note reads "Rebrand and Launch emails get it automatically. Any project can still connect it directly." A row you switch off wears a quiet Not passed on chip, and the sub-projects stop getting it automatically. A middle project such as Rebrand has both controls on what it gets from Halton, so it can stop something reaching Launch emails.

The exception is the project's own default workspace, which holds its working files. It starts switched off at every level and reaches sub-projects only if you switch it on. When it does, it arrives as an ordinary workspace and never becomes their default. Changing which workspace is a project's default does not change what its sub-projects get: each workspace keeps the setting it had.

An agent searching in a sub-project looks at the project's own knowledge first, then its parent's, then its grandparent's.