Project context

A Project's context is everything it is made of and everything it can reach. Open a Project in Build and it is the tree in the sidebar.

Audience: builders

The Build view

A Project open in Build: the Operate and Build switch, the Context sidebar, the workspace, and the conversation

The Operate and Build switch. Build is the lens that shows what the Project is made of. See Operate and Build.
The sidebar, on the Context rail. The tree below, grouped by what each thing is for. Its other rail is Work items.
The workspace. Whatever you open from the tree lands here as a tab: a file, a Workflow, a data source, a work item.
The conversation. The fastest way to change anything in the tree. Describe what you want and review what it proposes.

How the tree is organized

The Context tree groups sections by what they are for, rather than listing them flat. Knowing the groups is most of knowing where to look.

Group	Holds	The question it answers
Automations	Workflows, Custom views	What this Project runs and shows
Files	The file tree, Instructions, Email templates	What it works with, and what it has been told
Data	Data sources, Data Collections	What it can query
Knowledge	Memories, Schemas, Skills	What it knows and how it is shaped
Tools	Verified logic, Integrations, MCP	What it can act with
This conversation	Whatever the open conversation has produced	What just changed, and by whom

Automations opens first, because what a Project runs is usually what you came to check on. Instructions and Email templates sit inside Files rather than beside it: they are documents in the Project like any other, and they are edited the same way.

Most of this can be created from chat. Nearly every section offers a "Create in chat" action that opens the composer seeded for that kind of thing. Describing what you want and reviewing what the agent proposes is usually faster than filling in a form.

Automations

Workflows→Repeatable processes this Project can run. Each run becomes a Work item that keeps its input, its result, and the trigger that started it.Custom views→Pages the Project draws for the people who operate it. One can be marked Home.

What the Project works with

Files→The Project's own file tree. Upload documents and folders, organize them, and reference them by name from a conversation or a Workflow.Instructions→Plain English guidance the agent reads at the start of every conversation and every work item in this Project.Email templates→Markdown templates the agent picks by name to reply to inbound email.Data→Attach a data source and let the agent write the queries, or attach a Data Collection when the questions need your vocabulary and approved SQL.

Knowledge

Project Memories→Memories scoped to a single Project. Terminology and rules that should not leak elsewhere.Schemas→Structured shapes for inputs, outputs, and validation the agent uses every time.Skills→A focused capability your Project can call by name. Reusable across Projects when published.

Tools

Verified logic→Operations your team reviewed and approved for the agent to take. The approved version is pinned when a run starts.Integrations→Pick a credential someone already created, or connect one yourself for the OAuth-based providers.MCP servers→Mount one of the workspace's connected MCP servers here so this Project can call its tools and read its resources.

Project scope and shared scope

Some of these exist at more than one level. A Memory, a Skill, or a piece of verified logic can belong to this Project, or to your team or organization, where every Project gets it.

The tree shows both, grouped by scope, and the sections that have a shared counterpart offer a link across to it. Which scope to author into is a real decision: see Shared versus project scope.

Create one and start working Files