Course-Level AI Teaching Assistants for Higher Education, Built Directly by Faculty

Dr. Kelly Price-Rhea teaches marketing at East Tennessee State University, where she is Program Coordinator and Director of the fully online M.S. in Digital Marketing. She built six AI teaching assistants, one for each of her courses, each grounded in her own syllabi, readings and assignment briefs, and each configured to answer in her own voice. No developer was involved. No IT ticket was raised. In a typical semester those assistants serve around one hundred students. She shared how she built them, and every figure here comes from her own account.

The question arrives at midnight. The answer waits until morning.

An undergraduate in Principles of Marketing is working through an assignment at midnight. A graduate student in the online M.S. in Digital Marketing program wants to check a course policy before a deadline the next morning. Under the old arrangement, one person answered both: their professor, across six different courses, whenever she next found the time.

Her courses are fully asynchronous, which is the point of them. A student can be working at any hour, on any day, around a job and a family. The answer to almost every question already existed somewhere, in a syllabus, a reading or an assignment brief she had written herself. Reaching it meant email, Zoom, phone or a D2L chat, and then a wait.

A general-purpose assistant trained on nothing in particular would not have closed that gap. It would have been a search engine with better manners. What she wanted was something that knew this exact course, and answered the way she would answer.

Six assistants, one per course

There are two for sections of Consumer Behavior, and one each for Social Media, Principles of Marketing, Special Topics in Digital Marketing, and Digital Marketing Ethics. Each is grounded in that course’s own materials rather than a shared departmental pool, so a question about one course is answered from that course’s documents and nothing else.

They sit where students already look. Each assistant is pinned to the top of its course’s D2L announcements page and placed inside a course module as well, so nobody has to adopt a new tool or remember a second login. The assistant is part of the course shell students open anyway.

They are maintained the way a syllabus is maintained. She reviews each one before the course begins and re-uploads materials by hand whenever something changes. That is a deliberate choice rather than a limitation, because it keeps the person who knows the course in control of what the assistant can say.

Five things she would not compromise on

First, it had to sound like her, not like a generic bot. Second, it could not replace her as the instructor. Third, it had to require no technical setup, because adding a developer to the loop would have defeated the purpose. Fourth, materials had to stay current on her own schedule, not someone else’s release cycle. Fifth, students still had to be able to reach her directly whenever they needed to.

Those five read like modest asks. Together they rule out most of the market. An assistant that needs an engineer fails the third. One that routes students away from their instructor fails the second and the fifth. One that speaks in a vendor’s register fails the first before a student has finished reading the opening line.

The capability that decided it was voice

What settled the choice was not a technical feature so much as how much of each assistant’s tone and approach she could shape on her own. She did not want generic answers. She wanted every assistant to read as an extension of the course, consistent with how she presents material in class.

Building that took nothing more than her own course materials and time spent testing and refining. A professor with more than twenty years of teaching behind her already knows how she wants a concept explained. The work was getting that into the assistant, and she could do it directly, without writing a line of code or asking anyone’s permission.

What one instructor built, and kept running

One faculty member built and has maintained six separate assistants, spanning both undergraduate and graduate courses, with no developer or IT involvement at any point. Each continues to run on course materials she reviews and updates herself, semester after semester.

In her words: “The assistant gave them a place to start using the context and guidance I had provided while I remained available as their instructor when they needed me. That was especially valuable in an online learning environment, where students may be working on coursework at very different times of the day. It also had the potential to reduce some of the repetitive, routine questions that naturally occur in a course, allowing my interactions with students to focus more on discussion, clarification, and the kinds of questions where my experience and judgment as the instructor mattered most.”

The boundary in that quote is the part worth noticing. The assistant handles the first layer. She stays available for everything past it.

Why this approach worked

No developer required. Building an assistant took course knowledge rather than engineering, so the person who actually knows the course could build it herself. That removes the queue, the ticket and the translation loss between what an instructor wants and what a developer delivers.

A voice rather than a script. Each assistant’s tone and approach could be shaped directly, so it reads as an extension of her teaching rather than a chatbot bolted onto a course.

It lives where students already are. Embedded in the existing D2L shell, which means nothing new had to be adopted, learned or supported.

What this means for your department

You do not need to be a technology expert. You need to know your course and your students, which you already do.

Start with the course you know best. Build one assistant, use it for a term, then add the next as that course comes around. Six did not arrive at once, and they did not need to.

Decide early what it will not replace. This instructor kept the assistant to a first layer of questions and stayed directly available for everything else. Naming that boundary before launch is what keeps an assistant from quietly becoming a wall between a student and a teacher.

The undergraduate working through Principles of Marketing at midnight gets a first answer without waiting for morning. The graduate student checking a course policy before a deadline gets the same. And the professor who used to field every one of those questions herself, across six courses, can spend more of that time on the discussion and judgment calls where her experience matters most.

Measure	To date
Personal AI teaching assistants, one per course	6
Students reached in a typical semester	~100
Developers or IT staff involved	0
Faculty member behind every voice	1
Course sections covered, undergraduate and graduate	6

Figures reported by Dr. Kelly Price-Rhea, East Tennessee State University, from her own account of building the assistants.