Custom GPTs are the cheapest way to test whether packaged AI capability helps your team. Understanding what they do well — and where they stop — prevents both wasted effort and disappointment.
The three layers
| Layer | What it does | Needs a developer? |
|---|---|---|
| Instructions | Defines behaviour, tone, process, boundaries | No |
| Knowledge files | Reference documents it can draw on | No |
| Actions | Calls your API to fetch or change data | Yes |
Build the first two layers before considering the third. Instructions and knowledge files take an afternoon and answer the important question — is this workflow worth packaging at all? Actions are a development project, and building them before you know the answer is how budgets get spent on unused tools.
What works well
- Internal knowledge assistants over policies, procedures and documentation.
- Consistent document production — proposals, summaries, reports in your format.
- Onboarding support answering the questions new joiners repeat.
- Structured analysis applying the same framework each time.
- First-draft generation where a human reviews before anything ships.
Where they hit limits
| Limit | Consequence |
|---|---|
| Knowledge files are static | Re-upload when documents change |
| No memory between conversations | Each session starts fresh |
| Actions need an API you control | Legacy systems need an adapter first |
| Limited access governance | Enterprise controls are coarser than a custom build |
| Instruction following is imperfect | Long, rule-heavy instructions degrade |
| Platform-dependent | Behaviour can change with platform updates |
Static knowledge files are the constraint people notice last and regret most. If your reference material changes weekly, a knowledge file is a copy that quietly goes out of date.
Writing instructions that hold up
- State the role and scope in a sentence — what this GPT is for and what it is not.
- Define the output format precisely. Vagueness here produces inconsistency everywhere.
- Give worked examples of good output. These do more than any amount of description.
- Name the boundaries — what it should decline and escalate.
- Keep it as short as it can be. Long instruction sets are followed less reliably than short ones.
- Test against cases where you know the right answer before releasing.
Treat anything in a knowledge file or returned by an action as untrusted content. If a document contains text addressed to the assistant, it must not be able to change what the GPT does. This matters most once actions exist — retrieved data should never be able to authorise an action on your systems.
Actions: what building one involves
- An API exposing narrow, specific operations — not general query access.
- Authentication that identifies the user, not a shared key with broad rights.
- Input validation on everything, assuming parameters may be wrong.
- Field filtering so responses contain what the workflow needs and no more.
- Rate limiting against runaway loops.
- Logging of who invoked what and what came back.
This is a proper engineering task. Teams that treat it as configuration discover the security questions late.
Deciding whether to go further
A custom GPT is enough
- Internal users, reviewed output
- Reference material is fairly stable
- No sensitive data involved
- You are testing the idea
Build properly instead
- Customer-facing and unreviewed
- Live data is essential
- Audit and access control are required
- It must run inside your systems
Testing an idea, or ready to build actions? Tell us the workflow — we will say whether configuration covers it. See our ChatGPT plugin service, GPT Actions authentication, and enterprise deployment.