EduPilotPro is App Corp's production AI school operating system — a multi-tenant platform serving schools across 3 continents with 6 specialized AI agents. It is not a concept or a prototype. It is a production system handling real attendance, real fee collection, real admissions, and real parent communication for real schools. This article explains the architecture decisions, technology choices, and lessons learned from building and operating a school OS at scale.
Architecture Overview
EduPilotPro's architecture has five layers: (1) Integration layer: connects with existing school systems — SIS (Student Information Systems), LMS (Learning Management Systems), payment gateways, and communication platforms. Uses Supabase for database, auth, and real-time subscriptions. (2) Data layer: Supabase PostgreSQL with Row Level Security for tenant isolation. FHIR-inspired resource models for student data (Student, Enrollment, Attendance, Grade, Fee). Real-time subscriptions for live attendance and communication. (3) AI layer: 6 specialized AI agents — attendance, admissions, fee collection, parent communication, academic, and scheduling. Each agent operates within role-based permission boundaries. (4) Application layer: Next.js web application for administrators and teachers, React Native mobile app for parents. Shared component library for consistent UI. (5) Infrastructure: Supabase for database and auth, Vercel for web hosting, Expo for mobile, Stripe for payments. Serverless architecture for cost efficiency at education price points.
Note
EduPilotPro serves schools across 3 continents — the architecture must accommodate different attendance policies, fee structures, grading systems, and communication preferences per school.
Multi-Tenancy Design
Multi-tenancy in EduPilotPro: (1) Tenant isolation: Supabase Row Level Security ensures each school's data is isolated. Policies enforce that school administrators see only their school's data, parents see only their children's data, and teachers see only their classes. (2) Configurable policies: each school configures its own attendance policies (thresholds, notification rules), fee structures (currency, payment plans, late fees), grading systems (letter grades, percentages, GPA), and communication preferences (email, SMS, WhatsApp). (3) Role hierarchy: Student → Parent → Teacher → School Admin → Network Admin → Super Admin. Each role has specific data access and action permissions. (4) Data residency: for schools in different regions, student data may need to stay within national borders. Supabase's multi-region deployment supports this requirement. (5) Tenant-specific AI: AI agents are configured per school. The Attendance Agent uses different detection methods for different schools (face recognition for secondary, QR for primary).
AI Agent Implementation
EduPilotPro's 6 AI agents: (1) Attendance Agent: processes attendance via face recognition, geofencing, or QR codes. Detects patterns (chronic absenteeism, sudden changes) and generates parent notifications. (2) Admissions Agent: processes application documents, verifies eligibility against school criteria, and communicates application status. (3) Fee Collection Agent: sends payment reminders at optimal times, tracks payment status, calculates late fees, and generates financial reports. (4) Parent Communication Agent: generates personalised progress reports, attendance notifications, and event reminders. Handles parent inquiries with escalation to human staff. (5) Academic Agent: tracks student performance, generates report cards, identifies at-risk students, and recommends interventions. (6) Scheduling Agent: manages teacher schedules, substitute assignments, room allocation, and event scheduling. Each agent has defined inputs, outputs, quality thresholds, and human escalation paths.
Lessons Learned
Key lessons from building and operating EduPilotPro: (1) Configurability is king: different schools have different policies. The system must accommodate them without code changes. Invest heavily in configuration tooling. (2) Offline support matters: schools in regions with unreliable internet need offline-capable features. Implement local-first data sync. (3) Parent adoption is the bottleneck: the best school system fails if parents do not use it. Invest in parent onboarding, mobile apps, and multi-channel communication. (4) AI features should be optional: the base product must work without AI. AI enhances, not replaces, the core platform. Schools should be able to turn off AI features if they prefer manual processes. (5) Data migration is expensive: schools have existing data in spreadsheets, legacy systems, and paper records. Provide migration tools and support. (6) Local language support is essential: schools across different regions need multi-language interfaces. This is not translation — it is cultural adaptation.
Conclusion
EduPilotPro demonstrates the architecture for AI school operating systems: multi-tenant with configurable policies, 6 specialized AI agents, Supabase-based data layer, and Next.js/React Native application layer. The key lessons: configurability is king, offline support matters, parent adoption is the bottleneck, and AI features should be optional.
Key Takeaways
- Architecture: integration layer → data layer (Supabase RLS) → AI layer (6 agents) → application layer (Next.js + React Native) → infrastructure
- Multi-tenancy: Supabase RLS for isolation, configurable policies per school, role hierarchy, tenant-specific AI configuration
- 6 agents: attendance, admissions, fee collection, parent communication, academic, scheduling — each with defined inputs/outputs/thresholds
- Lessons: configurability is king, offline support matters, parent adoption is the bottleneck, AI features optional, data migration is expensive
- Production-proven: serving real schools across 3 continents with real attendance, fees, admissions, and communication