Give your Project a source of truth.

Choose a useful Project boundary

Create a Project around work that shares sources and instructions: a client engagement, research question, or internal planning cycle. A single unrelated task may only need a Session. A Project becomes useful when the next conversation needs the same background without starting the explanation again.

Avoid treating one large Project as a company-wide filing cabinet. “Autumn supplier review” provides a clearer boundary than “Everything.” Write a short purpose statement naming the decisions the Project supports and the material outside its scope. This helps you recognize when a new file belongs somewhere else.

Record what the files mean

Upload the relevant documents, spreadsheets, PDFs, images, or presentations. Ask for a source register as an ordinary document you can inspect; it is a working convention, not a special Workspace indexing feature. Record the original filename, document date, source owner when known, and why the file matters.

Distinguish the date a document describes from the date you uploaded it. A September upload can contain July prices. Use descriptive filenames when you prepare files, and retain enough of the original name to trace them back. Do not infer that the newest filename is automatically the approved version.

For spreadsheet exports, record the reporting range and units alongside the filename. For meeting notes, distinguish the meeting date from a later edit date. For a combined research packet, identify which sections belong to which source. These details make a later citation useful: “September export, amounts in USD” resolves questions that a filename such as data-final.csv cannot answer on its own.

Resolve a fictional version conflict

Suppose fictional Cedar Studio has two supplier proposals and a meeting note. The note asks for a discount, but it does not prove that the supplier accepted it. The register below preserves that distinction. Ask the Agent to apply the same rule before calculating a comparison or writing a recommendation.

Keep earlier versions when they explain a decision, but identify their role explicitly. If you need to reorganize existing files, review the proposed changes before applying them. A history folder or dated naming convention is your organizational choice; this guide does not assume automatic version detection.

Put stable rules in Project instructions

Project instructions should explain the audience, preferred output, and source-selection rule. For example: “Use the September proposal for current terms. Cite the filename and section for each price. Keep proposed changes separate from accepted terms.” These rules are more useful than a general request to be accurate.

Keep temporary requests in the relevant Session. “Make this draft shorter” need not become a rule for every future report. Keep reusable specialist behavior in an Agent when it applies across Projects. Separating those concerns reduces the chance that yesterday’s edit becomes an unexplained constraint on tomorrow’s work.

Refresh copies deliberately

A Google file saved into a Project is a copy, not a continuously synchronized source. If the original changes, request a fresh copy and verify it in the destination Project’s Files tab. Note which copy replaces the earlier one before asking for an updated result.

When the Agent cites an unexpected file, pause the conclusion and ask for the input list. Missing access, similar filenames, and ambiguous instructions can produce different problems that look like “bad memory.” Confirm the source is actually available, correct the selection rule, and rerun only the affected analysis.

Test the organization in a fresh Session

Start another Session in the Project and ask which sources it should use for a small, familiar question. Inspect the answer and source locations. This tests your working setup more effectively than asking whether the Agent understands the files. Make the expected answer something you can check independently.

Finish important work by opening the saved result in Preview or Files. Keep the source register with it, and note unresolved questions. Project organization helps you resume work, but an answer in a conversation is not proof that a requested file was created. Verify the actual artifact before relying on it later.

Try it with a small example.

Before you use the result.

• Current and historical versions have explicit roles.
• Dates refer to the source, not just the upload.
• A fresh Session chooses the expected input.
• The final file opens from Project Files.
• Google copies are refreshed only when requested and checked.