Projects as an Agent Workspace

Beyond conversational use, a Project can function as an agent workspace - a place where you define the context, assign the tools, and then send tasks that run autonomously, with or without you watching.

Background runs

Toggle Run in background before sending a message to queue the task as an async job. The task runs without opening a chat view - the model executes the full task, and when it completes, a conversation thread is created with the result.

This means you can:

• Send a task, close the tab, and check back later
• Queue several tasks simultaneously without waiting for each to complete
• Treat the project like an inbox: describe what needs doing, submit, move on

Each background run tracks its status: pending, running, completed, or failed. Completed runs link to the conversation they produced - you can open it, read the result, and continue the conversation from there.

What this enables

Long-running research tasks

Ask the project to research a topic using assigned workflows, save the findings to a memory folder, and draft a summary - all in one background task. Come back to a completed briefing rather than a half-started conversation.

Repeated task execution

The same project, with the same tools and context, can run similar tasks on different inputs. A content analysis project handles articles. A lead research project handles company names. You're not rebuilding the setup each time - the project holds the configuration and you just provide the input.

Parallel work

Send multiple background tasks in the same project. Each runs independently. You return to several completed results rather than a queue.

Multi-step orchestration in conversation

Even without background mode, a complex task can unfold across a single conversation. The model has all assigned tools available and can invoke them in sequence. For tasks that can be parallelised, the model can spawn multiple subtasks simultaneously - for example, researching three competitors at once rather than one after another.

Continuing from a completed run

A completed background run is a full conversation thread. Open it, read the result, and keep going. Ask follow-up questions, request revisions, or use it as the starting point for the next task.

Building a project for agent use

The quality of a project-as-agent-workspace depends on three things:

1. A specific system message

The system message is what makes a project useful for autonomous tasks. "You are a research assistant for our competitive intelligence team. When asked to research a company, use the competitor-research workflow, save findings to the intelligence database, and return a structured summary in this format: [format]."

The more precise the instructions, the more reliably the model handles tasks without needing to ask for clarification.

2. The right tools assigned

Assign only the tools the project needs. A focused set is more reliable than an exhaustive one. If the project's purpose is lead research, assign the lead-research workflow, the CRM connector, and the leads knowledge base - not every workflow in your library.

3. Knowledge bases wired correctly

Reference databases give the model background context without you having to paste it in. Output databases let the model save results so future tasks can build on them. A well-configured project gets more capable over time as the output database grows.

Example: a research and briefing project

System message: "You research companies on request. Use the @company-research workflow to gather data. Save the findings to the Intelligence folder. Then draft an executive briefing using the @briefing-generator prompt. Return the briefing text."

Assigned tools: company-research workflow, briefing-generator prompt, CRM connector.

Knowledge base: Intelligence folder (output - receives saved findings; reference - available for follow-up questions).

Usage: type "Research Acme Corp", toggle Run in background, send. Return to a completed briefing and an updated Intelligence folder.

The next time you ask about Acme Corp, the model has the earlier research as context.

The difference from a workflow

A workflow is a fixed automation - defined steps, predictable output. A project is an open-ended workspace - the model decides how to apply the available tools based on your instructions.

Use workflows for repeatable, structured processes where you know exactly what steps should run. Use project chat for tasks where the shape of the work varies and you want the model to apply judgment about which tools to use and in what order.

The two work well together: build workflows for the deterministic parts, assign them to a project, and let the project orchestrate when to use them.