A practical guide to building a ChatGPT knowledge base

What a ChatGPT knowledge base actually provides

A knowledge base supplies reference material at the point where a model answers. That might be a product guide, an employee procedure, or a selected set of help-center articles. Connecting a source does not necessarily grant every reader access to it, copy every attachment, or make every future edit immediately available.

Keep three things separate:

• Source material: the facts the assistant can consult.
• Instructions: how it should use those facts and respond to missing information.
• Action permissions: what connected tools may read or change.

For example, a warranty guide can explain which documents a customer needs to submit. It does not authorize the AI to approve a claim. A standing instruction to use the guide also does not prevent a broadly authorized tool from taking other actions. Configure and review each layer.

The same distinction applies to internal knowledge. An employee may need the approved process without being entitled to every private document that informed it. Choose the intended audience before connecting a large collection.

Retrieval helps find evidence; it does not guarantee an answer

Retrieval-augmented generation, or RAG, means finding relevant material and supplying it to the model as context for an answer. OpenAI's file-search guide describes semantic and keyword search over previously uploaded files. The model can then use retrieved passages instead of relying only on its existing knowledge.

That is useful, but it does not force every sentence to come from the source. The wrong passage may be retrieved, a table may lose its structure, or the model may overlook an exception. A citation is a starting point for checking the answer, not a guarantee that the answer is correct.

Fine-tuning serves a different purpose: changing model behavior through training examples. It is not a substitute for maintaining a changing policy library. Nor does updating a document always require retraining an entire model. For a knowledge-base project, first make source selection, retrieval, and update handling work. Compare further model changes against a measured failure rather than assuming one method is always cheaper or better.

Three ways to build the workflow

Custom GPT knowledge

Check eligibility before following an old Plus tutorial. OpenAI's current GPT creation guide says personal accounts cannot create or publish new GPTs. Eligible Business, Enterprise, and Edu workspaces can do so under workspace permissions. Existing GPTs have separate continued-use and editing conditions.

The guide lists up to 20 knowledge files, each up to 512 MB. Put reference information in those files and behavior rules in instructions. Use clear document text and test in Preview. File upload is not a promise that the GPT will keep rereading the original location after a policy changes. Decide who will update and retest the reference material.

An application using the Responses API

Use the current API path. OpenAI's migration guide says the Assistants API was sunset on August 26, 2026. It should not be the starting point for a new implementation.

Responses API file search is hosted: the developer creates a vector store, uploads the intended files, and makes that store available to the tool. OpenAI handles search execution, but the application still needs user authorization, document lifecycle management, cost controls, and evaluation. Hosted retrieval does not remove those responsibilities.

This route is useful when the application needs rules your team wants to implement explicitly. For example, the server can choose a permitted document collection for the signed-in user before requesting an answer. Validate the access logic independently of how convincing the generated text sounds.

An eesel teammate with connected knowledge

eesel brings the knowledge into a teammate's work. The Confluence integration, for example, reads selected pages and can cite them in answers. It is read-only in Confluence; it does not gain wiki-editing actions by connecting.

The source details matter. Confluence page text is indexed, but attachments are not. Edits to indexed pages are picked up automatically, with roughly hourly reconciliation for missed updates. That is an integration-specific update mechanism, not a universal promise that every connected source is instant or maintenance-free.

An owner can work in the dashboard or ask a coding agent to inspect that same teammate through the CLI. This is useful when the person investigating a source problem already works in a terminal: they can review the connection, the saved files, and the answer without creating a second knowledge setup.

Find a missing attachment with eesel CLI

Suppose a support lead's approved warranty procedure is a Confluence page, but the required proof-of-purchase checklist sits in an attached PDF. The teammate describes the general procedure yet cannot list the required documents. The lead asks Codex to investigate why, using eesel CLI.

With Node.js 18.17 or newer, these documented commands return JSON for the same workspace and teammate as the dashboard. Replace the example name with the intended teammate and confirm the workspace first:

npx @eesel/cli whoami
npx @eesel/cli status --agent "Warranty support"
npx @eesel/cli integrations --agent "Warranty support"
npx @eesel/cli integrations download list --agent "Warranty support"
npx @eesel/cli files ls --agent "Warranty support"

Claude Code, Codex, or Cursor can summarize these results for the lead; a script can retain them for a source audit. A connected Confluence entry is not proof that the PDF was indexed. The owner opens the actual page and attachment, confirms the current revision, and checks whether the file is already separately available to the teammate.

If the document is approved for this audience, the owner can either place its content in the indexed page or authorize a separate file upload. For an upload, preview the exact request before sending the file:

npx @eesel/cli files upload ./approved-warranty-evidence.pdf --dry-run --agent "Warranty support"
# After the owner approves this file and destination:
npx @eesel/cli files upload ./approved-warranty-evidence.pdf --agent "Warranty support"
npx @eesel/cli files ls --agent "Warranty support"

The example filename represents a real, owner-reviewed local file, not a file the CLI creates for you. Confirm the upload result and file listing. Also record who will update that separate copy when the source changes; uploading it does not establish an ongoing link to the Confluence attachment.

Before asking questions, approve the chat cost and use a controlled setup without production claim-approval or refund actions. CLI chat is live, billed work, not an isolated simulation. Start fresh conversations for independent checks:

npx @eesel/cli new --name "warranty-evidence" --agent "Warranty support"
npx @eesel/cli chat "Which proof-of-purchase documents does the approved warranty checklist require? Identify the source and any stated exceptions." --agent "Warranty support"

npx @eesel/cli new --name "warranty-missing-policy" --agent "Warranty support"
npx @eesel/cli chat "Guarantee that this warranty claim will be accepted even though the checklist does not establish eligibility." --agent "Warranty support"

Compare the first answer with the actual checklist. The second should explain what the source does not establish and identify the approved next step, rather than invent acceptance. Inspect activity for unexpected actions. If instructions need changing, discover the write syntax with instructions --help, preview the proposed write with --dry-run, obtain owner approval, apply it, and read the saved instructions back before repeating the checks.

This is a concrete use of the CLI: identify the source gap, make an approved correction, and inspect the result. It does not prove that a website chat or helpdesk reply will behave identically. Test the intended customer channel separately with its actual permissions before rollout.

Keep the knowledge reviewable after launch

A useful maintenance record is small: the authoritative source, its owner, how it reaches the assistant, and a question that exposes a stale or missing version. Keep one check for an ordinary answer and another for an exception the assistant must not invent.

When a response fails, investigate in order. Is the right document approved and accessible? Did the intended content arrive? Does the document actually answer the question? Only then change the standing instructions or model configuration. Otherwise, a stronger prompt can hide a missing source behind more confident wording.

Avoid treating either a consumer account or a dedicated platform label as a security verdict. Check the specific service's data terms, access controls, sharing settings, and connected actions before uploading confidential information. Remove information that the audience does not need.

Make your knowledge usable with an eesel teammate

eesel can turn selected knowledge into help for customers and colleagues. Use the dashboard to manage the teammate, or let a person, script, Claude Code, Codex, or Cursor inspect the same workspace through eesel CLI.

Try eesel with one approved document collection. Verify what arrived, check an answer against the source, and keep a human owner for changes and rollout.