You will be able to set up a project with its own instructions and reference files for a job you do often.
Priya's custom instructions from lesson 6.1, Custom instructions: what to say once, cover what is true in every chat. But a lot of her work comes in recurring types, and each type has its own standing material. Staff announcements need the company's style guide, the list of depots and the past three announcements as examples, while policy questions need the employee handbook and interview preparation needs the job descriptions and the scoring sheet. Pasting those in every time is tedious, and putting them in custom instructions would distort every other chat.
This is what projects are for.
Many assistants offer a way to group related chats into a workspace with its own instructions and files. Depending on the product it may be called a project, a workspace, a notebook or something similar, and in some products a custom assistant you set up for one job does a similar thing. The details differ, so check your assistant's help pages for what it offers and what your plan includes.
The idea is the same across products. You create a project for one kind of recurring job. You give it instructions that apply only to that job, and you add reference files. Every chat you start inside the project then has those instructions and files available on top of your general custom instructions, while chats outside it carry on as before.
How the files are used varies. Smaller files may be included in full with every chat. Larger sets may be searched for relevant passages when you ask a question, the retrieval approach from AI fundamentals lesson 5.3, Retrieval: how an assistant looks things up. Either way, the lessons of module 5 still apply: ask for the source when it matters, and check it.
Put in what every chat for that job needs and nothing else. For most recurring jobs, that falls into four kinds of material.
Start with a style guide, even a short one covering voice, formatting and the words to use or avoid. Your corrected style description from lesson 2.2, Style samples and examples of what to avoid, fits here well. Facts the model cannot know: your products and prices, your policies, your team structure, the standard answers to common questions. Templates for the outputs you produce often, such as the structure of a weekly report. And good past examples, since lesson 2.1, One good example beats a paragraph of description, showed how much examples shape the output. The example set you built in lesson 2.4 belongs in a project.
The project instructions should say what the job is and how to use the files. Priya's staff announcements project has five lines: "This project is for announcements to frontline staff. Follow the style guide in style-guide.pdf. Use the depot names and addresses exactly as listed in depots.xlsx. Match the length and tone of the three example announcements. Never state a policy detail that is not in the employee handbook; if it is not there, write [check with HR]."
She then runs real work in it. A new announcement now takes one line of context and the facts of the change, and the rest is already in place.
There is a risk that comes with this convenience. The model will use whatever is in the project's files, confidently and without any sense of whether they are out of date. An outdated price list in a project will be quoted to customers. An old version of the leave policy will be explained as current.
Daniel, the furniture shop's customer service lead from module 2, found this out when the shop raised its delivery fee. His replies project still had last quarter's fee schedule in it, and two customers were quoted the old fee before anyone noticed. Nothing in the replies looked wrong, because the model had no way to know.
So treat project files the way you treat any shared document. When the source changes, update the file in the project, and delete the old version rather than adding a new one beside it. Two versions of the same price list is worse than one old one, because the model may use either. A dated file name, such as fees-2025-07.pdf, helps you spot stale files at a glance.
Projects make it easy to upload a lot of work material at once: handbooks, client lists, internal reports. Before you do that in a personal account, check your company's rules. Many employers allow only certain AI tools for work data, or only the business versions of them, and some do not allow uploading internal documents at all.
Priya checked her company's AI policy first. It allowed the company's approved assistant for internal documents, so she built her projects there and not in her personal account. Lesson 8.2, Data settings and the rules at your workplace, covers how to find and read those rules.
Look at your own week and find the job you repeat most that always needs the same background material. That job, and the two or three files it always needs, is where your first project should start.
Create one project for a recurring job with instructions and at least two reference files, then run one real task in it.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).