Chapter 2. Knowledge spaces and custom assistants

Learning objectives

• Explain the differences between knowledge spaces (projects), shared projects and custom assistants, and choose according to the collaboration model.
• Distinguish where personal custom instructions, project instructions and assistant instructions apply.
• Put behavior rules in instructions and reference material in knowledge, and rewrite a work procedure as team instructions.
• Understand knowledge capacity and retrieval, and design searchable materials and update cycles.
• Build a test question set covering normal, exception, refusal and boundary cases, and validate before rollout.

Introduction

A company's HR team built an internal policy assistant. They uploaded six policy PDFs and wrote “Answer kindly” in the instructions field. The first week's response was positive. In the second week, however, an employee asked, “Hasn't the travel expense policy changed?” The assistant confidently answered using last year's policy. The revision had only been posted on the notice board and had not been uploaded. In the third week, it invented plausible answers to questions the policies did not cover. The instructions never said what to do when it did not know. By the fourth week, employees were checking its answers with HR again, and HR received more inquiries than before. An unreliable helper creates more work than having no helper at all.

The failure was not model performance. The team had not designed what belonged in instructions versus materials, who would update materials and when, or what to test before rollout. This chapter starts with knowledge spaces and custom assistants, then covers writing instructions, organizing and updating searchable materials, and testing before rollout. Here you build the tools for the “AI handles this” steps in your Chapter 1 table. This is one of the most heavily weighted exam domains, so be sure to complete the hands-on tasks too.

Key concepts

Knowledge spaces (projects)

A knowledge space is a workspace that groups related conversations, files and instructions. Product names vary, but the purpose is the same. OpenAI describes ChatGPT Projects as keeping related conversations, files and instructions together so the same context can be reused. Anthropic describes Claude projects as self-contained workspaces with their own conversation history and knowledge bases. In Google's Gemini Notebook, each notebook is a collection of sources for a particular project, and notebooks cannot access one another's information.

Think of a knowledge space as a dedicated workroom for one project. Work rules (instructions) hang on the wall, reference material (knowledge) sits on shelves, and past conversations accumulate on the desk. Separate workrooms are the default for work requiring boundaries, such as different clients' projects or departmental policies. Separate rooms alone do not complete the boundary, however: context may cross them depending on memory settings, which must also be checked (see Going deeper).

Three layers of instructions

The scope of instructions depends on where you write them.

OpenAI's help pages state that project instructions apply only within their project and override global custom instructions. To achieve consistent team results, put shared rules in project or assistant instructions rather than relying on each member's personal settings. Conversely, avoid putting team rules in personal custom instructions; that creates inconsistent results between people.

Shared projects and custom assistants

A custom assistant combines instructions and reference materials so multiple people can use AI in the same way. A shared project is a workroom where several people accumulate conversations and materials together. OpenAI's help pages compare the two forms as follows.

Products are changing quickly. OpenAI plans to retire custom GPTs and recommends moving to Plugins that bundle reusable instructions with connected apps. Google says personal-account Gems will move to skills from November 2026, with work and school accounts following in 2027. Anthropic offers Skills—bundles of instructions, scripts and materials loaded when needed—alongside project instructions. Even when names change, the distinction remains: “the same fixed procedure for many people” versus “a small group building context together.”

Why instructions and knowledge are kept apart

Instructions are the assistant's work rules, and knowledge is the reference shelf next to it. Work rules must apply to every conversation, while the reference shelf is consulted when needed. OpenAI explains that instructions apply to every conversation and guide tone, structure and decisions. It says knowledge is for reference material, not rules or behavior; rules, tone and work procedures belong in instructions.

If you tuck rules into the front page of an uploaded manual PDF, they may not apply unless retrieval pulls out that part. Conversely, pasting extensive material into the instructions field buries the actual rules. Also consider responsibility for changes. The assistant administrator changes instructions, while the department responsible for a policy changes its original text. Items updated by different people belong in separate places to prevent confusion during updates.

Five elements of team instructions and writing tips

Google advises considering four areas when writing Gem instructions: Persona, Task, Context and Format. For team work assistants, add exception handling as a fifth element.

The three companies' writing recommendations broadly align. For multistep tasks, OpenAI recommends explicit steps such as “when X happens, do Y,” specific positive directions rather than long prohibition lists, brief examples of acceptable and unacceptable output when classification criteria exist, and headings and lists to show priority. Anthropic explains that adding the reason behind an instruction helps the model understand its purpose. “Name the source document, because employees must check the original before copying it into approval paperwork” is better than “Name the source document.”

Turning a work procedure into instructions

Good instructions often come from an existing work procedure. Follow the order people use, adding input checks at the beginning and stop conditions at the end. Here is an equipment loan example.

[Before]
You are responsible for equipment loans. Answer kindly. Do not give incorrect answers.

[After]
[Role]
You are the guide at the internal equipment loan desk. Explain whether employees can borrow equipment and how.
[Procedure]
1. If the question lacks equipment type and loan period, ask for both first.
2. Find the relevant equipment clause in the knowledge document 'Equipment loan policy' and determine eligibility.
3. Answer in this order: one-line conclusion, no more than three procedural steps, supporting clause number.
[Exceptions]
- If equipment or circumstances are not covered by the policy, do not infer from similar clauses.
  Write "This is not covered by the policy" and direct the user to the general affairs loan desk.
  Reason: loss of equipment borrowed on incorrect guidance can result in personal liability for replacement costs.
- If asked about loan history or other employees' applications, do not answer; direct the user to the loan system.

The revised instructions are longer, but each line has a clear purpose. Wishes such as “Do not give incorrect answers” have been replaced with actions that prevent errors: ask first, find evidence, and hand off when unsure.

Answers that expose uncertainty and conflict

Fluent sentences conceal uncertainty. For work, admitting uncertainty is much safer than being confidently wrong. Put the following in instructions to make uncertainty visible.

1. Flag unsupported content: when no evidence is found, say so and identify the person or material to consult.
2. Distinguish facts, inferences and suggestions: label their nature, such as “According to Article 4 (fact),” “This appears to apply here too (inference),” and “We recommend checking with the responsible department (suggestion).”
3. Present conflicting evidence together: show both sources instead of quietly choosing one, and apply predefined precedence rules.
4. Show evidence locations: document names and clause numbers help people check the original. OpenAI also recommends explicitly instructing the assistant to cite knowledge content and specifying the format.

Knowledge capacity and retrieval

With a small amount of material, a system may put everything into context. As a knowledge space grows, however, the model does not read every document each time. A librarian responds to a question by fetching only relevant books. Similarly, RAG (retrieval-augmented generation) is a method of retrieving relevant passages and using them in an answer. Materials are usually stored in small chunks, and chunks similar to the question are selected. Anthropic explains that paid-plan Claude projects automatically switch to RAG as knowledge approaches the context limit—the amount the model can read at once—expanding capacity by up to ten times.

Products also impose capacity limits. As of the verification date, ChatGPT projects allow 5–40 files per project depending on plan, with a limit of ten files per upload batch. GPTs allow up to 20 files, each up to 512MB. These numbers change, so check them whenever designing a solution.

Practical rules follow from this principle.

For exhaustive counts, use a separate method that processes the full dataset, such as a spreadsheet or data analysis feature.

Preparing searchable documents

For a librarian to find books, their spines need clear titles. The same principle applies to reference documents. OpenAI recommends clean, text-focused files and explains that complex layouts can make content harder to use.

Several topic-specific documents often retrieve better than one long combined document. Over-fragmentation can break context and distort interpretation, however, so divide material into units that a person would also understand as a whole.

Organizing materials around questions

Choose materials around questions people actually ask, rather than the company's folder structure.

1. Collect actual questions from the past three months and group them by type.
2. Match each type with supporting materials. Create new material for unsupported types or classify them as “refer to the responsible person.”
3. Assign an authority level to each source. Approved policies, departmental notices and personal notes do not carry equal weight.
4. Write precedence rules for conflicting sources in the instructions. For example: approved policy with the latest effective date → departmental notice → past answer examples.
5. If precedence rules cannot resolve the issue, do not answer; refer the user to the responsible person.

If question types require different audiences and tones, separate spaces reduce mixed answers better than putting everything together.

Designing update cycles

Materials need different management depending on how fast they change and what triggers change.

Understand the distinction between a connected source and an uploaded copy too. Google says a Drive file added to a Gem uses the latest version, and edits are reflected in the Gem. ChatGPT's help pages, in contrast, state that a Google Drive app added inside a project does not support syncing and does not synchronize content in advance. Directly uploaded files are copies, so naturally they remain unchanged when the original changes. Check how your product behaves and assign an owner responsible for replacing outdated file copies.

Manage updates through a materials register.

Material | Authority level | Effective date | Responsible department/contact | Connected/copy | Next review date | Last test date

Testing before rollout

Before rolling an assistant out to your team, build a test question set. Collect 20–30 pairs of questions and expected answers or behavior, mixing four types.

Run the set in preview and record expected and actual behavior in a table. Google says testing a Gem in preview does not save it automatically, so you must click Save. OpenAI explains that edits to GPTs are automatically saved as drafts and earlier versions can be restored from version history. Check your product's documentation, as saving behavior varies. Keep the test question set after rollout. Rerun it whenever instructions or materials change to ensure a fix has not broken other answers (Chapter 5).

Going deeper

Ingestion, retrieval and generation are different stages

“Why doesn't it know, when I uploaded the file?” can conceal three different failures.

A citation does not guarantee a correct answer. It shows where content came from, not whether it was interpreted correctly. Identify the failed stage before choosing a remedy. Fix ingestion failures by preparing materials; fix retrieval failures by adding a glossary and synonyms or providing guidance on how to phrase questions; fix generation failures by revising procedures and exception handling in instructions.

Designs that survive product changes

Even during the writing of this book, custom GPT retirement and the Gems-to-skills transition were announced. If the work of building an assistant is locked into one product, every product change means starting over. These principles substantially reduce migration costs.

1. Store original instructions outside the product. Dated documents also provide version control.
2. Keep original knowledge materials in the company's document repository. Put only copies or connections in the assistant.
3. Maintain test question sets independently of the product. Running the same set after migration quickly shows whether it worked.
4. Describe forms, rather than product feature names, in design sheets. Instead of “one GPT,” write “guidance assistant based on fixed material, 200 users, evidence citations required.”

Boundaries between memory and knowledge

Uploaded files are not the only context in a knowledge space. OpenAI explains that projects can use their conversations and files as context in later answers. Shared projects automatically use project-only memory, without members' personal memories or context outside the project. Even project-only memory can reference other conversations in that project.

This is both an advantage and a risk. Memory scope also differs by product. On some ChatGPT plans, including Business, default memory can reference conversations outside the project; choose project-only memory to contain context. Claude has separate project memories but also uses account memory from outside the project, so turn off “Use account memory” in the project for full separation.

If a conversation discussing an idea rejected at a past meeting remains, that idea may reappear in answers. Move confirmed decisions out of scattered conversations into formal material such as a “Decision log.” Write in the instructions that formal materials take precedence over conversation history. To stop referencing a particular conversation in OpenAI, delete it or, where settings permit, move it to another project.

At work

Friendly Table Snacks: a franchise operations manual helper

The headquarters operations support team at snack-food franchise Friendly Table Snacks handles operational questions from 140 franchise owners. About 60 daily questions concerning hygiene checks, ingredient order deadlines and promotions arrive through messenger to six supervisors. Team lead Han Soyul decided to build a franchisee guidance assistant.

Han chose the form first. Owners ask individually, and headquarters maintains the manual as fixed material. A shared project with 140 owners would expose one another's conversations and files, so it was unsuitable. Han chose a custom assistant that answers through the same procedure.

To choose materials, Han grouped 600 questions from the past three months by type. Order deadlines and promotions accounted for half, exceptions by location type—airport and hospital outlets—for 10%, and some questions concerned store sales or other outlets' circumstances. Sales questions were outside the assistant's role. They became refusal cases directing owners to their dedicated sales system.

Conflicting material was the problem. The operations manual said orders closed at 6 p.m. the previous day, but a headquarters notice last month had moved this to 4 p.m. A supervisor suggested simply uploading the notice. Han pointed out that notices would keep accumulating monthly. The instructions specified precedence: “headquarters notice with the latest effective date → operations manual → past answer examples.” Until the manual was updated, Han marked the relevant clause “Change notice exists,” so even retrieval of that chunk alone would reveal the notice. The materials register also specified incorporating notices into the manual at each month-end and removing incorporated notices from knowledge.

The instructions included location-specific exceptions. If an answer depended on store type and the owner had not specified it, the assistant would ask first. Answers would distinguish “manual evidence” from “supervisor confirmation recommended.”

The test set contained 18 normal, five exception, three refusal and four boundary questions. Two boundary questions failed initially: the assistant applied the new deadline to orders placed before the notice took effect. Han added, “Apply the previous rules to cases before the notice's effective date; if the date is unclear, ask.” All 30 then produced the expected behavior. During the first month after rollout, daily messenger questions to supervisors fell from 60 to 25.

Dawn Bakery: a shared project for a seasonal campaign

Four marketers at Dawn Bakery spent three months preparing a year-end campaign. Team lead Kwon Doyun created a shared project in the business workspace, collecting proposals, brand guidelines, previous campaign results and weekly meeting minutes. After about a month, colleagues began complaining: copy drafts repeatedly included a slogan rejected two weeks earlier.

Kwon identified three causes. First, brainstorming conversations about the rejected slogan remained in the project and were being used as context. Second, both old and revised brand guidelines had been uploaded. Third, no document recorded confirmed decisions.

One colleague suggested deleting the project and starting again. Kwon rejected that option: most of the three months' context was useful, and the same habits would cause the same problem in a new project. Instead, Kwon made these changes.

1. After each weekly meeting, confirmed decisions were dated in one “Campaign decision log,” uploaded as project material.
2. Project instructions stated, “Copy and planning follow the Campaign decision log and latest brand guidelines. If ideas in conversation history differ from the decision log, follow the log and point out the difference.”
3. The old brand guidelines were deleted, and brainstorming conversations solely about rejected ideas were cleared out.
4. Frequently changing store event schedules were queried through the connected Drive app in project conversations when needed, rather than uploaded as copies. Answers named the source file and lookup time.

When the campaign ended three months later, store employees began asking about campaign operating rules. Kwon did not take these questions in the shared project. Instead, Kwon built a separate guidance assistant for 300 store employees containing only the decision log and operating rules. The conclusion was that a collaborative workspace and an assistant providing consistent answers to many people serve different purposes.

Common mistakes

1. “Putting everything in one file means it will all be read.” With much material, only relevant chunks are retrieved and used. Put mandatory rules in instructions.
2. “More in the instructions is better.” Extensive reference material buries core rules. Put behavior in instructions and material in knowledge.
3. “Longer prohibition lists mean greater safety.” Specific positive instructions, exception handling and short examples are more effective.
4. “Matching everyone's personal custom instructions makes results consistent.” Shared rules belong in project or assistant instructions so they apply equally to everyone.
5. “A cited source means the answer is correct.” A citation identifies a location, not accurate interpretation. Compare evidence with the original.
6. “A connected drive is always current.” Synchronization differs by product. Check whether it is a connected source or a copy, and assign an update owner.
7. “Testing questions it answers well means it is ready.” Tests missing exception, refusal and boundary cases fail to expose real risks.

Summary at a glance

• A knowledge space is a dedicated workroom grouping conversations, files and instructions. Separate spaces where boundaries are needed.
• Write shared rules in project or assistant instructions, rather than personal custom instructions. Within a project, project instructions override global custom instructions (OpenAI).
• Use custom assistants for the same procedure across many people, and shared projects for small groups building context together.
• Instructions define behavior—role, task, context, format and exception handling; knowledge contains reference materials. Separate items updated by different people.
• Include reasons with instructions, actions to take rather than only prohibitions, and short examples for ambiguous criteria.
• With large knowledge collections, RAG retrieves only relevant parts. More material does not ensure accuracy, and exhaustive counting is a weakness.
• Choose material around questions; record source authority and conflict precedence in instructions.
• Updates may follow periodic revisions or events. Distinguish connected sources from copies and use a materials register.
• Mix normal, exception, refusal and boundary cases in pre-rollout testing, and keep the set.

Check the official docs

• OpenAI — Projects in ChatGPT: Read about project instruction scope, app link sources, Drive syncing limits, file limits, and shared projects versus GPTs.
• OpenAI — Creating and editing GPTs: Check instructions versus knowledge, writing tips, file limits, preview, version history and the custom GPT retirement notice.
• Anthropic — What are projects?: Read about project knowledge and instructions, the RAG transition and capacity expansion.
• Anthropic — What are skills?: Check bundles of instructions and materials loaded when needed, and organization-wide distribution.
• Google — Use Gems in Gemini Apps: Check Gem creation, use of latest Drive file versions and the skills transition notice.
• Google — Tips for creating custom Gems: Read about persona, task, context and format, and the preview saving caution.
• Google — Create a notebook in Gemini Notebook: Check that notebooks are independent source collections.

Self-check

2-1. How do project instructions and personal custom instructions differ in scope? Include the problem with putting shared team rules in personal custom instructions.

2-2. Divide these five items between instructions and knowledge: (A) a rule to end answers with the source document name; (B) regional store opening-hours tables; (C) a procedure to ask for the date first when it is missing; (D) ten past model answers; (E) a rule to use polite, respectful language.

2-3. Rewrite “Answer kindly. Do not be wrong” as instructions with all five elements: role, task, context, format and exception handling. Use internal meeting-room guidance as the topic.

2-4. Explain why RAG-based knowledge spaces are weak at “counting exactly how many cases satisfy a condition across all materials,” and suggest an alternative.

2-5. A user reports, “It doesn't know, although I uploaded the file.” Give one check for each stage—ingestion, retrieval and generation—to locate the failure.

2-6. How do connected sources and uploaded copies differ in update management? Why should the materials register record this distinction?

2-7. Name the four types of pre-rollout test questions and write one line of expected assistant behavior for each.

Hands-on tasks