Reusable assistants: build one for a repeated job

What a reusable assistant actually is

A reusable assistant is ChatGPT set up for one specific job. It's still the same underlying model, but you've wrapped it in two things: standing instructions that shape how it behaves, and reference files it can draw on. Once it's set up, you open it and start a chat the way you'd start any chat, except it already knows its job.

The reason this matters for real work is repetition. If three times a week you open a blank chat and type the same 200 words of setup ("You're helping Fernway's operations team; use UK English; here's our tone; here's the policy we follow"), you're paying that setup tax every time, and so is anyone you'd hand the task to. A reusable assistant pays it once. It's the difference between re-explaining a task to a new temp each morning and training one person who then just does it.

ChatGPT gives you more than one way to build this, and the options changed in 2026:

• A Project works on every plan, including Free. It keeps its own instructions, uploaded files and all the chats about that job in one place. This is where most people should build, and it's what this lesson uses.
• On Business, Enterprise and Edu plans, a workspace agent goes further. It's built to be shared across your organisation, can connect to tools such as Google Drive, Slack and SharePoint, and can run on a schedule. It uses credits, and your admin may need to switch it on.
• You may also meet custom GPTs, the older way of doing this. Personal accounts (Free, Go, Plus and Pro) can no longer create new ones, and OpenAI plans to retire them on all plans on 11 December 2026 (some Enterprise workspaces have until 11 February 2027), helping creators move them to plugins. Existing GPTs keep working until then, but don't start anything new on one.

The craft is the same whichever you use: clear instructions, good reference material and proper testing. Learn it once here and it moves with you when the product names change.

Throughout this lesson we'll build one real assistant: a "Fernway feedback responder" that drafts replies to customer feedback in the house style, following the response rules from the feedback-process brief. It's a good candidate because it's repeated, has a fixed set of rules, and draws on a reference document. Those are the three signs a task is worth turning into a reusable assistant.

Where to build it

In the ChatGPT sidebar, choose New project and give it a clear name, such as "Fernway feedback responder". Then open the project's menu (the three dots) and choose Project settings to add its instructions. Upload your reference files to the project, and every chat you start inside it follows the instructions and can draw on the files.

Project instructions only apply inside that project, and they take priority over your general custom instructions while you're in it, so you can keep a different set-up for each job.

On a work plan with workspace agents switched on, the equivalent is Agents in the sidebar, then Create: describe the job, review the plan it drafts, then refine it in the builder. Whichever route you take, the real quality comes from editing the instructions by hand, because that's where you say exactly how the assistant should behave.

Instructions: the standing brief

The instructions are the heart of a reusable assistant. They're a longer, more permanent version of a prompt: the rules, tone, workflow and boundaries that apply to every chat in the project. Write them as if you're briefing a competent new colleague who'll do this task without you in the room: what the job is, how to do it, what to avoid, and what to do when they're unsure.

You are Fernway Group's customer-feedback responder. Your job: draft a reply to a piece of customer feedback that I paste in.

Rules for every reply:

UK English, warm and professional, never corporate or defensive.
Structure: acknowledge the specific issue, apologise sincerely if we got something wrong (without over-promising), say what happens next, and give a realistic timeframe.
Keep it to about 120 words unless I say otherwise.
Only commit to things our process actually allows (see the reference file). Never invent a refund, a discount, or a deadline I haven't given you.
If the feedback is ambiguous or you'd need information I haven't provided, say so and list what you'd need, rather than guessing.
Always end your draft with a one-line note flagging anything I should check before sending.

Notice what's doing the work here: the boundaries. "Never invent a refund" and "if ambiguous, say what you'd need" are what make an assistant safe to hand to someone else. An assistant that only knows how to succeed will confidently improvise when it hits an edge case, which is exactly when you don't want improvisation.

Reference files: reference, not rules

Reference files are documents you upload to the project so ChatGPT can draw on them when answering. How many you can add depends on your plan. The key distinction, and the one people most often get wrong, is this: files are for reference material, instructions are for rules and behaviour. Put your customer-response policy, your product facts, your style examples in files. Put "always use UK English, always structure it this way" in the instructions. If you bury a hard rule inside a long reference document, the assistant may or may not surface it; a rule in the instructions is applied every time.

For our feedback responder, the natural reference file is the response guidance: what we can and can't offer, the standard timeframes, a couple of example replies in the right voice. Upload that once, and every reply drafted in the project can lean on it.

When you draft a reply, check the response-guidance file for what we're allowed to offer for this type of issue, and apply the standard timeframe from that file. If the file doesn't cover this situation, tell me that explicitly instead of assuming; quote the closest relevant line so I can judge.

Test it before you trust it

This is the step that separates an assistant you rely on from one that just demoed well. Before you use it for real, and definitely before you share it, throw awkward cases at it and watch what it does.

Test with: a normal case (does it follow the structure?), an ambiguous case (does it ask, or does it guess?), an out-of-scope case such as a customer demanding something the policy doesn't allow (does it hold the boundary, or does it invent a refund to be helpful?), and a hostile case (does it stay warm and professional?). You're not checking whether it can write; you know it can. You're checking whether it behaves the way your instructions said, especially at the edges.

Test case. A customer writes: "This is the third time I've reported this and nothing's happened. I want a full refund and a month free, or I'm leaving." Draft the reply following your rules. I'm watching to see whether you invent commitments the policy doesn't allow.

When a test reveals a problem, fix the instructions, not just that one reply, then re-run the test. That loop, edit-and-retest, is how an assistant becomes dependable. Two or three rounds usually gets you there.

Try it now

Common mistakes

• Putting rules in the reference file. A hard rule buried in an uploaded document may not get applied. Rules, tone and workflow belong in the instructions; files are for reference the assistant draws on, not behaviour it must always follow.
• No boundaries in the instructions. An assistant told only how to succeed will improvise at the edges, inventing a refund, a deadline, a fact, precisely where you least want it. Always include "when unsure or out of scope, do X" rules.
• Sharing it before testing it. An assistant that writes one good reply in the demo can still mishandle the ambiguous or hostile case a colleague hits on day one. Run the awkward tests yourself first.
• Starting something new on a custom GPT. If you can still create one, it's tempting, but OpenAI is retiring them. Build in a Project, or a workspace agent if your organisation uses them, so you don't have to rebuild it later.
• Trusting a file-grounded answer because it came from your file (over-trust). "The policy allows a 10% goodwill credit" feels authoritative because the assistant read your document, but it can misread the file, blend two clauses, or apply a rule to a case it doesn't cover. Have it quote the line it's relying on, and check the source for anything you'll actually send or commit to. The file makes the reference handy; it doesn't make the reading infallible.

Check your judgement

Your reusable assistant follows the format but answers a policy question outside the source. What test belongs in its acceptance checks?

Keeping current

Projects, workspace agents and the retirement of custom GPTs are all moving quickly, so the buttons and plan details here may change. For the current details, see OpenAI's Projects in ChatGPT, ChatGPT workspace agents GPTs in ChatGPT and the custom GPT retirement FAQ, plus the ChatGPT release notes. Accurate as of 26 September 2026.