Set the project's intent

Project Data is the project’s memory of what it is trying to do: the decisions it has taken, the requirements it is working to, what is in and out of scope, the risks it has named, and the questions still open.

It is the answer to “what does this project already know”, and it is deliberately not a document anybody maintains by hand.

What it holds

Six sub-tabs, each with a count:

Sub-tab	What lands here
Decisions	Calls that were made, and the question each one answers
Requirements	What the product has to do, functional and otherwise
Scope	In, out, and parking lot
Tasks	The work the intent implies, before it becomes real tasks
Risks	What could go wrong, with dependencies alongside
Questions	What is still unanswered, including anything blocking

Every entry carries where it came from, so a decision in the project traces back to the meeting that took it.

Two things write it

Project Data is read only in the project. You cannot type a decision into it, and that is the point: intent is a record of something that happened, not a wish list.

Merging a meeting. A meeting builds its own intent model as you talk. When you merge its outcomes, everything you did not dismiss is promoted into the project’s, tagged with that meeting.
Extracting intents from a repository. A connected repository can be read by an agent and turned into candidate requirements and scope items reconstructed from the code. You review the candidates before any of them land. See connect repositories.

So the way to change a project’s intent is to hold the conversation that changes it. If a decision was wrong, take a new decision in a meeting and merge it.

How it steers a meeting

A project is not a folder the conversation happens to sit in. Two things carry it into the room.

The first turn opens with what the project already knows

When a meeting starts in a project, before your team answers you, the platform retrieves the most relevant prior meetings, meeting summaries, and workspace items from that same project and puts them in front of the agents as related context.

It is a semantic retrieval rather than a keyword one, built from the meeting’s title, its description, and your opening message, so a meeting called “Shaping: warn before a route crosses a closure” pulls up the conditions-feed discussion without anyone naming it. Up to five documents are carried in, and the retrieval runs once per meeting rather than on every turn: it is there to open the conversation in the right place, not to keep interrupting it.

That is why the same question asked in two different projects gets two different answers. It is also why holding a conversation in the wrong project is worse than it looks: the room is primed with the wrong history.

The conversation’s outcome is merged back into the same record

A meeting builds its own intent model as you talk, and merging it promotes what you did not dismiss into the project’s. So the project’s intent is the accumulated result of every conversation held in it, and the next conversation starts against that accumulation.

Steering a meeting is therefore mostly upstream work: put it in the right project, and set its topics for the part the project’s history cannot supply.

What else reads it back

The marketing side reads the intent as product truth. Objectives, functional requirements, and in-scope items are lifted out of the model and injected into the grounded pass that writes marketing work, under an instruction that claims not supported by them are expectations to verify rather than facts to assert. That is what stops a launch post promising something the project never decided.

The counters on the project’s Overview tab read it too, which is the fastest way to see that a project has twelve requirements and four unanswered questions.

A project with no intent yet

A new project’s Project Data tab is empty, and nothing is broken. It fills the first time you end a meeting in the project and merge it. If you want it filled faster, connect the repository and extract intents from the code that already exists.

Next steps

Merge a meeting’s outcomes: the main way intent arrives.
Steer a meeting with topics and intent: where the decisions are actually taken.
Knowledge: what the related-context retrieval searches.