Using Projects

A Project gives you a pre-configured workspace where the context is already established before you type the first message. The model knows what it's working on, what tools it has, and what constraints apply - because you defined all of that once in the project setup.

Starting a conversation

Type in the chat input on the project home page and send. The model receives your message along with everything assigned to the project: the system instructions, the list of available tools, and any knowledge bases configured as reference.

You don't need to re-establish context each time. A project for customer support already knows it's helping the support team. A project for engineering already knows the coding standards and has access to GitHub.

Using @ mentions

Type @ in the project chat input to open a picker showing everything assigned to the project: prompts, Tasks, knowledge bases, and connectors. Select any item to direct the model to use it.

Use @competitor-analysis to research Acme Corp,
then pass the findings to @briefing-generator

@ mentioning a tool is an explicit directive — "use this one now" — as opposed to leaving the model to choose. You're not limited to one @ mention per message; name several and describe the order you want them applied. For how the model picks tools when you don't @ mention one, and why clear tool descriptions matter, see Tools and Memory.

Chaining prompts and tasks

Because a project has multiple tools available simultaneously, you can chain them in conversation:

• Research with one Task, then summarize with a prompt
• Extract data using a connector, then format it with a template prompt
• Run a competitor analysis, then pass the findings to a briefing generator

Each step's output is available in the conversation context for the next step. You're orchestrating a sequence without writing any code - just describing what you want in natural language and referencing the tools by name.

Building on accumulated knowledge

If you've assigned a memory folder as Reference, the model automatically draws on it when relevant. If you've assigned one as Output, project and task results can get saved there over time.

This means a project can build institutional knowledge across sessions. A research project that saves findings to a memory folder accumulates them over time - later conversations can draw on everything that's been captured before.

A practical example: a competitive intelligence project with a scheduled research Task that saves to a "competitors" memory folder, and whose chat always has that folder as reference. When someone asks "what do we know about Company X?", the model searches the accumulated folder rather than starting from scratch.

Running a project in the background

Beyond live conversation, a project can run work autonomously. Toggle Run in background before sending a message to queue it as an async run. The run executes the full task without an open chat view, and when it finishes it produces a conversation thread with the result. You can send a task and close the tab, queue several runs at once, or treat the project like an inbox — describe what needs doing, submit, and move on.

Each background run tracks a status:

• Pending — queued, not yet started.
• Running — executing.
• Completed — finished; the run links to the conversation thread it produced.
• Failed — errored before producing a result.

Because a completed run is a full conversation thread, you can open it, read the result, and keep going — ask follow-ups, request revisions, or use it as the starting point for the next task.

Background runs suit a few patterns:

• Long-running research — research a topic with the assigned Tasks, save findings to a memory folder, and draft a summary, all in one run. Come back to a finished briefing.
• Repeated execution — the same project, tools, and context handle similar work on different inputs. You provide the input; the project holds the configuration.
• Parallel work — send multiple background runs in the same project. Each runs independently, and you return to several completed results.

Even without background mode, a complex task can unfold across a single conversation: the model has every assigned tool available and can invoke them in sequence, or spawn parallel subtasks — researching three competitors at once rather than one after another.

Example: a research and briefing project

• Instructions: "You research companies on request. Use the @company-research task to gather data, save the findings to the Intelligence folder, then draft an executive briefing with the @briefing-generator prompt and return the briefing text."
• Tools: company-research Task, briefing-generator prompt, CRM connector.
• Memory: Intelligence folder, assigned as both reference and output.

Type "Research Acme Corp", toggle Run in background, and send. You return to a completed briefing and an updated Intelligence folder — and the next time you ask about Acme Corp, the model has the earlier research as context.

Project configuration

The project home page has a settings control (the gear) that opens the Project configuration panel (the URL picks up a ?config=… parameter). This is where you edit everything the project applies to its chats. The panel's left-nav is organised into Settings, Tools, and Memories.

Settings has three sub-tabs:

• Instructions — edit the project's system message, the instructions applied to every conversation in the project.
• Settings — Project Details for the project's identity: an icon + color picker, Name, and Description. This tab also has a Danger Zone containing Delete Project, which permanently deletes the project and all its chats.
• Model — a Default Model selector plus Max Tokens, Thinking, and Effort controls that set how project chats run.

Tools assigns the prompts, tasks, connectors, and abilities the project chat can call, and Memories assigns the memory folders it can search. See Tools and Memory for both.

Sharing and team access

Open the Share dialog to control who can access the project. It has two levels of control:

• Organization access sets what every member of the org can do:
  • Private — only you, plus anyone added individually, can open the project.
  • Use project — every member can open the project and work inside it, seeing the same tools, system message, and knowledge base.
  • Edit settings — every member can also change the project's configuration.
• People with access shares the project with specific members. Use Add people to grant an individual access without opening the project to the whole organization.

Individual conversations stay private unless shared explicitly.

This is how teams standardise how they work with AI - everyone working in the same project uses the same tools and follows the same instructions, without each person needing to remember to set things up the right way.

What the model sees

When a project chat starts, the model receives a context block structured as:

1. Project owner instructions - your system message, framed as high-priority directives the model must follow
2. Built-in tools - web search and web fetch, if enabled
3. Integrations - each connected MCP server by name
4. Prompts and Tasks - each assigned tool listed with its name and description
5. Knowledge bases - each assigned folder listed with its role (reference, output, or both)

The model reads this context and decides which tools are relevant; @ mentioning a specific tool overrides that with an explicit instruction. See Tools and Memory for how tools are chosen and why clear descriptions matter.