Building an AI tutor that teaches the syllabus instead of doing the homework

The situation

An education platform served structured courses to school-age students, aligned to a defined syllabus. Students were already using general-purpose chatbots for homework help, and teachers could see the result: correct answers with methods the class had never been taught, explanations pitched at university level, and no sign the student had learned anything. The platform wanted its own tutor, built around how its courses actually teach, and one that teachers could see into and trust rather than work around.

What had to be true

• Grounded in the syllabus: the same methods, notation and vocabulary as the lessons.
• Teaches, not tells: hints and questions first, with solutions only where the teaching design allows.
• Safe for the age range, on what students type and on what the tutor says.
• Useful to teachers, as insight into misconceptions rather than transcripts to read.
• Affordable at classroom scale, when a whole year group logs in at once.

UNESCO's guidance on generative AI in education calls for data privacy protections, an age limit for independent use and validation of tools for pedagogical and ethical suitability¹. Those became design inputs, not an afterthought: the tutor was designed for supervised use within the platform, with schools in control of access.

Architecture

Grounding followed the retrieval-augmented generation pattern, combining a model with retrieval from a specific corpus², here the platform's own lessons and worked examples filtered by the student's course and unit. See the RAG to production checklist.

The data flow, end to end

The hard part: hinting without leaking the answer

Getting a model to be helpful is easy. Getting it to be helpful in the right way, and to resist a determined student asking for "just the answer" five different ways, is the real work.

• The tutoring policy was explicit and versioned: which exercise types allow worked solutions, how many hints before a fuller explanation, when to ask the student to show their step.
• Teachers authored a misconception library per objective, so hints targeted the likely error rather than repeating the method.
• An output check compared tutor responses against the exercise's answer key to catch leaked final answers.
• Attempts to override the tutor's instructions were treated as expected behaviour, not edge cases; prompt injection is the first entry in the OWASP Top 10 for LLM applications⁴. See prompt injection defence.

How the engagement ran

Key decisions and trade-offs

Tutoring prompts share a long, stable prefix of instructions, policy and lesson context. Prompt caching reuses a processed prompt prefix across requests, so only the changing tail is processed fresh, and any change to the prefix is a cache miss³. Structuring prompts so the stable parts come first made caching effective. Details in prompt caching for cost and latency.

What I'd do again, and differently

Again: write the tutoring policy with teachers before writing prompts, and let teachers grade the test set. Differently: build the teacher dashboard earlier. Seeing where whole classes got stuck changed the content roadmap as much as the tutor.

If you're building AI for learners, the AI architect page describes how I run these engagements, or analyse your challenge and bring the result to a call.