Skip to content

Organising with projects

You run a small agency with three clients: Halton, Ardsley and Meridian. Everything lives in one place, and for a while that is fine. Then the Halton chats are buried under Ardsley chats, an agent quotes Meridian's rates back to Halton, and a search for "the brief" returns four of them.

A project is the box you put one client's work in. 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.

What a project draws a line around

A project is the boundary for what an agent can see and search. Everything an agent makes in a chat lands in that chat's project: agents, workspaces, memory spaces, jobs, flows, scheduled tasks, contact lists and skills. The lists you browse follow it too: your chats, Manage > Agents (/agents), Manage > Files (/workspaces), Dashboard > Jobs (/jobs), Dashboard > Scheduled (/cron) and the search box all narrow to the project you have selected.

Four things deliberately sit outside the box.

  • Your main assistant and the system agents belong to every project, and are not yours to add or remove.
  • Jobs and scheduled tasks live in exactly one project, so putting one elsewhere is a move, not a copy. Most other things can belong to several; contact lists follow a project, though the contacts inside stay shared.
  • Passwords and keys in the vault keep their own access rules and do not follow a chat when it moves, so ask for the login again in the new project.
  • Your providers, your account and your site-wide skills are installation-wide: choosing a project never changes which AI you are talking to.

A project organises; it is not a security wall. It keeps a client's work together and out of the way of everything else, which is usually what you want, but it is not what to rely on if somebody must be genuinely locked out.

The selector at the top, and All projects

The project you are in is the title row of the sidebar. Its avatar opens the Dashboard (/dashboard); the name and chevron beside it open the picker, where you search your projects, pin the two or three you use daily, and create one from the footer.

The first option is All projects. It is a browsing mode rather than a project: every list broadens to the whole installation, which is how you find the chat you cannot place. Since nothing has a project while you are in it, Player One hides New chat and the Project row, and greys out anything that would have to be filed, with a tooltip that says to choose a project first. The selector turns red while it is on.

Switching in the header changes what you are browsing, not where your work lives: a chat keeps the project it was assigned. To move chats, use Select in a chat's menu, tick the ones you mean and choose Move to project. Each chat takes its team with it, the lead and the helper chats that work for it, and the confirmation counts them. Jobs, files and everything else stay where they are, so for a whole piece of work ask your assistant instead. A moved chat uses its new project's knowledge and skills from its next message.

Projects inside projects

Say Halton has a rebrand under way, and the rebrand has a launch-email workstream. Halton holds the brand guidelines and the contract terms. The rebrand needs the guidelines and its own research. The launch emails need both, plus their own copy.

Make Halton, then Rebrand, then Launch emails, each under the one before: say "make Rebrand a sub-project of Halton", or choose a Parent project in the New project dialog or on a project's Overview. Connect the guidelines Memory Space to Halton once, and Rebrand and Launch emails both read it without being connected to it themselves. The project picker shows the three as a tree, and the line under a sub-project's name shows where it sits: "Halton › Rebrand".

A project has one parent, and the tree stops at three levels. If you want a fourth, you probably want a folder in the sidebar instead.

What flows down is knowledge: the shared Memory Spaces, standalone workspaces and Fold sources connected above, and the project skills there. Everything else is per project. A sub-project has its own agents, standing instructions, jobs and chats, so write its rules on its own Instructions page rather than expecting Halton's to apply. Nothing flows up or sideways, and selecting Halton does not gather in the chats and jobs of the projects under it.

You decide what goes down. Once a project has sub-projects, each row on its Knowledge page carries Pass on to sub-projects, on by default. Switch it off for the contract terms that only Halton needs and the sub-projects stop getting them automatically. That is tidiness rather than a lock, because any project can still be connected to the item directly, and a sub-project that gets something from above reads it exactly as it would if you had connected it there. A sub-project can also turn an item down or take it as read-only, though never take more than the level above has. The one item that starts switched off is a project's default workspace, since that is where its working files sit.

If Rebrand turns out to belong to Ardsley, change its Parent project on its Overview. Launch emails goes with it, and what both get from above changes to Ardsley's. Nothing in either project is copied or moved, so the change is undone by changing the field back.

Two places to write standing instructions

Manage > Project > Instructions (/project/instructions) holds one project's standing instructions, read by every agent and chat in it. This is where a client's own rules go: how they like to be addressed, the rate you agreed, the approval they always want before anything goes out.

The site-wide equivalent is All agents, in the overflow menu on Manage > Agents (/agents), at /agents/all. Every agent on your installation reads that one, in every project, so it is for what is true everywhere: your company name, your house tone, that Friday finishes early.

They are read in that order, site-wide, project, then the agent's own, and the narrower scope has the last word. A sub-project reads its own file and not its parent's. Both are re-read on every turn, so each line costs a little on every message for as long as it stays: keep them to rules, and edit rather than append. Anything longer belongs in a skill, which loads only when wanted: see Teaching it.

Being in the Halton project does not by itself let an agent read Halton's files. It searches what the project is connected to, which you decide on Manage > Project > Knowledge (/project/knowledge).

  • Memory Spaces are the normal home for durable knowledge. Connecting one asks whether the project may Use as knowledge or Use and update: read it, or add to it as well.
  • Workspaces are file areas. Connecting one gives the project's agents access to the files; making them searchable by meaning is a separate switch, off to begin with, because a folder of half-finished drafts is not something you want quoted back.
  • Adding an agent on Manage > Project > Agents (/project/agents) brings its own memory and workspace with it, so the specialist arrives carrying what it has already learned.
  • In a sub-project, the same page also lists what the levels above pass down, each marked with the project it comes from. An agent there looks at the project's own knowledge first, then its parent's, then its grandparent's.

Workspaces and Memory Spaces explains what each of those holds; Memory, explained covers what an agent searches before it starts.

Project skills are the other half. A skill filed under the project, on Manage > Project > Resources > Skills (/project/manage/skills), beats a site-wide skill of the same name inside it, so one client's version of a process can differ from the house version without either needing a new name. A sub-project also finds the skills of the projects above it, and where two levels have a skill of the same name the nearer one wins.

When to make one, and when not to

Make a project when work has its own knowledge, its own rules and its own files, and when you want it out of sight while you do something else. A client, a product, a house move: each earns a box.

Do not make one for a topic. A project is not a folder for chats: the sidebar already has folders. A project per campaign inside one client means shuffling agents, memory and files each time one starts. If a piece of work inside a client really does need its own agents, files and rules, make it a sub-project, so it keeps the client's shared knowledge in reach and adds its own. If all you want is to group chats, keep the client and use folders inside it.

Anything unfiled lives in Default Project, and there is no shame in staying there. It sits outside the tree: it cannot have a parent or be one.

Tidying up

Ask for a review now and then. "Go through my projects and tell me what looks like it is in the wrong place" starts an audit: what each project holds, which chats look misfiled, whether the knowledge connections still make sense. You get one grouped proposal, and nothing moves until you approve it. Manage > Project > Overview (/project) shows what a project holds, and Manage > Project > Automations (/project/automations) carries Move here for jobs and scheduled tasks, since each belongs to one project at a time.

Deleting is slow on purpose. Manage > Project > Advanced (/project/advanced) shows what would be affected, asks where the work should go instead, and hands the rest to a logged review that lists every chat and resource and waits for your confirmation. Anything left over lands in Default Project rather than vanishing. The project's default workspace is part of that review too. It cannot be deleted while the project still exists, so if you choose to delete it, that happens after the project is gone.

A project with sub-projects cannot be deleted. The page names them and keeps the review from starting until you have given each a new parent, or made it top level, in its Parent project field. A sub-project that moves stops getting what its old parent passed down, so connect anything it still needs to it directly.

See Projects for the parts and where they live, Organise work with projects for the steps, and Agents, delegation and team chat for specialists that work across projects.