ChatGPT Projects and Claude Projects: Build a Custom Assistant

ChatGPT Projects and Claude Projects: Build a Custom Assistant

A project in ChatGPT or Claude is a workspace that stores instructions and reference files, so every new conversation inside it starts with the same context. It is the closest thing to a custom assistant for a single recurring task, and it is what most teams mean when they search for ChatGPT Projects and Claude Projects as a custom assistant. To build one, pick a recurring task, write short instructions covering role, format and limits, attach a few reliable documents, and name one person who reviews them on a fixed cycle. The initial setup is the easy part. What keeps the project useful is the update routine.

Key takeaways

• A project suits tasks that repeat and depend on the same rules, the same tone and the same documents.
• Instructions should say who the AI is for that task, what to deliver, in what format, and what it must never do.
• A few good files work better than a whole folder dumped in, and each file needs a review date and an owner.
• Context ages: without a review routine, the assistant keeps answering with rules the company has already changed.
• Personal data, secrets and third-party documents call for a decision up front, not improvisation.

What is a project and when is it worth it?

In both tools the idea is similar: you create a named space, write instructions that apply to every conversation inside it, and attach files the assistant can consult. Instead of pasting the same background text every time someone opens a chat, the context is already there. The details differ between ChatGPT and Claude (how files are consulted, what is shared with the team, which plans include the feature, and what the limits are). Check the official documentation of each product before you decide, because these points change over time.

A project is worth it when the task has three traits: it happens often, it follows rules that fit on a page or two, and it depends on stable reference material. Common examples: drafting replies to quote requests, summarizing meeting notes in the company format, reviewing copy against a brand guide, preparing the first version of weekly reports.

It is not worth it when the task is one-off, when each case requires real-time lookups in internal systems, or when the content is too sensitive to leave the company environment. In those cases a project gives a false sense of control.

A note on sources: the feature descriptions here come from the tools' documentation and should be verified there. The recommendations on structure, routine and review come from implementation experience and are best practices, not official rules.

What should the project instructions say?

Instructions are the assistant's contract with the task. Long, vague text hurts, and short, specific text helps. A good instruction block usually has these parts:

• Role and goal: who the assistant works for and what result the task delivers.
• Audience and tone: who will read the output and how the company speaks to that person.
• Output format: a fixed structure, approximate length, what comes first and what stays out.
• Allowed sources: which project files count as truth and what to do when the answer is not in them.
• Limits: what the assistant must never promise, invent or decide on its own.
• When to stop and ask: a list of situations where it should request information or flag human review.

The instruction for missing information is the most underrated. Write something like: if the data is not in the files, say you did not find it and list what is missing, without estimating. This reduces answers that sound right and are wrong. If you already write instructions for support agents, the reasoning is the same as in how to write instructions for an AI support agent.

Avoid pasting entire policies into the instructions. Instructions say how to work, and the reference file says what is true. Mixing the two makes updates harder, because you end up editing the contract every time a list price, deadline or internal rule changes.

Which reference files go in and which stay out?

The practical rule: include what the assistant would need to consult to do the task well, and nothing more. Anthropic's engineering material on context engineering for agents describes context as a limited resource and says the goal is to gather the smallest set of information that leads to the desired result. For a project used daily, that translates into curation. To understand the technical limit behind this, read about the context window in AI.

These go in well:

• A tone guide and approved examples of good replies or deliverables.
• Business rules in a lean version, with a review date at the top of the file.
• Document templates (proposal, meeting notes, report) with the fields already defined.
• A glossary with company terms and the correct spelling of products and services.
• A list of frequently asked questions the team has already answered.

These stay out:

• Spreadsheets with customer data, signed contracts, and any file with personal data without a clear need.
• Old versions and drafts that contradict each other. The assistant cannot tell which one is current.
• Long documents nobody has reviewed, included only because they were at hand.
• Credentials, access keys and passwords, in any format.

Give files names that explain the content and the version, such as tone-guide-reviewed-month-year. When the assistant cites a source, the file name helps the team check it.

How to build your first project, step by step

Start small, with a single task. The sequence below works in both tools.

• Step 1: choose the task and describe how it is done today, with input, output and who reviews it.
• Step 2: gather three to five real, already approved examples, with personal data removed.
• Step 3: write the instructions using the six parts from the previous section, in one page.
• Step 4: select the reference files, check that they do not contradict each other, and put a date and an owner on each.
• Step 5: test with old cases whose correct result you already know and compare side by side.
• Step 6: note where the assistant got it wrong and fix the cause, which is usually an ambiguous instruction or an outdated file.
• Step 7: release to a small group, with the rule that every external deliverable goes through human review.
• Step 8: put the project's first review on the calendar before you release it.

Step 5 is what separates a useful project from a nice demo. If you have ten past requests and know how well they were answered, run them and look at the differences. To structure this kind of check at larger scale, OpenAI's guide to evals shows the logic, even if your own test starts in a simple spreadsheet.

Illustrative scenario: replies to quote requests

Illustrative scenario: a technical services company receives quote requests by email and through a web form. Today each salesperson writes the reply from scratch and the tone varies. The manager creates a project called First quote reply.

The instructions say the assistant prepares a draft with a greeting, a summary of what the customer asked for, the questions still needed to quote, and next steps. They forbid stating prices and lead times, because those depend on a human assessment. The reference files are the tone guide, two approved reply templates, the list of services offered with a short description, and a document with the standard intake questions.

The salesperson pastes the customer's request, removes unnecessary data and receives the draft. If the request mentions a service that is not on the list, the assistant flags it instead of inventing something. The salesperson reviews, adjusts and sends. Each month, the manager checks whether the service list and the standard questions still reflect the operation and replaces the file, keeping the review date at the top.

Note what the project does not do: it does not set prices, it does not access the company's systems, and it does not send anything on its own. That boundary is deliberate.

How to keep context current without creating bureaucracy

The most common mistake is treating the project as a one-time installation. Months later, the assistant is still following a policy the company has replaced, and nobody notices because the text is still well written. Three habits are enough to prevent this.

First, assign an owner. One person answers for the project, even if several people edit it. Second, set a review calendar, with a frequency proportional to how fast the subject changes: rules that change every week need a weekly review, and tone guides can wait longer. Third, keep a short change log with the date, what changed and why, either in the file itself or in a separate document.

One extra trigger helps: whenever someone corrects the same assistant error twice, it becomes a maintenance item. Either the instruction needs to be clearer, or a file is missing, or a wrong file is present. Fixing it only in the chat solves that one case and leaves the problem in the project.

Finally, decide when to retire it. If nobody has used the project for a long time or the task has changed, archive it. An abandoned project with old rules is a risk, not an asset.

What data and security precautions apply?

Projects concentrate context, and concentrated context deserves rules. Before attaching any file, answer: does this document contain personal data? Does it need to? Who on the team will have access to the project? Where does this data go when I use the tool? On the last question, read about international data transfer under LGPD when using AI providers and consult the guidance from ANPD, Brazil's data protection authority. Also define what the team may or may not put into the tools, as described in company policy for employee ChatGPT use.

There is also the risk of instructions hidden in files or pasted text. A third-party document can contain commands that try to divert the assistant. The prompt injection protection guide explains the problem and the defenses. In day-to-day project use, the simplest defense is to attach only material the company produced or reviewed, and never act on an output without reading it.

In the method we use in consulting, a project goes through the same four stages as any AI use. Map: describe the task as it is done today and who reviews it. Limit: define which data goes in and which actions the assistant never performs. Pilot: test one real task with known cases and an agreed success criterion. Transfer: hand over an owner, a review calendar, and the decision to expand, adjust or stop.

Frequently asked questions

What is the difference between a project and a custom GPT or custom assistant?

A project groups conversations, instructions and files in one workspace, and is designed for an ongoing line of work. Custom assistants are usually packaged for reuse and broader sharing. The boundaries between these features change, so check each tool's current documentation.

How often should I review the reference files?

It depends on how fast the subject changes. Commercial rules, lead times and internal policies need a short review cycle, while tone guides and glossaries can wait longer. What matters is that the date and the owner are written in each file and that the review is on the calendar.

Can I put customer data in the project?

Only if there is a clear need, an adequate legal basis and a defined access rule, and the first choice should be to remove or anonymize whatever is not essential. Before deciding, understand where the data is sent and what the tool's policy says. When in doubt, align with whoever handles LGPD in your company.

Does a project replace training or fine-tuning a model?

No. A project supplies context to each conversation but does not change the model itself. For most recurring office tasks, clear instructions and good reference files are enough, and fine-tuning is left for specific cases that justify the effort.

Sources

• Anthropic: Effective context engineering for AI agents
• OWASP: prompt injection prevention
• OpenAI: evals guide
• ANPD: Autoridade Nacional de Proteção de Dados