Instructions, knowledge files, and actions (light)

You built a Custom GPT named something honest, like “Monday status brief.” Preview mostly works. Then the model softens a missing number into “solid growth,” ignores half your section order, and cites a glossary file you swear you never uploaded. A teammate asks if you can “just connect it to Jira.” Someone else pastes last quarter’s customer export into Knowledge “for accuracy.” The recipe is no longer the hard part. The layers are.

This is Part 2 of the Custom GPTs tutorial. Part 1 covered the first build: one repeating job, paid create rights in most cases, no actions, non-secret knowledge, Preview on real inputs. Here we go one layer deeper: instructions that stick, knowledge files that do not rot, and actions only as a light, delayed option when the text recipe is already boringly reliable. If ChatGPT basics still feel thin, use Learn ChatGPT from scratch. For Chat vs Work vs Codex and when a GPT is even the right door, keep the ChatGPT product map open. Everyday writing habits live in the ChatGPT everyday tutorial. Office agent deliverables live in the ChatGPT Work tutorial. Coding agents live in the ChatGPT Codex tutorial.

UI labels and limits still move. Treat this as a July 2026 field guide. Re-check Creating and editing GPTs, GPTs in ChatGPT, Configuring actions in GPTs, Troubleshooting GPTs, and openai.com/chatgpt before you freeze team standards.

What you’ll learn

How instructions, knowledge, and actions differ as layers of a Custom GPT
An instruction skeleton: role, audience, steps, format, refuse, example
Why knowledge is reference material, not a rules dump or a secret vault
How to version files and keep only public or already-allowed internal content
What actions are (external API calls), why risk and setup cost are higher, and why delay is a feature
A worked rewrite: weak instructions vs a structured skeleton on the same Monday brief
Troubleshooting habits from OpenAI’s own guidance, without cargo-cult prompting
What Parts 3 and 4 will cover: team sharing without chaos, and when a GPT is the wrong solution

Three layers, three jobs

OpenAI’s product language splits a GPT into pieces. For day-to-day builders, three layers matter most after name and description:

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 policy, living data tables
Knowledge	Reference material to ground answers	Stable glossaries, style guides, templates, dated handbooks	Daily forecasts, raw tickets, credentials, “whole drive” dumps
Actions	Call external APIs you define	Clear, approved integrations with auth and failure handling	Day-one Jira “magic,” unreviewed third parties, silent writes

Help is explicit: knowledge works best for reference material; put rules, tone, and workflow behavior in instructions, not only in uploaded files. Actions are a separate configuration path for external APIs. A GPT may also use built-in capabilities (web search, image generation, canvas, code tools, and related features as offered) and, in some setups, apps. OpenAI notes that a GPT can use apps or actions, but not both at the same time. That detail matters later. Today’s priority is still the spine: instructions first.

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. Delay the third until the first two are boring.

Instructions that stick

Instructions apply to every conversation with that GPT. They are not a wish list. They are operating procedure. When they fail, people blame “the model” and pile on more adjectives. Better builders shorten, structure, and test.

The six-part skeleton

Use this skeleton for almost every work GPT. Expand 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: hard outs (credentials, legal advice, out-of-scope confidential systems, invented metrics).
Example: one short good behavior sample for the failure mode you fear most.

OpenAI’s create guide pushes similar craft: explicit multi-step structure (“when X happens, do Y”), clear headings and lists, prefer concrete “do X” guidance, and include brief acceptable/unacceptable examples when classifications matter. Troubleshooting adds: shorten when the GPT ignores you, remove conflicts, test small changes in Preview.

Sample instructions (copy, then adapt)

Below is a teaching skeleton for a Monday status brief GPT. It is not a magic spell. Strip 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 skeleton is long for a blog sample and still short for a real team process. If your real instructions are three times longer, split: keep behavior in instructions, move stable definitions to knowledge, delete repeated synonyms of the same rule.

Weak vs structured (same job)

Weak instructions	What goes wrong	Structured fix
“Be a helpful product genius. Write great status updates.”	Tone drifts; invents confidence	Role + audience + refuse invented metrics
“Never be wrong. Always be complete.”	Impossible rules; model invents completeness	UNKNOWN labels + one clarifying question
Forty “don’t” bullets, no format	Conflicts; ignored middle rules	Section order first, few hard rules, one example
“Use our vibe”	Undefined vibe	Short style lines: short sentences, no filler
No refusal section	Secrets and out-of-scope advice slip in	Explicit refuse list for credentials and legal/HR

Knowledge files without rot

Knowledge lets the GPT use uploaded files as reference while answering. Official create guidance: best for documentation, guides, handbooks, and similar material. File limits exist (help has cited up to 20 files and large per-file caps; re-check current numbers). Complex layouts can be harder to use than clear text-forward files. If you want citations or quotes from files, say so in instructions and specify the format.

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 docs or internal docs you are allowed to share at this GPT’s share scope
Dated handbook excerpts that define terms the model keeps mangling

What does not belong

Live forecast workbooks and customer export dumps
Credentials, tokens, private keys, unreleased financial packages
Raw HR notes, health data, or anything your policy forbids in consumer AI tools
Behavior rules that should live in instructions (“never invent metrics” is not a PDF strategy)
“Everything we know” archives that nobody will refresh

Version them like software

Stale knowledge is worse than no knowledge because the GPT sounds confident in last quarter’s world. Practical habits:

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; do not leave two conflicting glossaries uploaded.
Mention the expected knowledge file name in instructions so the GPT knows what “approved glossary” means.
Schedule a quarterly review the way you review a dashboard. No review, no trust.
On Business, Enterprise, or Edu, follow workspace rules for what may leave the approved systems.

Public or already-allowed internal only is the Part 1 rule for a reason. Share scope multiplies risk. A private GPT with a sensitive file is already a judgment call. A broadly shared GPT with the same file is an incident waiting for a calendar invite.

Mini knowledge file example

A short glossary beats a novel. Example content you might upload as text:

metric-glossary-2026-07.txt

Owner: Maya Chen
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 tickets

In instructions, tell the GPT to prefer these definitions and flag conflicts. In Preview, paste notes that misuse “active users” and confirm it corrects or asks. If it ignores the file, fix instructions and file clarity before you add more files.

Actions (light): external power, higher risk

Actions let a GPT connect to external APIs you define: retrieve data or trigger workflows outside ChatGPT. Setup lives in the GPT editor under Actions (create new action, schema, authentication, and related configuration). OpenAI documents model constraints for actions and workspace domain restrictions on some plans. Help also notes that when GPTs use external APIs or apps, relevant parts of user input may go to third parties, often with user confirmation depending on setup. OpenAI does not audit how those third parties store data. Trust is your job.

Why delay actions

Auth and secrets: API credentials are a different class of risk than a tone rule.
Third-party data paths: prompts and payloads may leave OpenAI’s chat surface.
Failure modes look smart: a 500 from an API can become a fluent wrong answer if instructions do not force honest errors.
Workspace policy: Enterprise and Edu admins may restrict domains or create rights.
Debug cost: you now debug instructions, knowledge, schema, auth, and the remote API together.
Apps vs actions: product rules can limit combining them; read current help before you design a hybrid.

Delay is not fear theater. Delay is sequence. A GPT that cannot follow section order will not become trustworthy because it can hit an endpoint. Prove the text recipe on three real inputs. Keep share narrow. Then, if the job truly needs live system data or a controlled write, design actions with security, logging, and a human approval story. For many teams, the honest answer is: build the integration in real software or approved automation, and keep the GPT as a drafting recipe.

When actions might earn their keep (later)

Situation	Maybe actions later	Probably not a GPT action
Read a small approved status API for live ticket counts	If policy allows and read-only	Silent writes to production systems
Fetch public weather or public docs	If built-in web search is not enough and policy allows	Scraping private sites with stolen cookies
Trigger an approved internal workflow with confirmation	With auth, allowlists, and audit outside folklore	“Just post to customer Slack as the bot”
Replace your CRM	No	Use real software + API platform paths

Part 1’s rule still stands for most readers of this post: first GPT, no actions. Part 2’s rule: learn what actions are so you can say no with reasons, or yes with a plan.

Capabilities and apps (quick orientation)

Besides knowledge and actions, the editor can enable built-in capabilities such as web search, image generation, canvas, and code interpreter / data analysis, depending on account and region. Apps connect to external tools users have linked. Enable only what the job needs. A status brief GPT rarely needs image generation. A chart explainer might want code tools. A research coach might want web search with instructions that force source honesty. Every extra capability is another way to drift off the job.

Worked example: fix the soft-number failure

Recall Maya’s Monday status GPT from Part 1. Preview failed when notes said “revenue was up” with no figure. The model wrote “solid growth.”

Wrong fixes

Upload last year’s finance workbook as knowledge “so it can estimate.”
Add an action to the finance warehouse on day two.
Add twenty new “never be vague” bullets that conflict with “be complete.”

Right fix order

Add a hard rule: missing metrics become UNKNOWN.
Add the example block from the skeleton above.
Optional: upload a short dated glossary that defines weekly_revenue grain.
Re-run the same Preview input. Confirm UNKNOWN and one question appear.
Only much later, if leadership demands live warehouse numbers inside ChatGPT, design a read-only approved path (often real software or tightly controlled actions), not a junk export in Knowledge.

That order keeps risk proportional to proof. It also matches OpenAI troubleshooting: tighten instructions and examples before piling on tools.

Privacy and trust notes that change behavior

Help’s GPT overview includes privacy points builders forget:

Whether conversations train models depends on plan and data controls. Business, Enterprise, and Edu default differently from consumer Free/Go/Plus/Pro style plans. Re-check Data Controls help for your 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, custom instructions, or previous chats the way personal Chat personalization might. Each thread starts from the GPT config plus that thread’s content.

Those facts are product design, not footnotes. They argue for clear instructions, careful knowledge, and delayed actions. They also argue against treating a shared GPT as a private vault or a silent CRM.

Troubleshooting loop (Preview as lab)

When the GPT misbehaves, change one thing, then re-test the same input.

Symptom	Likely layer	First move
Ignores section order	Instructions	Put format first; remove conflicting tone essays
Invents numbers	Instructions	Hard UNKNOWN rule + example of good refusal to invent
Wrong definition of a metric	Knowledge or instructions	Short glossary file + “prefer glossary” line
Cites outdated policy	Knowledge	Replace dated file; delete old version
Fails only when “looking up” live data	Actions / apps / web	Disable the connection; fix honesty rules; then redesign
Different every run on same input	Instructions too vague	Tighten steps and format; add one example

Do not “fix” failure by telling teammates to prompt harder forever. If three people need the same workaround, the GPT is unfinished.

Common mistakes at this layer

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 instructions. Use knowledge for definitions and reference.

Knowledge as a secrets side door

Uploading sensitive exports because “the GPT needs context” is how policy exceptions become habits. Use redacted samples or approved systems.

Actions as status theater

Connecting tools before the recipe works creates demos that fail in production conditions. Delay until the text path is reliable.

Infinite instruction growth

Every edge case does not need a paragraph. Group rules. Prefer “when X, do Y.” Delete duplicates. Version history exists so you can try a shorter draft without fear.

Confusing GPT layers with Work or Codex

Better instructions will not turn a GPT into Work’s multi-step office agent loop or Codex’s repo diff loop. If the job is those jobs, change doors. Layers inside a GPT only refine the recipe door.

Practice this week

Open the GPT from Part 1 (or draft instructions in a note if you cannot create yet).
Rewrite instructions into the six-part skeleton. Cut one third of the fluff.
Add one example aimed at your worst failure mode.
If you use knowledge, replace vague dumps with one dated, purpose-built file. Delete the rest.
Confirm actions are still off. Write a one-sentence reason you would need them later, or write “never for this job.”
Re-run the same three Preview inputs. Record what improved.

What comes next

Part 3, Share with a team without creating chaos, covers ownership, share scopes, review habits, and retirement so your good recipe does not become five conflicting avatars. Part 4, When a Custom GPT is the wrong solution, draws the hard line against GPT theater when you need Work, Codex, plain chat, or real software.

Quick recap

Instructions are the behavior spine: role, audience, steps, format, refuse, example.
Knowledge is optional reference: public or allowed internal only, dated, short, refreshed.
Actions call external APIs: higher risk, higher setup cost, delay until the recipe is reliable.
Put rules in instructions; put definitions in knowledge; do not put secrets in either casually.
Debug with Preview, one change at a time. Tools do not fix a vague spine.

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