Designing Custom Assistants
Course Target: Engineer code-free, specialized assistants — Custom GPTs, Gemini Gems, Claude Projects, and Microsoft Copilot agents — by giving them clear instructions, grounding them in your own materials, and shaping how they interact through Socratic scaffolding.
A custom assistant is not a new model and not a coding project. It is a reusable briefing that sits on top of a chat model and loads before every conversation, so the assistant opens already knowing its job, its sources, and its rules. In this lesson, faculty learn the one design that all four tools share, how to ground an assistant in course materials so it stops inventing, and how to write instructions that teach by guiding rather than by handing over the answer.
Learning Objectives
- Identify the shared building blocks of a custom assistant — name, system instructions, grounding knowledge, capabilities, and sharing — and recognize them across Custom GPTs, Gemini Gems, Claude Projects, and Copilot agents.
- Write system instructions that ground an assistant in your own course materials so it answers from your sources rather than the model's training data.
- Apply Socratic scaffolding so an assistant guides learners with questions and staged hints instead of handing over finished answers.
- Build, stress-test, and iterate an assistant against a small bank of edge-case prompts until its behavior is reliable.
Key Terms
Select any card to flip it and reveal the definition. Cards are keyboard-operable — press Enter or Space.
Course Outline & Lesson Modules
The shared anatomy of an assistant
Whatever the brand on the box, a custom assistant is the same thing: a configuration layer that sits on top of a base chat model. You are not training a model and you are not writing code — you are packaging a briefing the model reads before every conversation. Learn that briefing once and the skill transfers to all four tools.
Nearly every builder asks you to fill in the same handful of parts:
1. A name and short description. So you and your colleagues can find the assistant later and understand its job at a glance.
2. System instructions. The standing prompt — the heart of the whole thing. It sets the role, scope, tone, rules, and the lines the assistant must not cross.
3. Grounding knowledge. Reference files the assistant can draw on: your syllabus, rubric, or policy documents.
4. Capabilities and tools. Optional powers such as web search, data analysis, image generation, or connections to other apps.
5. Conversation starters. A few example prompts that remove the blank-page problem for first-time users.
6. Sharing and permissions. Keep it private, share by link, or roll it out to a team or whole institution.
Why grounding changes the answer
By default a chat model answers from patterns learned in training. It is fluent, but generic — and it can confidently state a due date, a policy, or a figure that is simply wrong for your course. Context grounding fixes this by attaching your own materials so the assistant answers from your syllabus and your rubric, says "that isn't in the course materials" instead of inventing, and stays consistent with what you actually teach.
How each builder grounds its answers
Custom GPTs (ChatGPT). In the Configure tab, upload files under Knowledge. One caution: people who use the GPT may be able to download those files, so never ground a shared GPT in anything sensitive.
Gemini Gems. Add files under Knowledge, or pull them from Google Drive — a Drive-linked file updates automatically when you edit the original. For a larger curated source set, connect a NotebookLM notebook.
Claude Projects. A shared Files knowledge base is available to every chat in the project. On paid plans, retrieval lets that knowledge base scale well beyond what fits in a single conversation.
Microsoft Copilot agents. Ground in SharePoint sites, the public web, or Microsoft 365 connectors. Agents respect existing permissions — "no new privileges" — so a user only ever sees content they were already allowed to see.
| Builder | Where you build it | How it grounds | Who can build | Best fit |
|---|---|---|---|---|
| Custom GPT | ChatGPT web → Explore GPTs → Create | Uploaded knowledge files | Paid plans (Plus, Pro, Team, Enterprise) | Shareable task assistants & the GPT Store |
| Gemini Gem | gemini.google.com → Gems → New Gem | Uploads, Google Drive, NotebookLM | Free and paid tiers | Google Workspace users & quick reuse |
| Claude Project | claude.ai → Projects → New project | Files knowledge base (retrieval on paid) | Free (limited) and paid plans | Document-heavy, careful reasoning work |
| Copilot agent | Microsoft 365 Copilot → Agent Builder (or Copilot Studio) | SharePoint, web, M365 connectors | Microsoft 365 Copilot licensees | Institutional data behind existing permissions |
Practical example
Picture a "Course Concierge" grounded in your syllabus, schedule, and rubric. A student asks when the second project is due or how participation is weighted; the assistant answers in your phrasing, cites the document it drew from, and — when a question isn't covered — points the student to office hours instead of guessing. Same build pattern in any of the four tools; only the upload screen differs.
Designing instructions that teach
For an educational assistant, the instructions are where your pedagogy lives. A tutor that simply answers is an answer key with a friendlier voice. Socratic scaffolding means telling the assistant, explicitly, to ask before it tells — and to reveal help in stages.
Effective patterns to write into the instructions include: ask the student what they have already tried before offering help; give at most one hint per turn; have the student attempt the next step before you confirm it; and if they are still stuck after a few hints, show a worked example of a similar problem rather than the assigned one. The goal is a productive struggle, not a shortcut around it.
Guardrails and integrity
Two rules belong in almost every educational assistant. First, protect privacy: keep student names, grades, and other personal data out of the knowledge base entirely. Second, protect the learning: instruct the assistant to refuse to complete graded work, to coach the student to produce it themselves, and to cite course materials while flagging anything they don't cover. (Lesson 11 returns to FERPA and governance in depth.)
The build–test–refine loop
No instruction set is right on the first try. Build the assistant, then stress-test it with a small spread of prompts: a simple request, a complex multi-step one, an ambiguous one, an out-of-scope one, and a contradictory one. Watch where it misses, then tighten the instructions — usually by adding an explicit "do not" rule or a short example — and test again. Remember that instructions are behavioral guardrails, not security controls: assume a determined user will push, and design accordingly.
Hands-on Workspace Modules
Assistant Spec Sheet
Plan before you build. Define your assistant's purpose, audience, role, grounding sources, and guardrails, then generate a portable spec block you can drop into any of the four builders.
Socratic Instruction Builder
Assemble a system-instruction block for a grounded tutor — choosing how Socratic it should be, what it must never do, and how it cites your materials — then copy it straight into your builder.
Build, Test & Iterate
Stand up your assistant in a chosen platform, then run it through an edge-case stress test and log what breaks, refining the instructions until the behavior holds.