An AI tutor is not a chatbot with a teaching prompt

Most AI products in education are a general chat model with a system prompt asking it to behave like a tutor. It demos well. It rarely teaches, because tutoring is a discipline with its own craft, and a prompt is a poor place to keep a discipline.

We built OLi Tutor with Olympus Insights, the company Castle co-owns, working as technical co-founders across commercial strategy, product, design and AI engineering. The premise from day one was that the tutoring behaviour had to live in the system itself. This post is about why, and what it means if you are building AI into any specialist product.

A prompt is an instruction, not a capability

A system prompt can ask a model to be Socratic. It cannot make the model remember that a learner struggled with the same concept last week, work out whether today's question is too easy, or decide when a topic should come back for review. Those aren't matters of tone. They are state, measurement and scheduling, and they need somewhere to live that persists between conversations.

So we started by listing what a good human tutor actually does, and treated each item as an engineering requirement rather than an adjective:

• Remembers the learner. Concept-level memory that persists across sessions, so the tutor picks up where the learner is, not where the chat window starts.
• Pitches the work at the right level. Bayesian difficulty calibration, so questions move with what the learner has shown they can do.
• Brings things back at the right time. Spaced repetition scheduling, so review happens when it helps the learner retain it.
• Sees what the learner sees. Real-time screen-share coaching and reasoning over uploaded images, because most learning problems live on a page, not in a sentence typed into a chat box.
• Teaches in a style that suits the learner. Tutor personalities and teaching styles: Socratic, example-led, direct and story-led.

None of these are prompt features. Each one is a component with data behind it, and we built and trained the system that carries them.

Design around the primitives, not the chat box

Once voice, screen share and memory were treated as primitives, the interface followed. OLi is voice-first because tutoring is a conversation. It is screen-aware because the work is on screen. Role play mode lets a learner pick a scenario, set the temperament and difficulty of the other person, and practise the conversation out loud.

Accessibility went in at the same level. ADHD-optimised sessions, dyslexia-friendly interface patterns and CEFR-aligned language tracks were designed from the first sketch, not added once the core product worked. For a tutor, the learners who find standard material hardest are the ones it most needs to serve.

The platform is most of the work

A tutor on its own is a demo. A product needs authentication, onboarding, chat, voice and session management, billing, an admin portal, and analytics that an enterprise buyer will ask about in the first meeting. We sequenced sixteen foundational epics to cover exactly that, so launch did not trip on plumbing.

This is the part most AI prototypes skip, and it is usually why they stay prototypes.

Strategy decided the engineering

The build was hard because the positioning demanded it. Consumer AI tutors compete on interface. Enterprise learning platforms compete on feature count, often by bolting generative AI onto existing infrastructure. OLi competes on teaching.

That thesis only holds if the teaching is genuinely better, and that meant investing in the system rather than the wrapper. It is also what makes the product hard to copy. Anyone can write a prompt. Rebuilding the memory, calibration and scheduling underneath it is a different job.

What this means for your product

You are probably not building a tutor. The lesson carries anyway. If your product depends on a specialist craft, whether that is teaching, triage, case management or compliance, ask where that craft lives.

• If it lives in a prompt, it is fragile, it resets every conversation, and a competitor can copy it in an afternoon.
• If it lives in the system, as data, state and rules the model works within, it compounds. The product gets better at the job the more it is used, and users can feel the difference.

Not every feature needs this depth. A summary button can be a prompt. But if AI is the reason someone chooses your product, the craft needs to be engineered, not described.

Read the full OLi Tutor case study, or see how we approach AI in specialist products.