A virtual teacher per subject, that remembers each student

Where it fits

You already know what an agent can do, because you have used one. The problem is not capability. It is that the two shapes on offer are both wrong for teaching.

A general assistant is stateless by design. It is superb at the question in front of it and has no opinion about the student asking. Teaching is the opposite: the value is almost entirely in what carries over between sessions — that this student skips steps under time pressure, that they went quiet on fractions three weeks ago and never came back.

An autonomous agent on its own machine has the memory but arrives with two problems. The cost does not survive contact with a school: one virtual machine per student, times a thousand students, times every school, is a number no parent will accept at the end of the chain. And its strongest capability — driving a computer, running commands — is a liability in a classroom, not a feature. Nothing in teaching a twelve-year-old fractions requires shell access.

What teaching actually needs is narrower and harder: read what a student understands, remember where they are weak, and come back to it. That is a memory and retrieval problem.

How it is put together

Four decisions carry the whole design.

A space per subject. Not a folder — an isolation boundary. Sessions, uploaded files, memory, extracted entities and the teacher's read on the student all carry (student, subject) and are enforced with row-level security in the database. When the English teacher retrieves context, the maths material is not filtered out afterwards; it was never in the result set.

A teacher per subject. Each is an agent with its own persona, its own boundaries, and its own attached knowledge bases. The school's syllabus, lesson plans and worked examples live in a tenant-level knowledge base the whole school shares.

A private knowledge base per student. Separate from the school's. Photographed mistakes, marked homework, the questions they keep getting wrong — uploaded by the student, tagged by topic, retrieved only for them. Encrypted with that student's own key. They can delete it, which matters more here than in most industries.

A profile per teacher, per student. This is the piece that has no equivalent in a general assistant. The maths teacher accumulates its own read on this student; the English teacher accumulates a different one. Exactly as it works in a real school, where each teacher knows a child through their own subject.

That profile shapes how the student is taught — where to slow down, when to praise before correcting. It is deliberately not allowed to rewrite what the teacher may say. A student cannot talk their way into a different teacher over a term of conversations, because the profile layer has no authority over the teacher's identity or its safety boundaries.

Set up by a coding agent, not a console

Schools do not have platform administrators, and your curriculum team should not become one.

The whole configuration surface is exposed over MCP, so your team can point Claude Code — or any MCP client they already use — at the platform and describe the school in prose. It creates the subject teachers, converts syllabus documents into knowledge bases, checks that a given question actually retrieves the right material, and reports what it did.

The material is the work. The data entry is not.

What it does between sessions

The difference between an assistant and a teacher is mostly what happens when nobody is in the room.

Scheduled follow-ups are real background work: persisted in the database, picked up by a poller that survives a restart, and delivered over Telegram, WhatsApp or email. The student does not have to open anything to be reminded that fractions are due for another pass.

Each subject teacher can live in the student's messenger, so revision arrives where they already are.

What this platform does not do

Worth being explicit, because the gaps are the reason the design is affordable.

No computer use. The teacher reads, retrieves, remembers and writes. It does not drive a browser or run commands. In this setting that is a deliberate subtraction.

No assessment engine. Pronunciation scoring, reading-level measurement and similar specialist work belong to tools built for them, connected over MCP as skills the teacher can call. Speech is transcribed to text, which is the right input for a conversation and the wrong input for scoring pronunciation — by the time a mispronunciation reaches the model as text, the transcriber has usually corrected it away.

No mid-conversation redirection. A teacher's boundaries are set in its instructions and hold across the conversation; there is no separate watcher that interrupts a student who has drifted off-topic. Bringing them back is done through what the teacher is told to do, and through the revision schedule.

Because the students are children

Two things follow from the users being minors, and they shape the build rather than decorate it.

The isolation described above is the compliance story: a student's conversations and files are encrypted with their own key, scoped to their own space, and deletable by them. The right to remove your own data is not a feature to be added later.

The second is that students are the most adversarial user population you will ever ship to. Some will try to talk the teacher into saying something it should not, and the one who succeeds will tell the class. The platform filters what the agent says rather than what the student asks — generated text is checked sentence by sentence before it reaches the screen, so a reply that turns harmful is stopped mid-flight rather than retracted after it has been read. Refer to your own review of the boundaries you set; this layer is a floor, not a ceiling.