A Custom GPT is your own saved version of ChatGPT, set up for one job you do again and again. You control three parts: the written instructions, the reference files you upload, and optional connections to other software. Get the instructions right first, keep the files few and dated, and add connections last, because each layer can break the one before it.
Imagine you built a Custom GPT for your Monday status update. In testing it mostly works. Then it turns a missing number into “solid growth,” skips half of your section order, and a teammate asks whether you can “just connect it” to the team’s ticket tracker. Writing the first version was easy. Keeping the three layers in order is the real work.
The first post in this tutorial covered the first build: one job, no connections, only files that are safe to share, and testing on real inputs. This one shows how to write instructions that stick, keep reference files from going stale, and decide when a connection to outside software (OpenAI calls these actions) is worth it. New to ChatGPT? Start with Learn ChatGPT. To decide whether a GPT is the right tool at all, see the ChatGPT product map. Related guides: everyday ChatGPT, ChatGPT Work and ChatGPT Codex.
Button labels and limits keep moving, so treat this as a field guide from vendor help pages checked in July 2026. Before you set team standards, check Creating and editing GPTs, GPTs in ChatGPT, Configuring actions in GPTs, Troubleshooting GPTs, and openai.com/chatgpt again.
Three layers, three jobs
OpenAI splits a GPT into several pieces. After the name and description, three layers matter most to everyday builders.
| Layer | Job | Good content | Bad content |
|---|---|---|---|
| Instructions | How the GPT behaves every time | Role, audience, steps, format, refusals, short examples | 200 conflicting “don’ts,” secret policies, data tables that change daily |
| Knowledge | Reference material the answers can lean on | Stable glossaries, style guides, templates, dated handbooks | Daily forecasts, raw tickets, credentials, “whole drive” dumps |
| Actions | Call outside software you define (through an API, which is a way for programs to talk to each other) | Approved connections with a sign-in method and a plan for when they fail | Day-one Jira “magic,” unreviewed outside services, changes made silently |
OpenAI’s help pages say knowledge files work best as reference material. Rules, tone, and how the work gets done belong in the instructions, and not only in uploaded files. Actions are set up in a separate place and connect to outside software. A GPT may also use built-in features such as web search, image generation, a drawing and editing pane called canvas, and code tools, plus apps in some setups. OpenAI notes that a GPT can use apps or actions, but not both at the same time. That detail matters later, and for now the priority is still the instructions.
Rule of thumb: Instructions tell the GPT how to work. Knowledge tells it what documents to lean on. Actions let it call systems outside ChatGPT. Fix the first before you add the second, and hold off on the third until the first two are boring.
Instructions that stick
Instructions apply to every conversation with that GPT, so they are less a wish list and more a procedure to follow. When they fail, people blame “the model” and pile on more adjectives. Better builders shorten the instructions, give them structure, and test them.
The six-part skeleton
Use this six-part outline for almost every work GPT, and expand a part only where the job needs it.
- Role: who the GPT is for this job (careful status editor, support tone rewriter, checklist scorer).
- Audience: who reads the output and how they use it (skimming directors, on-call support, new analysts).
- Steps: what to do when X arrives (reorganize notes, score sections, ask one clarifying question).
- Format: section order, length, tone, labels for unknowns.
- Refuse: firm limits on what the GPT must decline (passwords, legal advice, confidential systems outside the job, invented metrics).
- Example: one short good behavior sample for the failure mode you fear most.
OpenAI’s guide for creating GPTs recommends similar habits. Write out the steps (“when X happens, do Y”), use clear headings and lists, and prefer concrete “do X” advice over vague warnings. When the GPT has to sort things into categories, add short examples of acceptable and unacceptable answers. Its troubleshooting page adds three more habits: shorten the instructions when the GPT ignores you, remove rules that conflict, and test small changes in the Preview window.
Sample instructions (copy, then adapt)
Below is a teaching outline for a Monday status brief GPT. It is not a magic spell, so strip out anything that does not match your process. Never paste secrets into instructions.
You are a careful weekly status editor for a product team.
Audience:
- Busy directors who skim on Monday morning.
- They need shipped, slipped, risks, and asks.
- They punish invented numbers harder than short unknowns.
When the user pastes weekly notes, follow these steps:
1) Extract only facts present in the notes or in approved knowledge files.
2) Map facts into the output sections below.
3) Mark missing metrics as UNKNOWN.
4) Ask at most one clarifying question if a critical number or owner is missing.
5) List assumptions in the final section.
Output format (use these headings in order):
1) Headline (one line, no hype)
2) What shipped
3) What slipped
4) Risks
5) Asks
6) Assumptions and unknowns
Style:
- Short sentences.
- No filler leadership prose.
- Prefer bullets inside sections when lists help scanning.
- Aim for one page equivalent.
Hard refusals:
- Never invent metrics, dates, customer names, or root causes.
- Never echo passwords, API keys, tokens, or raw personal data. Refuse and say why.
- Do not give legal advice or HR discipline language.
- If notes are pure venting with no facts, say so and request facts. Do not invent a brave narrative.
Knowledge use:
- If a glossary file is attached, use its metric definitions.
- Prefer the glossary definition over casual synonyms in the notes.
- If notes conflict with the glossary, flag the conflict instead of quietly picking one.
Example (good behavior):
User notes: "Revenue was up. Auth project slipped. Need design help."
Your response should:
- Put revenue under Assumptions and unknowns as UNKNOWN (no figure, no grain).
- Put auth under What slipped with no invented reason.
- Put design help under Asks.
- Ask one question: "What is the revenue figure, period, and grain?"
Do not write "revenue grew about 12%."That outline is long for a blog sample and still short for a real team process. If your real instructions run three times longer, split them up. Keep behavior in the instructions, move stable definitions into a knowledge file, and delete repeated wordings of the same rule.
Weak instructions versus structured ones (same job)
| Weak instructions | What goes wrong | Structured fix |
|---|---|---|
| “Be a helpful product genius. Write great status updates.” | The tone drifts and it invents confidence | Role + audience + refuse invented metrics |
| “Never be wrong. Always be complete.” | The rules cannot be met, so the model invents completeness | UNKNOWN labels + one clarifying question |
| Forty “don’t” bullets, no format | The rules conflict and the ones in the middle get ignored | Section order first, few hard rules, one example |
| “Use our vibe” | Nobody has defined the vibe | Short style lines: short sentences, no filler |
| No refusal section | Secrets and advice outside the job slip in | A written refuse list for passwords, legal advice, and HR matters |
Knowledge files without rot
Knowledge lets the GPT read uploaded files as reference while it answers. OpenAI’s guidance says it works best for documentation, guides, handbooks, and similar material. File limits exist, and the current numbers are on the vendor’s help page, so check them the day you build. Files with complicated layouts can be harder for the GPT to use than plain, text-heavy ones. If you want citations or direct quotes from the files, say so in the instructions and describe the format you want.
What belongs in knowledge
- Metric glossary that changes quarterly, not hourly
- Brand or support tone page leadership already approved
- Template outline for the deliverable
- Public product documents, or internal documents you are allowed to share with everyone who can use this GPT
- Dated handbook excerpts that define terms the model keeps mangling
What does not belong
- Live forecast workbooks and customer export dumps
- Credentials, tokens (secret strings that let software log in as you), private keys, unreleased financial packages
- Raw HR notes, health data, or anything your policy forbids in consumer AI tools
- Behavior rules that belong in the instructions (“never invent metrics” should not be buried in a PDF)
- “Everything we know” archives that nobody will refresh
Keep version dates on your files
Stale knowledge is worse than no knowledge, because the GPT sounds confident while describing last quarter’s world. These habits help.
- Put a date in the file name:
metric-glossary-2026-07.txt. - Keep a one-line changelog at the top of the file.
- Replace the file when definitions change, and do not leave two conflicting glossaries uploaded.
- Mention the file name in the instructions so the GPT knows what “approved glossary” means.
- Schedule a quarterly review the way you review a dashboard (a page of charts that updates from your data), because a file nobody reviews is a file nobody should trust.
- On Business, Enterprise, or Edu plans, follow your workspace rules for what may leave approved systems.
The first post’s rule of using only public or already-approved internal content exists for a reason: the wider you share a GPT, the bigger the risk. A private GPT with a sensitive file is already a judgment call, and a widely shared GPT with the same file is an incident waiting to happen.
Mini knowledge file example
A short glossary beats a novel. Here is an example of a file you might upload as plain text.
metric-glossary-2026-07.txt
Owner: Finance analytics lead
Updated: 2026-07-01
Purpose: definitions for Monday status GPT only
active_user:
grain: one user account with at least one successful login in the period
do_not_use_as: install count, seat count, or marketing MQLs
weekly_revenue:
grain: recognized revenue for the calendar week in USD
do_not_use_as: pipeline, bookings, or unpaid invoices
auth_project:
meaning: the Q3 login redesign tracked in the product roadmap
not: third-party SSO vendors or password reset ticketsIn the instructions, tell the GPT to prefer these definitions and to flag any conflict. In Preview, paste notes that misuse “active users” and confirm that the GPT either corrects them or asks. If it ignores the file, make the instructions and the file clearer before you add more files.
Actions: outside power with higher risk
Actions let a GPT connect to outside software through an API that you define. That connection can fetch data or start a task somewhere outside ChatGPT. You set it up in the GPT editor under Actions, where you describe the connection and how it signs in. OpenAI documents limits on actions, and some plans let workspace admins restrict which websites a GPT may call. The help pages also note that when a GPT uses outside APIs or apps, parts of what the user typed may go to third parties, often after the user confirms. OpenAI does not audit how those third parties store data, so deciding whom to trust is your job.
Why delay actions
- Sign-in and secrets: the credentials that let a GPT log in to another system are a bigger risk than a tone rule.
- Third-party data paths: what users type and what the GPT sends may leave ChatGPT.
- Failures look smart: when the outside system returns an error, the GPT can turn it into a fluent wrong answer unless the instructions force it to report the error honestly.
- Workspace policy: Enterprise and Edu admins may restrict which sites a GPT can call, or who may create GPTs.
- Cost of debugging: you now have to debug the instructions, the files, the connection setup, the sign-in, and the outside system all at once.
- Apps versus actions: product rules can limit using both, so read the current help page before you design a mix.
Waiting is not fear. It is putting things in the right order. A GPT that cannot follow a section order will not become trustworthy because it can call an outside system. First prove the text recipe on three real inputs and keep sharing narrow. Then, if the job truly needs live data or a controlled change in another system, design the action with security, a log of what it did, and a person who approves it. For many teams the honest answer is to build the connection in real software or an approved automation tool, and to keep the GPT as a drafting recipe.
When actions might earn their keep later
| Situation | Maybe actions later | Probably not a GPT action |
|---|---|---|
| Read live ticket counts from a small approved status service | If policy allows and it can only read | Silently changing data in live systems |
| Fetch public weather or public docs | If built-in web search is not enough and policy allows | Pulling from private sites with borrowed logins |
| Trigger an approved internal workflow with confirmation | With a sign-in method, a list of allowed sites, and a real audit trail | “Just post to customer Slack as the bot” |
| Replace your CRM | No | Use real software and the vendor’s developer tools |
The first post’s rule still stands for most readers: build your first GPT without actions. The rule for this post is to learn what actions are, so you can say no with reasons or yes with a plan.
Built-in features and apps
Besides knowledge files and actions, the editor can switch on built-in features such as web search, image generation, canvas, and code tools for data analysis, depending on your account and region. Apps connect the GPT to outside tools that users have linked. Turn on only what the job needs. A status brief GPT rarely needs image generation, while a chart explainer might want code tools. A research coach might want web search, with instructions that force it to be honest about its sources. Every extra feature is another way for the GPT to drift away from the job.
Worked example: fix the soft-number failure
Go back to the Monday status GPT from the first post. In Preview, it failed when the notes said “revenue was up” with no figure, and the model wrote “solid growth.”
Fixes that make it worse
- Uploading last year’s finance workbook as a knowledge file “so it can estimate.”
- Adding an action that reaches into the finance data warehouse (the central database your company reports from) on day two.
- Adding twenty new “never be vague” bullets that conflict with “be complete.”
The right order of fixes
- Add a hard rule: missing metrics become UNKNOWN.
- Add the example block from the outline above.
- Optional: upload a short dated glossary that defines
weekly_revenue, meaning exactly what one row of that number covers. - Re-run the same Preview input. Confirm UNKNOWN and one question appear.
- Only much later, if leadership demands live warehouse numbers inside ChatGPT, design an approved read-only path. That is often real software or tightly controlled actions, and not a messy export dropped into the knowledge files.
That order keeps the risk in proportion to what you have proven. It also matches OpenAI’s troubleshooting advice, which is to tighten the instructions and examples before piling on tools.
Privacy and trust notes that change behavior
OpenAI’s overview of GPTs includes privacy points that builders often forget.
- Whether conversations train models depends on plan and data controls. Business, Enterprise, and Edu plans default differently from the consumer plans. Check the data controls help page for your own account.
- GPT builders cannot view individual end-user conversations with their GPTs.
- External APIs and apps can send relevant input to third parties. Only use connections you trust.
- GPTs do not use saved memory, your personal custom instructions, or previous chats the way regular ChatGPT might. Each thread starts from the GPT’s own setup plus what is in that thread.
These facts are part of how the product works, not footnotes. They argue for clear instructions, careful knowledge files, and delayed actions. They also argue against treating a shared GPT as a private vault or a hidden customer database.
Troubleshooting loop: use Preview as a lab
When the GPT misbehaves, change one thing, then re-test the same input.
| Symptom | Likely layer | First move |
|---|---|---|
| Ignores section order | Instructions | Put the format first and remove long conflicting tone advice |
| Invents numbers | Instructions | A hard UNKNOWN rule plus an example of refusing to invent |
| Wrong definition of a metric | Knowledge or instructions | A short glossary file and a “prefer the glossary” line |
| Cites outdated policy | Knowledge | Replace dated file; delete old version |
| Fails only when “looking up” live data | Actions, apps, or web search | Turn the connection off, fix the honesty rules, then redesign |
| Different every run on same input | Instructions too vague | Tighten the steps and format, and add one example |
Do not “fix” a failure by telling teammates to phrase their questions better forever. If three people need the same workaround, the GPT is unfinished.
Common mistakes
Rules buried only in a PDF
If “never invent metrics” lives only on page 40 of a handbook, the model may miss it. Put the rule in the instructions, and use knowledge files for definitions and reference.
Knowledge files as a side door for secrets
Uploading sensitive exports because “the GPT needs context” is how one-time policy exceptions turn into habits. Use samples with the sensitive parts removed, or use approved systems.
Actions as a show for leadership
Connecting tools before the recipe works creates demos that fail under real conditions. Wait until the text-only version is reliable.
Infinite instruction growth
Not every unusual case needs its own paragraph. Group the rules, prefer the “when X, do Y” pattern, and delete duplicates. The editor keeps a version history, so you can try a shorter draft without fear.
Mixing up a GPT with Work or Codex
Better instructions will not turn a GPT into Work, which carries out multi-step office tasks, or into Codex, which edits a code project and shows you the changes. If your job is one of those jobs, switch to that tool. The layers inside a GPT only sharpen the recipe.
How to practice
- Open the GPT from the first post, or draft instructions in a note if you cannot create one yet.
- Rewrite the instructions into the six-part outline and cut one third of the fluff.
- Add one example aimed at your worst failure.
- If you use knowledge, replace vague dumps with one dated, purpose-built file. Delete the rest.
- Confirm that actions are still off. Write one sentence on why you might need them later, or write “never for this job.”
- Re-run the same three Preview inputs. Record what improved.
Series notes
This is Part 2 of the Custom GPTs tutorial. The next post, Share with a team without creating chaos, covers who owns a GPT, how wide to share it, how to review it, and when to retire it, so your good recipe does not turn into five conflicting copies. The one after that, When a Custom GPT is the wrong solution, draws a firm line for the cases where you need Work, Codex, plain chat, or real software.
Quick recap
- Instructions are the backbone of the GPT: role, audience, steps, format, what to refuse, and an example.
- Knowledge files are optional reference material: public or approved internal content only, dated, short, and refreshed.
- Actions connect to outside software: they carry higher risk and a higher setup cost, so wait until the recipe is reliable.
- Put rules in the instructions and definitions in the files, and do not put secrets in either.
- Debug with Preview, one change at a time, because extra tools do not fix vague instructions.
Sources
Research and further reading used for this article:
- OpenAI Help: Creating and editing GPTs (instructions craft, knowledge best practices, capabilities, actions, Preview, version history)
- OpenAI Help: GPTs in ChatGPT (what GPTs include, apps vs actions note, privacy, FAQ on memory and API embeds)
- OpenAI Help: Configuring actions in GPTs (external API setup path)
- OpenAI Help: Troubleshooting GPTs (instructions vs knowledge, shorten and example guidance)
- OpenAI Help: Managing GPT access in Enterprise and Edu workspaces (workspace controls and action domain restrictions)
- ChatGPT: Explore GPTs
- OpenAI: ChatGPT product overview
- Analytics Made Simple: Learn ChatGPT from scratch
- Analytics Made Simple: ChatGPT product map
- Analytics Made Simple: ChatGPT everyday tutorial
- Analytics Made Simple: ChatGPT Work tutorial
- Analytics Made Simple: ChatGPT Codex tutorial
Keep going
Same lessons in your feed
Short diagrams, hooks, and weekly tutorials on Substack, Instagram, X, and Facebook.
