MentorOS AI

The AI Operating System for Education, autonomous Gemini agents that connect school systems, detect student risk early, coordinate interventions, and measure outcomes

Comment

MentorOS AI

The AI Operating System for Education

Schools already have software. They have learning management systems, student information systems, email, calendars, ERPs, CRMs, collaboration platforms, assessment tools, and increasingly, AI assistants.

But there is still a fundamental problem: none of these systems continuously understands what is happening across the entire institution and acts when something important is happening. A student can stop engaging with the LMS, miss assignments, accumulate absences, and experience declining academic performance — while each signal remains isolated in a different system. By the time someone connects the dots, the opportunity for early intervention may already be gone. MentorOS AI is designed to change that.

What is MentorOS AI?

MentorOS AI is an autonomous intelligence layer for educational institutions.

It does not replace Moodle, Google Classroom, Microsoft Teams, Canvas, academic ERPs, SIS platforms, email, or other institutional systems.

It connects and orchestrates them.

MentorOS continuously transforms fragmented institutional data into educational signals that specialized AI agents can understand.

The core operating loop is:

Observe → Understand → Decide → Act → Follow up → Learn

Instead of waiting for someone to ask a chatbot a question, MentorOS can identify situations that require attention on its own.

Our first product: MentorOS Student Success

We are intentionally starting with one high-impact problem:

early student intervention.

MentorOS Student Success analyzes signals such as:

  • declining academic performance
  • missed or late assignments
  • changes in LMS activity
  • attendance patterns
  • achievement progress
  • historical student behavior

These signals are normalized across institutional systems and evaluated together.

When MentorOS detects a meaningful pattern, an AI agent creates an evidence-based risk case.

The risk assessment then produces an appropriate recommended next step, which can be routed into an intervention workflow.

Institutional policies then decide whether MentorOS can execute the action autonomously or whether human approval is required.

The workflow is designed to follow up on interventions and record their outcomes, allowing the institution to measure what happened after an action was taken.

The objective is not simply to predict that a student may struggle.

The objective is to help the institution intervene while there is still time to make a difference.

A different approach to educational AI

Most educational AI products start with a conversation:

"Ask the AI something."

MentorOS starts with an event.

A student misses assignments.

Learning activity falls.

Academic performance changes.

MentorOS notices.

No prompt is required.

This distinction is central to our product thesis:

the next generation of educational software will not only assist humans when asked — it will continuously operate alongside them.

Human-controlled autonomy

Autonomy in education requires trust.

MentorOS therefore uses explicit autonomy levels and institutional policies.

The architecture supports progressive autonomy.

Low-risk actions can eventually be authorized for automatic execution.

Sensitive actions can require explicit human approval.

Some actions remain completely restricted.

In the current validation environment, sensitive external actions are not autonomously executed.

The architecture follows a simple principle:

AI proposes or decides. Policy authorizes. Tools execute only within approved boundaries. Everything is audited.

This allows institutions to increase autonomy progressively rather than handing uncontrolled authority to an AI model.

How we are building it

MentorOS uses a vendor neutral domain model so agents reason about educational concepts rather than the internal database structure of a particular platform.

For example:

A Moodle record may become: 'AssignmentMissed'

An academic-system record may become: 'AcademicPerformanceDeclining'

An attendance record may become: 'AttendancePatternChanged'

The agents reason over these normalized signals.

This allows MentorOS to eventually understand a student across Moodle, Canvas, Google Classroom, Microsoft systems, ERPs, SIS platforms, and other data sources without coupling its intelligence to one vendor.

Our current architecture combines:

  • Gemini for contextual reasoning
  • an event driven institutional signal layer
  • deterministic analytics for objective indicators
  • AI reasoning for contextual interpretation
  • policy controlled intervention workflows
  • auditable agent execution records
  • FastAPI for the backend
  • Next.js and React for the product interface

The current validation build runs as a modular application with a persistent AI Execution Ledger.

We deliberately use deterministic software where deterministic software is better.

Gemini is used where reasoning, context, ambiguity, or decision-making creates real value.

Why Gemini?

Gemini is not being added as a text-generation feature.

It is part of the decision layer of MentorOS.

The StudentRiskAgent uses Gemini to interpret combinations of educational signals, evaluate context, explain supporting evidence, and recommend an appropriate next step.

The long-term goal is for Gemini-powered agents to become an operational workforce that can coordinate complex educational workflows across multiple systems.

AI-native operations

We believe the company building an AI workforce should itself operate through AI.

MentorOS AI is therefore also being designed as an AI-native company.

Our internal agent roadmap includes:

  • Founder Intelligence
  • Sales
  • Customer Success
  • Product Intelligence
  • Finance
  • Engineering Operations

The first internal agent will produce operational founder briefings, analyze company signals, recommend priorities, and progressively execute authorized business actions.

Every important agent execution can be logged so we can measure where AI is actually operating the company rather than simply claiming that it does.

What is running today

During the hackathon, we deployed a working validation instance of MentorOS and executed a real Gemini-backed StudentRiskAgent workflow using synthetic educational data.

The agent used Gemini 3.1 Flash Lite to evaluate a structured student context and produced:

  • risk type: ACADEMIC_DECLINE
  • severity: MEDIUM
  • confidence: 0.85
  • execution status: SUCCEEDED
  • latency: 3,073 ms
  • total token usage: 1,709 tokens

The execution was persisted in the MentorOS AI Execution Ledger, exposed through the backend API, and rendered in the AI Operations Center.

The current validation environment uses synthetic student data. Sensitive external actions are not autonomously executed, and no production student data was used for this Gemini verification.

Real-world validation

We have access to a real K-12 educational environment in Colombia where MentorOS can be tested against actual institutional systems and educational workflows.

Our first validation strategy has two stages.

Historical backtesting

Our next validation stage is historical backtesting.

MentorOS is designed to analyze historical Moodle and academic information using only data that would have been available at a particular point in time.

We can then compare early detections with outcomes that occurred later.

This will allow us to measure whether MentorOS could have identified meaningful warning signals earlier.

Live Shadow Mode

MentorOS will then monitor a defined real student cohort.

Initially, the system recommends interventions while academic staff validate its detections.

This enables us to measure:

  • validated risk detections
  • false positives
  • previously unidentified cases
  • intervention acceptance
  • time from detection to action
  • subsequent outcomes

Once a workflow demonstrates sufficient reliability, selected low-risk actions can move from recommendation to policy-controlled autonomous execution.

The challenge

The hardest problem is not calling an LLM.

The hardest problem is building a trustworthy system capable of reasoning across fragmented educational information while preserving:

  • student privacy
  • institutional policies
  • explainability
  • auditability
  • human oversight
  • data isolation
  • reliable identity resolution across systems

Educational institutions cannot accept autonomous systems that behave as black boxes.

Every important MentorOS decision must therefore answer:

What happened?

What evidence was used?

Why did the agent make this decision?

What policy authorized the action?

What happened afterward?

What we are learning

One of our most important lessons is that autonomous AI should not mean replacing every deterministic rule with an LLM.

A reliable agentic system combines:

data + deterministic signals + contextual reasoning + policies + tools + humans

We are also learning that the strongest long-term advantage will not come from prompts or access to an AI model.

Those are increasingly commoditized.

Our defensibility must come from understanding how educational institutions operate and, over time, learning:

which interventions work, for which situations, under which conditions.

The long term vision

Today we are starting with Student Success.

But student intervention is only the first closed-loop workflow.

The same operating architecture can eventually support:

  • academic operations
  • teacher productivity
  • family engagement
  • admissions
  • enrollment
  • administrative operations
  • institutional intelligence

Our long term goal is not to build another application that educators must constantly operate.

It is to create an intelligent operational layer working continuously across the systems they already use.

MentorOS AI

Detect early. Decide intelligently. Act responsibly. Measure outcomes.

The AI Operating System for Education.

Share this project:

Updates