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), Automations (/automations) 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 sits at the top left of every page. 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 holds back anything that would have to be filed. The control turns dark 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. That moves those chats and nothing else, so for a whole piece of work ask your assistant instead.

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. 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.

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 (/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.

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, and it splits the memory that made that client's work good. Keep the client, and use folders inside it.

Anything unfiled lives in Default Project, and there is no shame in staying there.

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.

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.