In this article
A reusable assistant is useful when the same briefing work keeps recurring. It is less useful when you have not yet decided what a good result looks like.
Choose a narrow job for custom GPTs
Pick a task with a recognisable input and output. “Help our business” is too broad; “Turn approved meeting notes into a draft action register without inventing owners” is testable.
In a hypothetical training team, colleagues repeatedly turn workshop notes into facilitator outlines. A custom GPT could help organise approved material into a consistent structure, leaving the trainer to verify substance and adapt the session.
OpenAI's GPT creation documentation distinguishes instructions from uploaded knowledge and recommends preview testing. Creation access depends on the account and workspace permissions; check your own environment before planning a rollout.
Write the procedure before configuring the assistant
Describe the task as though a capable colleague were taking it over. State the purpose, required input, steps, output and reasons to stop.
For the hypothetical workshop assistant:
- Identify the intended audience and learning outcome.
- Use only the approved reference material supplied for this task.
- Create an outline with activities and questions clearly separated.
- Flag claims needing a source or subject expert.
- Stop if the audience, topic or source material is missing.
Keep the procedure short enough to maintain. A collection of contradictory instructions gathered from old conversations can make the behaviour harder to understand.
Include a concrete example of a good output and a problematic one. Explain the difference, such as an activity that fits the audience versus one requiring equipment the team does not have.
Separate reference material from behavioural rules
Use instructions to describe the job and the expected behaviour. Use approved reference files to support the content. Do not assume uploading a handbook automatically establishes every rule the assistant must follow.
Label the reference material with an owner and review date. Remove obsolete versions through the authorised process, so the assistant is not asked to reconcile conflicting guidance without context.
Avoid confidential employee information, private customer data or internal documents unless your organisation has explicitly approved the tool and use. Access to an upload button is not the same as permission to share a file.
Ethan Mollick's earlier GPT essay is useful historical context. Use current product documentation for present capabilities rather than assuming a demonstration from an older article still applies.
Build a test set that reveals weaknesses
Test the assistant with several kinds of input before sharing it. Use a straightforward example, an incomplete request, conflicting source material and an out-of-scope request.
| Test | Expected behaviour |
|---|---|
| Complete approved notes | Produces the required outline |
| No audience specified | Requests clarification |
| Two conflicting procedures | Identifies the conflict |
| Request for unsupported statistics | Flags the evidence gap |
Review the content, not just the formatting. In the workshop example, a beautifully structured activity fails if it teaches a claim the sources do not support.
Save the test inputs and your judgement. Reuse them after changing instructions or updating reference files.
Share the limits alongside the tool
Tell colleagues what the assistant is for, what information they may use and which checks remain their responsibility. A friendly name and polished description should not imply independent expertise.
Start with a small group that can give meaningful feedback. Ask what they had to correct, what was missing and whether preparing the input took more effort than expected.
If the assistant has connected actions, treat that as a separate authority decision. Producing a draft outline does not imply permission to email participants, publish training material or change a shared calendar.
Write a maintenance note before sharing
Include the assistant's purpose, instruction owner, reference-file owner and most recent review date in a short maintenance note. Record which test examples should be rerun after an update. This prevents reusable help from becoming an abandoned configuration that still looks authoritative.
In the hypothetical training team, an updated facilitator policy could make the old outline unsuitable. The reference owner should identify the change, while the instruction owner checks whether the procedure or examples also need revision.
Do not assume replacing a file is enough. Run the relevant test and inspect whether the assistant uses the new guidance correctly, including where the old and new versions differ.
Plan for absence as well. If the original creator leaves the team, who can update or retire the assistant through the workspace's authorised controls? Shared use needs continuity that does not depend on one person's private account.
If no one can maintain the instructions and references, a simple shared checklist may be a better option. Reusability creates value only when the organisation can keep the setup understandable and current.
Decide whether the reusable setup is worthwhile
Compare the complete task with your previous method. Include preparation, checking, correction and maintenance. A faster first draft is useful only if the rest of the workflow remains manageable.
Choose one repeated task and write its procedure today. Configure reusable help only after the procedure makes sense without the technology.
Continue through PiOfAI, the AI procedure guide and the personal AI workflow guide to connect the assistant to a process your colleagues can trust.
AI-assisted researched guidance from PeakBelt. Hypothetical examples are labelled in the text. See our editorial approach.