Building a custom GPT: instructions, knowledge, and capabilities

• Name and Description
• Instructions (the system prompt)
• Conversation starters (suggested first messages)
• Knowledge (uploaded files)
• Capabilities (Web Search, Canvas, Image Generation, Code Interpreter & Data Analysis)
• Actions (custom APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → calls)

Let's go through the ones that matter.

Instructions: write them like an operating procedure

Instructions are the GPT's standing orders. They are prepended to every conversation, so treat them as a contract, not a vibe. For Onboard Buddy:

Three habits that separate good instructions from bad:

Anchor to knowledge explicitly. The line "Use ONLY the uploaded knowledge files" plus an escape hatch ("If the answer is not in the files, say so") is what stops your GPT from confidently inventing a parental-leave policy.

Specify refusal behavior. Tell it what NOT to answer. For an HR-adjacent bot, "never guess about salary or legal topics" is a safety feature, not a nicety.

Define format where it matters. "Output a numbered checklist" produces consistent, scannable setup guides instead of prose blobs.

Keep instructions focused. There is a generous character limit, but a tight 300-word brief outperforms a rambling 2,000-word one because the model weights clear, non-contradictory rules better.

Conversation starters earn their keep

These are the clickable prompts on the GPT's home screen. Make them match real first-week questions:

• "How do I set up my laptop and VPN?"
• "What's our health insurance and when does it start?"
• "Who owns the deployment pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.View full definition →?"
• "Walk me through expense reports."

Good starters quietly document what the GPT is for and reduce "what can you do?" friction.

Knowledge: files, not fine-tuningfine-tuningFine-tuning adapts a pre-trained model to a specific task or domain by continuing training on a smaller, targeted dataset, improving accuracy and style for that use case.View full definition →

The Knowledge section is where you upload reference documents. Behind the scenes this gives the GPT retrieval over your files, the same RAG pattern you already know, with no setup on your part. Upload the actual source material:

• benefits-2026.pdf
• it-onboarding.md
• team-directory.md
• pto-and-leave-policy.pdf
• expense-policy.pdf

A few realities to design around:

Structure beats volume. A clean Markdown file with clear headings retrieves better than a 90-page scanned PDF. If a document is messy, convert it to Markdown or split it by topic before uploading.

One concept per file is easier to maintain. When the 2026 benefits change, you swap one file instead of re-editing a monolith.

Files are visible if Code Interpreter is on. This matters for privacy. If you enable Code Interpreter & Data Analysis, a savvy user can sometimes get the GPT to list or dump uploaded files. Do not put secrets, raw PII, or unreleased compensation bands in Knowledge. Treat anything you upload as readable by anyone who can use the GPT.

Knowledge is static. It is a snapshot from upload time. For data that changes daily (open headcount, ticket status), you want an Action or Connector instead, covered below.

Capabilities: toggle only what the job needs

Each capability is a checkbox. More tools means more surface area for the GPT to wander, so enable deliberately.

Web Search

Lets the GPT pull from the live internet. For Onboard Buddy, turn this off. You want answers grounded in your files, not a public web guess about "standard PTO policy." Web Search is right for a competitive-research GPT, wrong for a policy authority that must be internal-only.

Canvas

Opens a side-by-side editing workspace for longer documents and code. Useful if your GPT helps draft things (a 30-60-90 day plan, a welcome email). For a pure Q&A helper, optional. Enable it if you expect new hires to co-write onboarding docs with the assistant.

Image Generation

Lets the GPT create images. For an onboarding helper, off. There is no reason a benefits bot needs to generate pictures, and turning it off keeps the GPT focused.

Code interpreter & data analysis

Also called Advanced Data Analysis: a sandboxed Python environment that can run code, parse spreadsheets, and make charts. For Onboard Buddy, off by default, both because it is unnecessary and because of the file-exposure issue above. You would enable it for, say, an analytics GPT that crunches an uploaded CSV of survey responses.

For our onboarding assistant, the correct configuration is: all capabilities off, knowledge files on, instructions tight. A boring config is often the right one.

Actions and Connectors: when static knowledge isn't enough

Knowledge files answer "what is the policy." They cannot answer "is my laptop ticket approved yet." For live, per-user data you need GPT Actions: the GPT calls an external APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → mid-conversation, using your OpenAPI schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition →, and folds the response into its answer. This is the same idea as function calling in the APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →, exposed inside ChatGPT.

You define an Action by pasting an OpenAPI spec and setting auth (APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → key or OAuth). Suppose your IT system exposes a "ticket status" endpoint. A minimal schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition → looks like this:

openapi: 3.1.0
info:
  title: Acme IT Tickets
  version: "1.0"
servers:
  - url: https://it.acme.internal/api
paths:
  /tickets/{ticketId}:
    get:
      operationId: getTicketStatus
      summary: Get the status of an onboarding IT ticket
      parameters:
        - name: ticketId
          in: path
          required: true
          schema:
            type: string
      responses:
        "200":
          description: Ticket found
          content:
            application/json:
              schema:
                type: object
                properties:
                  status: { type: string }
                  assignee: { type: string }
                  eta: { type: string }

With this in place, a new hire can ask "what's the status of ticket IT-4821?" and the GPT calls getTicketStatus, then answers in plain language. The operationId and summary are not decoration: the model reads them to decide when and how to call the endpoint, so write them descriptively.

The official walkthrough is worth bookmarking: Actions in GPTs.

Connectors are the lower-effort cousin. In Team and Enterprise, OpenAI offers managed Connectors to sources like Google Drive, SharePoint, and others, so the GPT can search company documents without you writing any schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition →. If your onboarding docs already live in Google Drive, a Connector may beat re-uploading files as Knowledge, because it stays in sync. Use Knowledge for stable reference PDFs, Connectors for living document stores, and Actions for transactional, per-user lookups.

Test, then publish deliberately

Before sharing, use the Preview pane on the right of the builder. Run adversarial tests, not just happy paths:

• Ask something not in the files: does it admit the gap and point to Slack, or fabricate?
• Ask an off-scope question ("what's our Q3 revenue?"): does it refuse?
• Ask an HR question: does it append the "Confirm with People Ops" line?

If behavior drifts, fix the instructions, not the knowledge. Most misbehavior is a missing rule.

When it passes, hit Create / Update and choose the audience. For Onboard Buddy, select your workspace-only option. Avoid "Anyone with a link" for anything containing internal docs, and avoid the public GPT Store entirely for internal tools.

A note on the bigger picture

A Custom GPT is the no-code end of OpenAI's spectrum. When you outgrow it (you need version control, automated evals, multi-step orchestration, or to embed the assistant in your own app), the same logic moves to the APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →: instructions become a system message, Actions become function calling or tools, and Knowledge becomes your own retrieval pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.View full definition → or a hosted file search tool. The Custom GPT is often the prototype you validate before you rebuild it with the Responses API and the Agents SDK.

Key Takeaways

• Write instructions like an SOP: define scope, an explicit "use only the knowledge files" anchor with an escape hatch, refusal rules, and output format. Most bad behavior is a missing rule, so fix instructions before touching files.
• Treat Knowledge as public to your audience. Never upload secrets or raw PII, especially if Code Interpreter is enabled, since uploaded files can be exposed.
• Toggle capabilities deliberately. For an internal Q&A GPT, the right config is usually everything off plus tight instructions. Each tool you add is more room to wander.
• Match the data source to the data: Knowledge for stable PDFs, Connectors for living document stores that must stay in sync, Actions for live per-user lookups via an OpenAPI schemaschemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition →.
• Publish to your workspace, not the public Store, for anything internal, and treat the Custom GPT as a fast prototype you can later rebuild on the Responses API when you need scale and control.