I would make a Project narrow enough that its name tells a colleague what belongs inside. “Cedar Metrics launch” gives the work an address. “Marketing” gives every old deck in the company somewhere to hide.
The benefit is a smaller briefing tax: less time reconstructing the same background in every conversation. The price is maintenance. Shared context needs an owner just as much as a shared spreadsheet does.
Give the Project a specific job
A useful Project has a durable purpose. A product launch, a customer research program or a recurring pipeline review creates several related deliverables that draw on the same facts. The Project holds that common context while individual chats handle different outcomes.
For fictional Cedar Metrics, I would create “Q4 reporting launch” and define the scope: positioning, approved proof, audience and launch deliverables. That is enough to make decisions about what belongs. A payroll export does not belong because it happens to be a spreadsheet. Last year's sales deck belongs only if its historical role is explicit.
The name is an operational choice. If the title is broad enough to absorb every document, the sources will eventually disagree without anyone noticing. Start with one outcome and expand only when the shared context actually remains shared.
TipWrite a one-sentence purpose before adding files.
Separate project context from a chat
The Project provides common files and instructions. A chat carries the specific request, discussion and result for one task. I would start separate chats for the launch brief, follow-up email and enablement notes, then refer to the shared sources as needed.
That arrangement makes review easier. A colleague can inspect the email task without scrolling through an unrelated argument about slide layout. The Project is the filing cabinet; each chat is a work order. The cabinet should help you find the work, not become the work itself.
Do not assume every past sentence appears verbatim in every future response. Ask the agent to identify which sources it used for material claims. Shared organization reduces repeated setup, but it does not remove the need to supply decisive context or verify that the relevant file was actually consulted.
TipBegin each chat with the desired deliverable and the source set that should govern it.
Choose cloud sources or local folders deliberately
A ChatGPT Project on the web uses uploaded or connected sources. It does not provide automatic access to a directory on your laptop. Desktop can also work with local projects tied to folders, and those have a different relationship to the filesystem.
For a shared campaign brief, uploaded approved documents may be sufficient. For a content repository with templates and a build script, a local project may be more appropriate. Choose based on what the agent must read and change, not on which label sounds more organized.
If a task says a file is missing, check the environment. A path in your message is not an upload. Likewise, a document visible to you in a source application may be unavailable to the connected account. Confirm access with a harmless source before starting the larger task.
TipUse a small known file to verify that the Project can reach the intended material.
Write instructions that settle recurring decisions
Project instructions should answer questions that otherwise recur across tasks: who the audience is, which positioning is current, how sources should be cited and what requires review. Keep them short enough that a human maintainer can see contradictions.
For Cedar Metrics, the instructions might require operator-to-operator language, a link beside quantitative claims and an explicit unknown when the packet lacks evidence. They can also identify the approved positioning document by name. Avoid putting changing campaign metrics in the instruction text when a dated source file is the better home.
The instructions define behavior; the files supply evidence. Mixing both into a long paragraph creates maintenance trouble. When the positioning changes, you want one clear place to update the facts and a stable rule explaining how those facts should be used.
TipKeep frequently changing numbers in dated sources, not permanent instructions.
Build a small source register
A source register is a short list of the material the Project should rely on, with an owner, date and role for each file. It can be a plain document. The goal is to distinguish current truth from examples, historical notes and unfinished drafts.
An illustrative register might identify positioning-2026-09-22.md as authoritative, approved-proof.md as the permitted evidence and launch-drafts.md as work in progress. That makes it harder for a polished old draft to quietly become the source of a new claim. Format is a poor proxy for authority.
Ask ChatGPT to flag contradictions rather than silently choosing a winner. If a sales deck promises a capability absent from the current product note, someone needs to resolve that. A Project should expose that disagreement while the work is still a draft.
TipLabel historical material explicitly so it cannot masquerade as current guidance.
Run one task that tests the setup
The first test should require the Project to use both its instructions and sources. Ask for a launch brief with supported claims and unknowns. Include a claim that is tempting but unsupported, such as a guaranteed percentage improvement, and instruct the agent to exclude it unless the approved proof supports it.
A useful result cites the current positioning, uses the specified audience and leaves unsupported performance numbers out. If it fails, inspect the context before adding more instructions. Was the approved source accessible? Was its role clear? Did another document contradict it?
I would preserve the successful test as an example, including the source register and acceptance checks. It becomes a small onboarding exercise for another teammate. A working example teaches the Project's purpose more effectively than a page explaining why everyone should use it.
TipTest the same request after replacing an authoritative source.
Maintain the Project when the business changes
A launch evolves. Features change, customer proof expires and the audience becomes more specific. Set a maintenance trigger for those changes instead of expecting the Project to infer the new truth from a stray conversation.
When a source changes, update the register, remove or clearly mark superseded versions and run the acceptance example again. If an old claim still appears, inspect which source is supplying it. This is ordinary content maintenance with an AI consumer attached.
For a team Project, decide who owns the source set and who reviews outputs. Sharing context can improve consistency, but shared access does not establish approval to publish or send a result. The output still needs the review appropriate to the workflow, particularly when customer claims or external communications are involved.
TipTreat a positioning change as a source-maintenance event, not just a new chat message.
Where Projects go wrong
The common failure is the junk-drawer Project. Too many unrelated files make relevance harder to judge and contradictions easier to miss. Split by durable outcome when the sources or audience diverge. A little duplication of structure can be healthier than one universal context bucket.
Another failure is treating memory as the Project's source of truth. Personal memory may help with preferences, but a team needs explicit, reviewable material. Keep the authoritative facts in sources the team can inspect. The memory guide explains the distinction.
Finally, resist making one chat carry the entire quarter. Separate deliverables, keep context current and retain accepted outputs where the team can find them. Which ongoing body of work deserves a clear address instead of another conversation called “New chat”?
How to set it up
Create the scope
Create a Project for one ongoing outcome and write its one-sentence purpose.
Add approved sources
Upload or connect current positioning, proof and relevant notes. Keep a source register with dates and owners.
Set recurring instructions
Specify audience, evidence rules, preferred format and the boundary between drafting and external actions.
Test and maintain
Run the launch-brief example, verify its claims and repeat the test when authoritative sources change.
Frequently asked questions
When should I use a Project?
When multiple tasks depend on recurring context, sources or instructions.
Should every task become a Project?
No. A self-contained question may not need ongoing shared context.
Is a Project a local folder?
A ChatGPT Project is not automatically a local folder. Desktop local projects have separate filesystem access.
Should I keep all marketing work together?
Only if the sources and purpose remain coherent. Narrower Projects are often easier to maintain.
Can instructions replace source files?
Use instructions for behavior and sources for evidence. Changing facts usually belong in dated files.
Will every chat remember every earlier detail?
Do not rely on perfect recall. Identify decisive sources and verify their use.
How do I handle old documents?
Remove them or label their historical role and date clearly. Define which current source is authoritative.
What should I test first?
A small deliverable that must use the Project instructions and cite its approved sources.
Sources & further reading
ChatGPT and Codex change quickly. This page was last reviewed September 22, 2026; verify time-sensitive details against the official docs above before relying on them.
Related GTM workflows
Use these existing playbooks to explore the business workflow. Adapt their tool-specific steps to your chosen environment and check the result.