A Safeguarding-Aware Agentic AI Tutor for Montessori-Inspired Personalised Education

This record documents the design and classroom trial of a working AI tutoring system built for adolescents at Blue Blocks Montessori School, Hyderabad, and the architectural argument that follows from it: that personalisation, teacher oversight, and child safeguarding should live inside one auditable pipeline rather than being bolted onto a general-purpose chatbot.

The system runs twelve distinct tutor personalities from a single shared codebase. Nothing is duplicated per child — each student's preference profile and evolving memory record are injected into the same orchestration loop, so the same physics question returns a Hinglish film analogy to one student and a headed, step-by-step derivation to another. The preference vocabulary itself was not written by adults: it was elicited from the students in an earlier co-design study, in which the same cohort designed their own ideal AI teachers and built prototypes of them.

Around that personalisation layer sits the safeguarding machinery. Every student message passes a four-state triage before any model call is made, so distress, bullying, or self-harm signals never reach the tutoring path at all and instead surface as structured alerts to the supervising adult. A second monitoring loop, the Hydra dashboard, gives one teacher a class-wide view of confidence, confusion, frustration, weak topics, homework status, and open alerts without requiring them to read a single transcript.

The paper is deliberate about what it does not claim. The trial was a feasibility exercise with twelve students under a 1:4 adult supervision ratio, not an efficacy study. No learning gains were measured, no baseline comparison was run, and no formal student feedback was collected. The paper states its own boundaries plainly: the triage layer is heuristic rather than clinically validated, it filters student input only and not model output, the dashboard scalars are operational attention cues rather than psychometric measures, and the JSON storage layer is prototype-grade and unfit for child-data processing at scale.

Also documented here: full implementation stack, per-turn control flow with code listings, the memory and reflection update logic, the homework and notification subsystem, and the deployment conditions — school-administered institutional API account, no personal student accounts, on-premises sessions only, adult present throughout.

The architecture is pedagogy-agnostic. Swapping the profile vocabulary, planner action set, and safeguarding thresholds reconfigures it for exam-preparation, narrative-led, or special-needs settings. It is offered as a reference template for schools now deciding how children will work alongside AI tutors.

Personalisation at scale is difficult to achieve in classroom teaching: students differ in pace, prior
knowledge, learning preferences, and emotional disposition, while a single teacher has limited contact time
with each child. Large language models open new opportunities for personalised tutoring, but deploying
them directly with minors raises safeguarding concerns that an unmonitored chatbot does not address.
We present a teacher-monitored agentic AI tutoring prototype that combines per-student personalisation
with classroom-level safeguarding inside a single auditable loop. The preference schema and co-design
methodology build on a companion student-led study in which students designed personalised AI teacher
identities and developed AI tutor prototypes using the Claude API, Python, and Streamlit under facilitator
guidance. In the present system, each student interacts with a tutor configured from their own preference
profile, covering explanation style, humour level, emotional tone, correction handling, response length,
relationship style, and other parameters elicited through a student-guided co-design questionnaire. Every
student message is routed through a four-tier safety triage (green, yellow, orange, red) before any LLM call
is made; wellbeing and safeguarding signals are surfaced on a teacher dashboard, and red-level incidents
are dispatched as a critical-severity SOS. A class-wide monitoring layer, the Hydra dashboard, presents
per-student signals (confidence, confusion, frustration, topic weakness, homework status, and active alerts),
enabling a teacher to monitor many personalised agents from one place. We describe the architecture, the
per-turn flow, the student-agent construction process, the safety and memory layers, the Hydra monitoring
dashboard, and the homework and alerting workflow. The prototype was tested with 12 students aged
12–16 in an AIMS-accredited Montessori classroom, accessed through a school-administered institutional
account and under direct adult supervision throughout. The trial assessed workflow feasibility rather than
learning outcomes. While the prototype was adapted for a Montessori classroom, the proposed architecture
is pedagogy-agnostic and is offered as a reference framework for safe, teacher-monitored AI tutoring across
school environments in which children are increasingly learning alongside AI tutors.

Prepared by the Blue Blocks Micro Research Institute, the research arm of Blue Blocks Montessori School, Hyderabad, India.

Conflict of interest. BBMRI is institutionally affiliated with Blue Blocks Montessori School, the site of this deployment. The prototype was built, deployed, and evaluated in-house. Readers should weigh the feasibility observations accordingly. This work received no external funding.

Child participation and data governance. Twelve students aged 12–16 (grades 7–10) participated during the 2026 academic year. Consent and assent were obtained and records maintained under the institution's child-data management guidelines (CDCS v1.0, DOI: 10.5281/zenodo.19202499) and the Blue Blocks Micro Research Methodology (DOI: 10.5281/zenodo.18584816). Student names, IDs, usernames, email addresses, and on-screen identifiers are masked or blurred in every figure. Students appear as named co-authors with institutional and guardian consent; no identifiable operational data is released.

Model access. All model calls were routed through a single school-administered institutional Anthropic account, with API keys held in server-side secrets under school control. No student held or accessed a personal account with the model provider at any point.

Supervision. Four adults supervised the trial — one principal teacher with an AI background as alert point person, plus three classroom teachers each overseeing four students. Sessions took place on school premises during timetabled hours only. Results characterise the system as operated under close human supervision.

Data availability. Operational data from this prototype — chat logs, memory files, homework records, safety alerts, dashboard signals, and live student profiles — are confidential and withheld. The preference questionnaire and student responses are available separately via Harvard Dataverse (DOI: 10.7910/DVN/PEMXKT). A demonstration repository using synthetic profiles only is at https://github.com/mousam10… and contains no real names, addresses, keys, memory files, or alert logs.

Companion record. This paper extends the student-led co-design study deposited at DOI: 10.5281/zenodo.20373728. Read together, the two records cover the full arc from student-designed AI teacher identities to a safeguarded classroom deployment.

Format. An AI-optimised Markdown version of this paper is published alongside the PDF for machine ingestion. The PDF at this DOI is the canonical Version of Record.