A custom GPT is shaped by more than its instructions. Three additional layers determine what it can actually do: knowledge files give it reference material, capabilities give it tools, and connected actions or apps let it interact with external services.
Each of these layers changes the GPT's behavior in a different way, and each one needs to be deliberately chosen and clearly referenced in the instructions.
Show the GPT as layers: instructions on top of knowledge, capabilities, and connected actions. Instructions sit at the top because they coordinate everything below them.
- What knowledge files are good for and what makes a good knowledge file
- How capabilities like web browsing and code interpreter change the GPT's behavior
- What connected actions and apps add to a GPT's workflow
- How to keep a GPT focused instead of overloaded
- How to write instructions that reference every attached resource
Many custom GPTs become messy because users add every available option. More capability often means more confusion, not more value.
A GPT with three knowledge files, web browsing, code interpreter, and two connected actions may look impressive in the builder. But if the instructions do not coordinate all those resources, the GPT's behavior becomes unpredictable. It may consult the wrong file, search the web when it should use an attached document, or call a connected action at the wrong time.
The strongest setups usually keep only the files, capabilities, and actions that genuinely improve the repeated job the GPT is meant to do. Restraint is a design choice, not a limitation.
The core idea
Instructions define behavior. Knowledge changes the context pool. Capabilities and actions change what the GPT can do. These are three distinct levers, and each one should be pulled deliberately.
That means each layer should be justified by the actual workflow. If the GPT does not need a knowledge file, do not attach one. If it does not need a connected action or app, leave it out. Focus increases reliability. The best custom GPTs tend to use the minimum configuration needed to do the job well.
Use extra surface area only when it creates clear leverage for the job.
Knowledge files work best when they contain structured reference material -- style guides, glossaries, standard operating procedures, product specs. These give the GPT a reliable source it can consult repeatedly. Raw data dumps, on the other hand, often produce inconsistent results because the model has no clear framework for interpreting them. A well-organized document with clear headings and consistent formatting is far easier for the model to navigate than a folder of miscellaneous notes.
Capabilities like web browsing and code interpreter change the GPT's action space. Web browsing lets the GPT pull live information from the internet. Code interpreter lets it run calculations, generate charts, or parse uploaded files. Image generation lets it create visuals on demand. Each should be enabled only when the workflow genuinely requires it. A GPT meant to answer questions from an attached document does not need web browsing -- enabling it introduces a competing information source that can dilute accuracy.
Every added layer is a potential source of confusion if the instructions do not reference it clearly. A knowledge file that sits unmentioned in the configuration may never be consulted. A capability that is enabled but never directed creates ambiguity about when the GPT should use it. The instructions must tie everything together, pointing the model to the right resource at the right moment.
Think of it as a contract between the builder and the GPT: the instructions say what to do, the knowledge files say what to reference, and the capabilities say what tools are available. If any part of that contract is vague, the GPT fills in the gaps with its own judgment -- which may not match yours.
The shift from Actions to Apps and MCP
OpenAI is transitioning from legacy GPT Actions (which used OpenAPI specifications) to Apps built on MCP (Model Context Protocol). When you enable Apps in a GPT edit, it replaces legacy actions -- the two cannot coexist in the same GPT.
MCP is a cross-platform standard that also works in tools like Claude and VS Code, making skills and integrations portable across environments rather than locked to one platform. If you are building new integrations for a custom GPT, Apps with MCP is the path forward. Existing GPTs with legacy actions will continue to work, but new development should use the Apps approach.
The practical implication: if your GPT currently uses a legacy action, it will keep working. But if you need to add a new external integration, you will use the Apps interface instead.
The same design principle applies regardless of which system you use: only connect what the workflow requires, and reference the connection in your instructions so the GPT knows when to use it. A connected app that is never referenced in the instructions is no different from a capability that is enabled but undirected -- it adds surface area without adding clarity.
How it works
- Start with the core job. Ask what information or actions are truly required to complete it well.
- Add knowledge only when recurring reference material matters. The question to ask: "Will the GPT need to look something up that it could not know on its own?"
- Enable capabilities only when the GPT needs them to complete the job. If the answer is "sometimes," define exactly when in the instructions.
- Connect actions or apps only when the GPT must interact with an external service -- sending data, retrieving live records, or triggering a workflow.
- For each resource you add, write at least one instruction sentence that tells the GPT when and how to use it. This is the step most people skip, and it is the one that matters most.
What skilled users do differently
Skilled users write instructions that explicitly reference their knowledge files. Instead of hoping the GPT will find the right document, they include directives like "When answering brand questions, consult the attached style guide" or "Use the pricing sheet for all cost-related queries." This removes guesswork and makes the GPT's behavior predictable.
They also test whether the GPT actually uses the knowledge file. A simple check: ask a question the file answers and see if the response draws from the document. If the GPT invents an answer instead of citing the attached material, the instructions need tightening -- usually by adding a sentence like "Always check the attached file before answering."
Skilled users disable capabilities that create noise. If a GPT is meant to work only from attached documents, web browsing is turned off so the model cannot pull in outside information that contradicts the source material. They treat each toggle as a decision, not a default.
They also version their knowledge files deliberately. When a product spec changes or a policy is updated, the knowledge file is replaced and the GPT is retested against known questions. Stale reference material is worse than no reference material because it produces confident but outdated answers. The GPT has no way to know the document is old -- it will treat whatever is attached as current truth.
Finally, they periodically audit whether connected actions still function correctly. APIs change, endpoints deprecate, and authentication tokens expire. A connected action that silently fails degrades the GPT without warning. A quick end-to-end test once a month catches most of these issues before users notice.
Two worked examples
Example 1 -- HR policy GPT.
The builder attaches the full employee handbook as a knowledge file. Web browsing and code interpreter are both disabled. The instructions read:
"You are an HR policy assistant. Answer employee questions using only the attached employee handbook. Quote the relevant section when possible. If the answer is not in the handbook, say so clearly and suggest the employee contact HR directly."
This creates a closed system. The GPT consults one authoritative source, never fabricates policy, and tells the user when it cannot help. No unnecessary capabilities compete for attention.
Notice the instruction "If the answer is not in the handbook, say so clearly." This is the fallback behavior -- it tells the GPT what to do when the knowledge file does not cover the question. Without this, the GPT would likely improvise an answer, which defeats the purpose of attaching a handbook in the first place.
Example 2 -- Sales team GPT.
The builder attaches two knowledge files: product-specs.pdf and pricing-guide.pdf. Web browsing is enabled for competitor research. Code interpreter is disabled. The instructions reference both files by name:
"For product details, consult product-specs.pdf. For pricing questions, consult pricing-guide.pdf. Use web browsing only when the user asks about competitor offerings or current market context. Never use web results to override information in the attached documents."
This gives the GPT clear rules about when to use attached documents versus live search. The final sentence prevents web results from contradicting the company's own materials.
Both examples share a common pattern: the instructions name the specific resources, define when to use each one, and specify what to do at the boundaries. That pattern scales to more complex setups.
Prompt block
What should I enable for this GPT?
This prompt is too open-ended. It gives the model no context about the GPT's purpose, so the answer will be generic.
Better prompt block
Help me design the supporting setup for this GPT.
Job:
[describe the GPT]
For this use case, tell me:
- what belongs in instructions
- whether I need attached knowledge
- which capabilities are genuinely necessary
- whether connected actions or apps would improve the workflow
- what I should leave out to keep the GPT focused
Why this works
The better prompt makes each layer earn its place. When instructions explicitly reference attached knowledge files and define the conditions for using each capability, they create a closed loop. The GPT knows what to consult, when to consult it, and what to do when the resource does not contain the answer.
This matters because a GPT without clear resource directives will improvise. It may ignore a knowledge file entirely, search the web when it should use attached documents, or hallucinate an answer instead of admitting a gap.
Explicit references eliminate that ambiguity. The result is a GPT that behaves consistently across different users and different questions -- which is the whole point of building a custom GPT in the first place.
A maximal setup where every option is enabled but none is directed almost always performs worse than a focused setup with clear routing.
- Adding knowledge files that do not materially improve the task. Extra files increase context without increasing quality.
- Enabling capabilities just because they are available. Each enabled capability is a door the GPT might walk through at the wrong time.
- Connecting actions or apps without a clear workflow reason. If the GPT never needs to call an external service, the connection adds complexity for no benefit.
- Attaching knowledge files without referencing them in the instructions, so the GPT may ignore them entirely. The model does not automatically prioritize attached files unless told to.
- Enabling web browsing on a GPT that should only work from attached documents. This introduces a competing information source that can override your curated material.
- Pick a GPT idea -- something you would actually use repeatedly.
- List every knowledge file and capability you could add. Be generous. Include everything that seems even slightly relevant.
- Cut the list to only what the core job requires. For each item you remove, note why it does not earn its place.
- For each remaining resource, write one instruction sentence explaining when the GPT should use it. For example: "Consult pricing-guide.pdf when the user asks about cost."
- Reflect on what you removed. Did the GPT's job become clearer once you stripped away the extras? If so, that is the signal that restraint is working.
Compare your final resource list with the original. Most people find they cut at least half of what they initially considered. The items that survive are the ones that genuinely serve the repeated job.
If you completed step 4, you now have a set of instruction sentences that can go directly into a GPT's configuration. That is the bridge between planning and building.
Custom GPT quality often improves when you remove unnecessary layers instead of adding more. Every knowledge file, capability, and connected action should be referenced in the instructions and justified by the core job. If you cannot write a sentence explaining when the GPT should use a resource, that resource probably does not belong.