Create a Project and start working
A Project starts empty and fills up as you use it. Make one, describe the work you are doing, and let the context accumulate from there.
Audience: builders
Create it
Open the Projects page
Projects is in the top navigation. The list shows the Projects you and your teammates have built.
Click + Project
The round + Project button at the top of the page opens the create dialog.
Name it
The name becomes the workspace label and the URL slug, so name it after the work: "AP help desk", "FY26 Q1 close". The description is optional and lands on the Project card in the list.
Pick an icon and colour
Defaults are fine. Customize if the visual helps your team find it later.
Click Create project
The dialog closes and you land in the new Project, on its Conversations surface.
The Project starts with nothing in it but a starter Instructions.md. That is deliberate: what belongs in it is not obvious until you have done some of the work.
Start chatting
Do not go looking for things to configure. Open a conversation and describe what you are actually trying to do, the way you would brief a capable colleague who is new to your team.
I need to answer a vendor asking where invoice 4471 is. Our AP data is in Snowflake. Can you look it up and draft a reply?
The agent will do what it can and tell you what it is missing. That is the useful part: rather than guessing what a Project needs up front, you find out by being told.
Attach files to the conversation as you go. Drag them in, or use the attach control. Anything you attach is available to the Project from then on.
Add what the work asks for
When the agent says it cannot reach your AP tables, that is the moment to attach a data source. When it needs your mailbox, that is the moment to add an integration. When it writes in a voice your team would not use, that is the moment to open Instructions.
Each of those lives in the Project's Context, and nearly all of them can be created from the conversation you are already in rather than from a form.
Ask the agent to set it up. "Attach the AP data source to this project" and "write instructions capturing how we talk to vendors" both work. It proposes the change and you review it before it lands.
Keep what you learn
The habit that makes a Project compound is small and boring: when you correct the agent, say why.
"No, we always quote the payment date from the remittance file, not the invoice due date" is worth saving as a memory. Next time, and for everyone else on the team, it is already known. See Project Memories.
After a few cycles of this, the Project holds most of what a new colleague would need to be told. That is also the point at which the work is worth turning into a Workflow.