How a K12 provider would give every student a teacher per subject
A worked example of an education company building its own teaching product on agent4.io — a virtual teacher per subject per school, each student's weak points accumulating in a space only they can reach, and revision that arrives on a schedule instead of waiting for the student to open the app.
The starting point
In this scenario the company sells to schools, and the schools ask for the same thing every year: something that helps students revise between lessons. The company has already tried the two obvious routes and rejected both.
A general assistant answers well and remembers nothing. A student explains where they are stuck, gets a good answer, closes the tab, and next week starts from zero. The product would be a search box with better manners.
An autonomous agent per student solves the memory problem and creates a worse one. Giving each student their own machine multiplies by a thousand students per school, and the number that reaches the parent at the end of the chain is not a number a parent pays. The company's founder had also noticed something subtler: the capability those agents are proudest of — driving a computer, running commands — is not wanted here. Teaching a twelve-year-old fractions never requires shell access, and in a school it is a liability to be explained rather than a feature to be sold.
What is actually needed is narrow: read what the student understands, remember where they are weak, and come back to it later.
What gets deployed
- A space per subject, per student. Maths and English are separate boundaries, not folders.
Sessions, files, memory and the teacher's read on the student carry
(student, subject)and are enforced with row-level security, so the maths history is never retrieved into an English session. - A teacher per subject. Each is an agent with its own persona and boundaries, attached to the school's tenant-level knowledge base — syllabus, lesson plans, worked examples — which the whole school shares.
- A private knowledge base per student. Photographed mistakes, marked homework, the questions they keep getting wrong. The student uploads their own, tags by topic, and can delete it. Encrypted with that student's own key.
- Scheduled revision. The teacher schedules a return to a weak topic, and the reminder is delivered over Telegram or email whether or not the student opens anything.
- Configuration over MCP. The curriculum team points Claude Code at the platform and describes the school in prose; it creates the teachers, converts the syllabus into knowledge bases, and checks that a question actually retrieves the right material.
How the pieces map to what a school actually asks for
This is the part that decides whether a pilot survives contact with a head of department.
"Will it mix up my subjects?" — This is the first question, and it is usually asked because a previous tool did. Isolation is the space boundary, enforced in the database rather than requested in a prompt. The English teacher does not filter maths material out of its results; the material was never in the result set.
"Will it know my students?" — The profile is held per student, per subject, per teacher. The maths teacher accumulates its own read — hesitant with word problems, skips steps under time pressure — and the English teacher accumulates a different one, exactly as two human teachers would. It is worth being precise about what this is: the profile shapes how a student is taught, and has no authority to change what the teacher may say. A student cannot argue their way into a different teacher over a term.
"Who has to maintain it?" — Schools do not have platform administrators, and a curriculum team should not become one. Because the whole configuration surface is exposed over MCP, the company's own staff drive setup from a coding agent they already use. Writing the material is the work; the data entry is not.
"What happens between lessons?" — This is where an assistant and a teacher actually differ. Scheduled follow-ups are background work that survives a restart and reaches the student where they already are, so revision does not depend on a twelve-year-old remembering to open an app.
What the company still builds itself
Worth stating plainly, because the boundary is what makes the estimate honest.
Pronunciation scoring and reading-level assessment are specialist tools, connected over MCP as skills the teacher calls. Speech reaching the platform is transcribed to text — the right input for a conversation, the wrong input for scoring pronunciation, since a transcriber generally corrects the mispronunciation away before the model ever sees it.
Reports for parents and teachers need a schema of their own. The platform exports structured documents, but its built-in shape is a consultation memo, not a progress report, and there is no parent-facing delivery path — that is product work on the company's side.
The lesson interface is theirs too. The platform runs the teaching relationship underneath.
Because the students are children
Two consequences shape the build rather than decorate it.
The isolation above is also 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 exists before anyone asks for it.
And students are the most adversarial users this company will ever ship to. Some will try to talk the teacher into saying something it should not, and whoever succeeds will tell the class by lunchtime. 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. Against a set of hand-written probes it stopped every operational sample while leaving legitimate coursework untouched, including a health lesson on what methamphetamine does to dopamine and a biology answer about therapeutic windows. That is a floor, not a ceiling, and it does not replace the school's own review of what its teachers are told to do.
Why this shape is affordable
The cost argument is the whole reason the design looks like this.
There is no machine per student. Students share model capacity, and what a school pays scales with conversation rather than with provisioning. The subtraction is deliberate: no computer use, no assessment engine, no autonomous task execution. Each of those is capability the company does not pay for and does not have to explain to a parent.
Illustrative scenario. This is a composite example built from the workflows agent4.io supports, not a report on a named customer deployment. It is provided to show how the product is used; it is not a claim of results achieved. Verified customer outcomes will be published as such once available.
Read the full K12 schools and tutoring solution