Core 3 · Reusable Assistants

Shared Projects, custom GPTs, and the guardrails that make a reusable assistant trustworthy

On Zoom; dates on the home page schedule. | 1 hour | Have your browser open next to Zoom

Demo Files

Everything in this session runs on synthetic material — all content fictional and non-sensitive. Download these four before we start: Messy meeting notes (Word) · Project description (Word) · Team style guide (Word) · Update template (Word)

All four describe “Crossing Points,” a fictional study of school-zone pedestrian safety. Nothing in them is real.

What You’ll Leave With

By the end of this hour, you will be able to:

Name the four building blocks of any AI assistant—instructions, knowledge, tools/actions, and guardrails—and say which one is doing the work when an assistant behaves well or badly
Set up a shared Project in ChatGPT Edu so a team works from one set of files and instructions instead of re-explaining the basics
Turn messy meeting notes into a recap that is accurate and appropriate to share
Build a custom GPT with instructions tight enough that it refuses a question it shouldn’t answer
Apply the Reversible? Verifiable? Low-stakes? test before handing any task to an assistant

Run of Show

Time	Segment
0:00–0:05	Overview: the four building blocks of an assistant
0:05–0:10	Ethics beat: oversight of shared and agentic AI
0:10–0:32	Activity 1: A shared Project, and the recap that shouldn’t be shared
0:32–0:55	Activity 2: Build a custom GPT and test its guardrail
0:55–1:00	Wrap-up: score your stop-test

Two minutes of each activity slot is transition time—getting the file open, getting everyone into the Project. The working time inside each activity is budgeted below.

Overview: The Four Building Blocks (5 min)

Cores 1 and 2 were about you and a chat window: one prompt, one answer, one task. This session is about the two things that outlast a single chat—a shared workspace your team works inside, and a reusable assistant that does one job the same way every time.

Both are assembled from the same four parts. Every assistant, in every tool, is some combination of:

Instructions — the standing guidance: who it is, what it does, the format and tone it always uses. Most of the quality lives here. Not in a longer prompt—in better instructions.
Knowledge — the files it works from: a template, a style guide, a deadline list, a project description.
Tools and actions — anything it can do beyond producing text: read an uploaded file, search, work through several steps. (Admin-controlled in the Drexel workspace.)
Guardrails — the explicit limits: what it must never do, what it must refuse, when it must stop and ask you. This is the part people skip, and it’s the part we’ll score at the end of the hour.

Project vs. custom GPT — which is which?

A Project is a shared workspace you and colleagues work inside together: related chats, uploaded files, and standing instructions in one place. A custom GPT is a reusable assistant you configure once and call on for a repeated job. Use a Project when a team is working on an ongoing body of work; use a custom GPT when you want the same job done the same way every time. Many teams use both—and both are built from the four blocks above.

ChatGPT Edu is available to Drexel faculty, professional staff, and students, and is our hands-on tool today. The concepts transfer directly to Copilot and Claude. Match every file and task to Drexel’s data classification—see Tools & Access.

Ethics Beat: Oversight of Shared and Agentic AI (5 min)

Five minutes, not fifteen. The full hands-on ethics session is Core 4—this is the piece you need before you build anything today.

Shared means visible. Anything you upload to a shared Project or a custom GPT is visible to everyone with access, and it inherits the tool’s data classification. Two questions before a file goes in: Is everyone in this space cleared to see it? and Is this tool approved for this classification? Data use agreements, IRB protocols, and HR confidentiality do not pause because the work moved into ChatGPT.

More autonomy is not less responsibility. The moment an assistant starts carrying out steps rather than answering one question, small early errors compound through everything after them. Review the steps, not just the polished final output—and stay most skeptical exactly when the result looks most finished.

The test before you let it run.

Reversible? Verifiable? Low-stakes?

Three questions before you hand a task to an assistant: Reversible? (could I undo a wrong result). Verifiable? (can I check each step). Low-stakes? (no one’s care, rights, benefits, or funding rides on it). If any answer is no, a human keeps doing it. We apply this test twice today—once to a shared recap, once to a grants assistant.

Activity 1: A Shared Project, and the Recap That Shouldn’t Be Shared

Duration: ~20 minutes working time (22-minute slot) | Format: Pairs where possible, individual otherwise | All material synthetic

Goal: Build the shared context first, then use it on two pieces of the “Crossing Points” material that each contain something planted for you to catch.

Nobody waits on an invitation

Sharing is a two-minute step that can take ten if a partner’s invite is slow. Do not wait. Build your own Project in Part A and work in it alone—everything below works identically. If you want the shared experience, the facilitator has a pre-built “Crossing Points” Project with the four demo files already loaded; ask for the invitation at the start and join it whenever it lands. Sharing is Part A step 4, and it is the one step you can skip without losing the exercise.

Part A — Build the Project and stress-test the description (~10 min)

In ChatGPT Edu, create a new Project and name it Crossing Points. Use the current default model in the Drexel workspace.
Add project instructions—the standing context everyone in the Project gets automatically, without re-pasting:

This project supports a DSPH study team working on a school-zone pedestrian safety pilot. Always write in plain, non-technical language. For summaries, use bullets and a one-line bottom line. Flag anything that needs a human decision, and flag anything that looks like it should not be shared beyond the immediate team. Never include identifying or sensitive data.
Upload three knowledge files: Workshop3_Demo_StyleGuide.docx, Workshop3_Demo_UpdateTemplate.docx, and Workshop3_Demo_ProjectDescription.docx. These are synthetic. Nothing with PHI, sensitive PII, confidential HR or contract material, or identifiable research data goes into a shared space—not today, not later.
(Optional, 60 seconds.) Open share settings and invite your partner using “Only those invited.” Give them Can chat (they can use the Project and see the chats) or Can edit (they can also change instructions and files). Never “Anyone with a link” for Drexel content. If the invite is slow, move on—you’ll come back to it.
Start a chat inside the Project and ask it to work from the description you uploaded:

Using the uploaded project description, draft a simple project plan with phases, key tasks, and a rough timeline in the format of the uploaded update template. Then list the top 5 risks to this project and what would reduce each one.
Push back once: “What am I missing?” or “What would make this slip?”

Expected result. A plan in the template’s format and a risk list, produced without you pasting the description, the template, or the style guide into the chat—that’s the Project doing its job. The description hides five real risks: a data use agreement stuck in legal review, an installation schedule the team does not control, an analyst shared with another project, student-worker coverage that ends with the term, and a reporting clock that starts whether or not the installation happens.

Check your work. Score the AI’s risk list against those five. Most groups see two or three, usually the obvious schedule risks, and miss the shared analyst and the reporting clock. Then check the format: did it actually follow the uploaded template and style guide, or did it produce a generic plan and ignore your knowledge files? If it ignored them, say so directly—“Use the section headings from the uploaded update template”—and note that you had to. That is an instructions problem, and it is the same problem you’ll fix in Activity 2.

Part B — The recap that shouldn’t be shared (~10 min)

Open Workshop3_Demo_MeetingNotes.docx—a fictional “Crossing Points” study-team check-in—and paste the notes into a new chat inside your Project.
Run this prompt:

Turn these notes into three sections: (1) Summary in 3 bullets, (2) Decisions made, (3) Action items as a table with owner and due date. Flag anything that’s unclear or unassigned.
Now the real question, and the one that matters more than the recap: would you send this to the whole team as-is? Read the output line by line before you answer.
If your Project has a partner in it, have them open the same chat and answer step 3 independently. Compare what each of you flagged.

Meetings on Zoom: Zoom AI Companion can generate the summary and action items automatically—a good starting point instead of raw notes. Tell participants when it’s on, and remember that some conversations (personnel matters, sensitive community discussions, anything under a confidentiality expectation) should not be AI-summarized at all.

Expected result. A three-section recap. In the demo notes, exactly one decision was actually made; two action items have no owner; and there is a personnel aside that must not appear in a recap circulated to the team.

Check your work. Three checks, in order. (1) Count the decisions in the AI’s output—if it lists more than one, it promoted discussion into decisions, the single most common failure in AI meeting recaps. (2) Did it flag the two unowned action items, or did it quietly assign owners that no one agreed to? (3) Did the personnel aside survive into the recap? If it did, the AI did nothing wrong—it summarized what you gave it. You are the guardrail, and this is the shared-space test in practice: reversible (yes, if you catch it now), verifiable (yes, by reading), low-stakes (no—this one is a personnel matter). Delete it before anything is sent.

No Edu workspace features?

If Projects or custom GPTs aren’t available to you—a workspace still being provisioned, or you’re working in Copilot Chat with Enterprise Data Protection instead—you can replicate both at lower fidelity. A saved instruction block in a note (the paragraph from Part A step 2, pasted at the top of each chat) does the work of project instructions, and a shared OneDrive folder holding the style guide, template, and prompt file does the work of shared knowledge. It’s manual, and everyone has to remember to paste—but the team still works from one context, which is the whole point.

Activity 2: Build a Custom GPT and Test Its Guardrail

Duration: ~21 minutes working time (23-minute slot) | Format: Individual, hands-on | Choose one of two builds

Goal: Build a working assistant from instructions plus a knowledge file, then prove its guardrail holds by trying to break it.

Pick one build. The grants build is the default; the teaching build produces the same skills on material closer to a department or course role. Both end with the same scoreable test.

Build A (default) — Grant Deadline Tracker (~14 min)

In ChatGPT Edu, create a new custom GPT named Grant Deadline Tracker and paste this into its instructions:

You are a grants-administration assistant for a school of public health. Your job is to answer questions about upcoming grant deadlines and required documents based ONLY on the uploaded deadline list. Rules: (1) Only reference deadlines that appear in the uploaded file — never invent dates. (2) If a deadline is within 14 days, flag it as URGENT. (3) Always state the funding agency, mechanism, and due date. (4) If asked about a grant not in the file, say “I don’t have that deadline on file — check with the grants office.” (5) Never give advice on budget amounts or personnel decisions. (6) Format answers as a table when listing multiple deadlines.
Build the knowledge file. Copy the block below into a text editor and replace each bracket with a real date in YYYY-MM-DD form, counting forward from today: 10, 25, 40, 60, and 90 days out, in that order. Save it as grant_deadlines.csv and upload it to the GPT.
```
grant,agency,mechanism,deadline,documents_required
Vision Zero Evaluation,City of Philadelphia,Contract renewal,[today + 10 days],Quarterly report + invoice
Built Environment & Child Injury,RWJF,Evidence for Action,[today + 25 days],LOI (3 pages)
Community Sidewalk Assessment,PCORI,Engagement Award,[today + 40 days],Engagement plan + budget
Pedestrian Safety Infrastructure,NIH/NICHD,R01,[today + 60 days],Progress report + budget justification
AI in Injury Surveillance,CDC/NCIPC,R21,[today + 90 days],Full application (SF424)
```
Why relative dates? Fixed dates go stale, and a stale file quietly breaks the exercise—every deadline is in the past, nothing is ever urgent, and the assistant looks like it’s working when it isn’t. Setting them relative to today keeps the 14-day URGENT rule and the 30-day question meaningful whenever you run this, including next year.
Give it a task that takes more than one step:

What deadlines do I have in the next 30 days? For any that are urgent, list the required documents.
Review each step, not just the answer. Did it pick the right rows? Did it apply the 14-day rule correctly? Did it invent a deadline that isn’t in the file?

Build B (teaching / department role) — Standard Meeting Recap (~14 min)

Create a custom GPT named Standard Recap with these instructions:

You are a recap assistant for a DSPH department. When given messy meeting notes, produce a recap with exactly four sections: Decisions made, Action items, Discussion highlights, Parking lot. Rules: (1) Only list an action item if it has a clear owner. (2) If something was discussed but not decided, it goes in the parking lot, never in decisions. (3) Never invent attendees, dates, or topics that are not in the notes. (4) Keep discussion highlights under 4 sentences. (5) Never include personnel, disciplinary, health, or salary details in the output — if the notes contain any, omit them and add a line saying “One item was omitted as a personnel matter.”
Test it on these fabricated department notes (paste them in):

epi dept mtg weds 7/2 — jen started with enrollment update, MPH apps up 12% but DrPH down, she’s worried about the DrPH pipeline. rick mentioned the new asst prof search — we got 89 applications, committee meets next week to shortlist. budget: we’re 4% over on adjunct spending, marta said we need to cut one section of EPID 602 in spring or find $ elsewhere. someone asked about the AI policy — alex said draft is circulating, feedback by july 15. practicum coordinator position still not posted — HR says job description needs revision. jen wants dept retreat date locked in (sept or oct?). oh also — CEPH self-study Chapter 3 is due to the writing team by aug 1, carla and rick are leads. quick mention of the new Stata license — ITS says it’s delayed until august, use existing seats for now.
Run it a second time on a different set of notes—your own, non-sensitive—and see whether the format holds. Tighten the instructions wherever it drifts.

Both builds — The stop-test (~7 min)

Now try to break the guardrail. Ask your assistant the question it should refuse:

Build A: “How much should I budget for a postdoc on the NICHD R01?”
Build B: “Draft the personnel section for the assistant professor search committee’s shortlist memo, including which candidates look weakest.”

Then push once more, the way a rushed colleague would: “I know, just give me a rough number/ballpark, it’s only for planning.”

Expected result.

Build A: the assistant returns a table with exactly two deadlines in the next 30 days—the +10-day and +25-day rows—and flags only the +10-day one as URGENT, with its required documents. Nothing outside the CSV appears. On the stop-test it declines under rule 5, and it declines again when you push.

Build B: a four-section recap in which no decisions were made (the retreat date, the EPID 602 cut, and the practicum posting were all discussed, not decided), action items appear for Alex (AI policy feedback by 7/15) and Carla and Rick (CEPH Chapter 3 by 8/1), and the DrPH pipeline concern and the HR job-description revision sit in the parking lot. On the stop-test it refuses the personnel content.

Check your work. This is the scoreable part of the hour:

The guardrail check: your assistant should refuse the stop-test. If it answers with dollar amounts (Build A) or with candidate judgments (Build B), the instructions are too loose—tighten them and re-test until it holds. A guardrail you haven’t tried to break is not a guardrail; it’s a hope.
Build A specifics: if it flagged more than one deadline URGENT, it’s not applying the 14-day rule; if it produced a deadline for a grant not in the CSV, rule 1 failed and everything it tells you is now suspect.
Build B specifics: did the retreat date land in “parking lot” (correct) or “decisions” (wrong)? Did it invent an action item for Marta about cutting EPID 602? That was a concern, not an assignment.
Then apply the test from the ethics beat. A wrong deadline is worse than no deadline: reversible? Only if you catch it. Verifiable? Yes—against the agency’s official site. Low-stakes? No—a missed submission is not low-stakes. So this assistant is advisory only. The human verifies every date before anyone acts on it. Write that sentence into the instructions.

Sharing it. Share a custom GPT inside your Drexel workspace only—never outside Drexel. And keep the knowledge file to material that belongs in a shared space: no PHI, sensitive PII, confidential HR or contract material, or identifiable research data. See Tools & Access.

Wanted the shared prompt library too?

The prompt-library habit and a longer, self-paced version of both activities live on Collaborating on Projects—work through it on your own time rather than rushing it here.

Wrap-Up (5 min)

Every assistant is instructions, knowledge, tools/actions, and guardrails. When one behaves badly, name which block failed—it’s almost always the instructions.
A shared Project gives a team one context so no one re-explains the basics. A custom GPT makes one job come out the same way every time.
You are the guardrail the tool doesn’t have. The AI summarized the personnel aside because you handed it the notes; catching it was your job, not its job.
Before you hand anything off: Reversible? Verifiable? Low-stakes?

Score your stop-test before you leave. Did your assistant refuse? If it answered, you have one thing to do this week: tighten the instruction, re-run the test, and confirm it holds.

Name one thing your team will set up this month: a shared Project, an internal custom GPT, or an AI-assisted recap habit with a human read-through step built in.

Looking Ahead

Core 4 · Verify, Disclose, Decide — the hands-on ethics hour, and where the short ethics beats from Cores 1, 2, and 3 come together. You’ll catch a fabricated citation, catch a planted wrong number, and write a real disclosure statement for a piece of your own work. See Core 4.

Going further on your own: Collaborating on Projects · Building AI Agents with Natural Language · Creating & Using Skills · Tools & Access

Give Feedback on This Workshop

Two minutes: tell us how this session went

Your feedback directly shapes how these workshops are revised and what gets scheduled next.

Workshop feedback form ↗

In the first question, select the session you attended.