Custom GPTs vs Claude Projects vs Gemini Gems: how to build a reusable AI assistant

What a reusable assistant is

A reusable assistant is a saved setup: standing instructions, optional reference files, and sometimes tools, that every new conversation starts with. Instead of pasting the same three paragraphs of context each time, you open the assistant and go straight to the task.

Three things it is not. It is not a fine-tuned model; the underlying model is the same one everyone gets. It does not learn from use; what you put in the instructions is what it knows tomorrow. And it is not a substitute for judgment; it drafts, you decide.

OpenAI calls these custom GPTs (and, in a lighter form, Projects). Anthropic calls them Claude Projects. Google calls them Gems. Microsoft calls them Copilot agents, built in Copilot Studio or with the agent builder inside Copilot Chat. The mechanics differ; the discipline of writing good instructions is the same across all of them.

The three options compared

Custom GPTs are the most productized: you can hand one to a colleague and it feels like a small app. Claude Projects feel more like a workspace: instructions, a shelf of documents, and the running history of everything you have done in that context. Gems are the lightest weight and the fastest to set up.

Two adjacent options are worth knowing. ChatGPT Projects are folders with files and instructions, closer in spirit to Claude Projects than to custom GPTs. And Anthropic's Skills let you package instructions and scripts that Claude loads only when they are relevant, which helps when you have many procedures and do not want every one of them in every chat.

When to build one

Build a reusable assistant when three things are true. You have done the same task at least three times. The context you paste each time is more than a paragraph. And the output has a consistent shape you can describe.

Skip it when the task is genuinely different every time, when it depends on live data the assistant cannot see, or when the stakes are high enough that you would review every word anyway. A good test: if you cannot write down the rules for a good result, you are not ready to hand the judgment to an assistant.

Common candidates: recurring reports, formatting jobs, editing to a house style, answering questions from a fixed set of documents, first-pass triage of requests, and drafting in a repeatable format such as release notes or job descriptions.

How to write the instructions

Instructions are a job description for the assistant. Write them in this order.

1. Role and audience. Who the assistant is and who it serves. "You are an editor for the internal communications team at a mid-sized hospital system."
2. The job. One paragraph on what it does and the result the user wants.
3. Inputs to expect. What the user will paste or attach, and what to do if it is missing or messy.
4. Steps. The order of operations, especially anything to do before writing.
5. Output format. Headings, length, tone, and what to leave out. Be specific; this is where most of the value is.
6. Rules. Hard constraints, phrased as short bullets. Never invent names or figures. Keep the original meaning. Ask before assuming.
7. When unsure. Tell it to ask a clarifying question or say what it could not do, rather than guess.
8. Examples. One or two short input-and-output pairs, or point to examples in a knowledge file.

Keep the instructions under a page. Put long reference material (style guides, SOPs, templates) into knowledge files and tell the instructions to consult them. Test with a bad input as well as a good one: paste half a document, or notes in the wrong language, and see what it does.

Three worked examples

A meeting-notes formatter

The most-built assistant in most companies. Paste raw notes or a transcript, get a clean recap. Here is a complete set of instructions you can paste into any of the three tools:

You are a meeting-notes formatter for [TEAM NAME] at [COMPANY]. Users will paste raw notes or a transcript from an internal meeting. Your job is to turn them into a recap that someone who missed the meeting can act on in two minutes.

Steps:
1. Read the whole input before writing.
2. Identify decisions, action items, open questions, and anything that needs a follow-up meeting.
3. If an action item has no clear owner or date, mark it [OWNER?] or [DATE?] rather than inventing one.

Output format:
- Title line: meeting name and date, if present in the notes.
- Decisions: bullets, one line each.
- Action items: a table with Owner, Task, Due date.
- Open questions: bullets.
- Notes: anything important that does not fit above, under 120 words.

Rules:
- Use only what is in the notes. Never add names, dates, or commitments that were not stated.
- Keep the whole recap under 300 words unless the meeting ran over an hour.
- Match the team's tone: direct, no filler, no praise.
- If the input is not meeting notes, or is too short to summarize, say so and ask what the user wants.

Attach one example of a recap the team liked as a knowledge file. That single example will do more for consistency than another page of rules.

Test it with three past meetings. Compare each output against the recap a person actually wrote. Where the assistant invented an owner or dropped a decision, add a rule, re-run all three, and only then share it.

A brand-voice editor

Instructions, in short: "You are an editor who rewrites drafts to match our brand voice without changing their meaning. Consult the style guide in your knowledge files. Return the edited text, then a short list of what you changed and why. Never alter facts, numbers, names, or claims. If a sentence cannot be improved without changing its meaning, leave it and flag it."

Knowledge: the style guide, five to ten paragraphs the team considers on-voice, and three examples of off-voice writing paired with the corrected version. The before-and-after pairs teach more than the guide does.

The check: read the change list every time. An editor that quietly softened a legal disclaimer is worse than no editor.

An SOP explainer

Instructions, in short: "You answer questions from new employees about our operating procedures using only the documents in your knowledge. For each answer, cite the document and section. If the question is not covered, say so and tell the person to ask their manager. Never guess at a procedure, and never answer questions about pay, benefits, or disciplinary matters; direct those to HR."

Knowledge: the SOPs as clean PDFs or documents, one per file, with clear titles. Rename files before uploading; the assistant sees the file names and uses them.

The check: ask it ten questions you know the answers to, including two it should refuse. When it gets one wrong, fix the document before the instructions; usually the SOP itself was unclear.

Sharing and governance

A shared assistant is a shared document with opinions. Treat it like one.

• Knowledge files are readable. Anyone who can chat with the assistant can, with enough effort, extract most of what is in its files. Do not upload anything you would not share directly with every user.
• Name an owner. Every shared assistant needs a person responsible for its instructions and a date for the next review. Quarterly is fine.
• Keep the source outside the tool. Store the instructions and the list of knowledge files in a plain document on your team's drive. Vendors change their builders; you should be able to rebuild in an afternoon.
• Use the business tier for anything with company data. Team and Enterprise plans from all three vendors let admins control sharing, see what exists, and keep data out of training. Consumer plans do not offer the same controls. Never put confidential data into a consumer AI tool unless your organization has approved it.
• No secrets in instructions. Passwords, API keys, and customer identifiers do not belong in instructions or knowledge files. Custom GPT Actions store credentials separately for exactly this reason.
• Watch for injected instructions. If an assistant browses the web or reads documents from outside your team, text inside those sources can try to redirect it. Keep browsing off for internal assistants unless the job needs it.

If you work in a regulated field, add one more rule: the assistant's knowledge must not contain PHI, privileged material, or regulated personal data unless compliance has approved the specific tool and plan.

Limits to plan around

• Files are retrieved, not memorized. With larger knowledge bases, the assistant pulls in the passages it thinks are relevant, and it can miss the right one. Ask it to quote its source whenever accuracy matters.
• Instructions fade in long chats. After many turns the assistant may drift from its rules. Start a fresh chat for each new task.
• No learning between chats. Corrections you make today do not carry over unless you edit the instructions. Keep a running list of fixes and apply them at review time.
• File limits exist. Each tool caps the number and size of knowledge files. Check the current limits before planning an assistant around a whole document library; for large collections, NotebookLM or an enterprise search tool is a better fit.
• Nothing is portable. A custom GPT does not export to a Gem. Your plain-text instructions and your example files are the portable part.
• Hallucination does not go away. A well-instructed assistant is more consistent, not more truthful. Verify anything that will be sent, published, or acted on.

Next steps

• Compare the underlying assistants in ChatGPT vs Claude vs Gemini vs Copilot.
• Sharpen the instructions with the prompt engineering guide and the prompt builder.
• Take the next step: Automate your workflow with AI.
• Set ground rules for shared assistants with How to write a team AI policy.
• Terms used here: custom GPT, system prompt, retrieval-augmented generation, and prompt injection.
• Tool pages: ChatGPT, Claude, Gemini, and NotebookLM.