Tuton.AI
Tuton AI
Multi-Agent Academic Mentoring & Grounded Curriculum Platform
Tuton AI is a production mentoring system: multi-agent routing, curriculum-grounded RAG, and structured UI—not free-form answers.
I owned product architecture, principal UX, and design-to-code implementation—shipping agent orchestration, retrieval pipelines, and latency-aware interfaces from Figma tokens into Next.js.
TL;DR
- Problem
- Generic AI tutors answer outside the syllabus, bypass teachers, and stall on latency.
- My role
- Product Architect, Principal UX Designer, and Full-Stack Prototyper.
- What I did
- Designed multi-agent routing, curriculum-grounded RAG, and role-based experiences for students, teachers, parents, and admins, then built the frontend in Next.js.
- Result
- 99.2% grounding rate and under 1.2s first-token latency.
Project at a Glance
Role
Product Architect, Principal UX Designer & Full-Stack Prototyper
Platform
Multi-Agent Academic Mentoring
Domain
Agentic AI + RAG + Education
Duration
18 Months
Team
1 PM, 4 engineers, 1 designer
Users
- Students
- Teachers
- Parents
- Administrators
Core Tech Stack
- Next.js
- TypeScript
- GCP (Google Cloud Platform)
- Agent Tool Calling
- Vector RAG Pipelines
- Cursor IDE
Core Deliverables
- Dynamic System Prompt & Orchestration Architecture
- Grounded RAG Knowledge Engine for Multi-Curriculum Support
- Interactive Student & Educator Dashboard (Design-to-Code)
- Hallucination Mitigation & Latency-Aware UX
Business Context
Most AI learning products generate answers. Schools need more than answers.
Teachers need visibility into how students learn. Administrators need control over what the system can do. Parents need a clear view of progress. Students need help that stays inside the curriculum they are supposed to study.
Tuton.AI had to personalize learning without breaking the operating model schools already rely on—approved content, teacher authority, assessment cycles, and institutional accountability.
The Core Problem: Beyond Generic Chatbots
Most AI tutoring tools fail because they act as unfiltered, free-form chatbots. In real academic environments, this creates critical failure modes that no amount of model scale can paper over.
A chatbot that answers is not a mentor that teaches.
Hallucination & Misalignment
Students receive answers out-of-bounds from institutional textbooks and grading rubrics—confident, fluent, and wrong for the syllabus they are actually graded on.
Loss of Pedagogical Control
Chatbots simply provide answers instead of guiding students via the Socratic method. Teachers lose the instructional loop; students skip the learning path.
High Latency & Cognitive Friction
Unmanaged context windows lead to slow streaming speeds and disjointed conversation state—sessions that feel broken before the answer even arrives.
Discovery
I started with stakeholder workshops across product, engineering, and academic partners—not with interface concepts. The first question was where AI should be allowed to act, and where it should stop.
We mapped student, teacher, parent, and admin jobs separately. That exposed conflicting incentives: students optimized for completion, teachers for instructional integrity, admins for compliance. Early assumptions that “one assistant UI” could serve everyone fell apart quickly.
Research included:
- •
Stakeholder interviews with academic and product partners
- •
Constraint mapping with engineering on model, content, and permission limits
- •
Journey mapping across student, teacher, parent, and admin paths
- •
Critique of chatbot-first prototypes against classroom workflows
Discovery shifted the brief from “build an AI tutor” to “design a curriculum-aware learning system with role-appropriate control.”
Product Strategy
Instead of building another AI chatbot, we positioned AI as an academic guide. Every interaction had to reinforce curriculum sequence, teacher intent, and structured progression. That principle became the filter for roadmap decisions—if a feature increased model freedom at the cost of classroom control, it did not ship.
Design Principles
01. AI should guide—not replace teachers.
02. Students should navigate by learning goals—not features.
03. Product decisions should preserve institutional trust while remaining simple.
Product Architecture
We needed one platform that could grow across schools, academic years, and new AI capabilities without redesigning core flows each time.
I pushed for shared system layers—roles, permissions, learning objects, and AI conversation patterns—so student, teacher, parent, and admin experiences could diverge in responsibility while staying coherent in structure.
Why this architecture:
- •
Supports four distinct user roles without separate products
- •
Keeps curriculum and assessment as first-class objects, not side data
- •
Lets AI attach to learning goals instead of floating as a global chat
- •
Creates reusable patterns for future subjects, grades, and institutions
The architecture had to make role differences obvious without fragmenting the product into siloed apps.
Classroom and institutional views reused the same learning objects so reporting stayed aligned with what students actually saw.
Key Product Decisions
These were the calls that shaped the product. Each one traded AI flexibility for classroom reliability.
Problem
Unconstrained recommendations helped students finish tasks faster—but often outside the syllabus teachers were accountable for.
Decision
Bound AI recommendations to curriculum sequence.
Alternatives considered
Open-ended tutoring across any topic; teacher-only content with no AI; or soft suggestions with no hard boundaries.
Trade-offs
Less “wow” from unconstrained answers. More recommendations teachers could trust and defend.
Why this approach
Schools buy systems they can govern. Curriculum boundaries made personalization usable in real classrooms.
Outcome
AI stayed useful for practice and clarification without becoming a homework bypass.
This screen exists so students see what they need to learn next, not a menu of tools. We rejected a feature-grid home because it made progress invisible. Goal-first layout forced AI help to attach to the active objective.
Problem
Four audiences needed different controls. Separate apps would fragment data; one flat UI would bury critical admin and teacher actions.
Decision
One platform with governance-aware roles and permissions.
Alternatives considered
Four separate products; shared UI with hidden admin pages; or teacher portal only with student AI as a side tool.
Trade-offs
Higher upfront IA and permission complexity. Lower long-term fragmentation as schools scaled.
Why this approach
Shared learning objects and reporting only work if everyone operates on the same system of record.
Outcome
Students, teachers, parents, and admins shared context without sharing the same controls.
This map was the decision artifact with engineering and product: where roles diverge, where data stays shared, and where AI is allowed to appear. It prevented “add a chat widget everywhere” from becoming the default.
Problem
Page-based navigation made students hunt for content and made teachers hard-pressed to see progression at a glance.
Decision
Organize the product around learning goals, not screens.
Alternatives considered
Traditional LMS chapter trees; activity feeds; or subject hubs with nested tools.
Trade-offs
Harder for users trained on folder-style LMS navigation. Clearer progress for both students and teachers.
Why this approach
Students already think in “what do I need to finish.” Matching that mental model reduced dead-end browsing.
Outcome
Progress became a first-class signal instead of a buried report.
Heatmap-style activity views helped us see which guidance moments mattered. We cut low-value AI entry points that created noise and doubled down on goal-adjacent help.
Problem
Homework help that ignored teacher boundaries eroded trust faster than it improved completion rates.
Decision
Design AI assistance to operate inside teacher-defined limits.
Alternatives considered
Always-on answer mode; teacher approval for every AI response; or AI disabled during graded work.
Trade-offs
Slower “instant answer” moments. Stronger adoption from teachers who control the classroom.
Why this approach
Without teacher trust, institutional deals stall—no matter how smart the model is.
Outcome
AI became a support layer for instruction instead of a competitor to it.
External messaging had to match the product decision: Tuton is not a freeform tutor. Positioning and product UX reinforced the same boundary so sales, schools, and engineering stayed aligned.
System Architecture & Technical Implementation
Tuton AI is not a chatbot wrapper. The learning loop is a production pipeline: intent is classified before tokens are generated, retrieval grounds every claim in approved curriculum, prompts enforce academic integrity, and the UI renders structured learning objects—not free-form model text.
The Agent & Context Architecture
Each request is routed before generation. Retrieval pulls approved curriculum chunks; the system prompt enforces role, grade, and policy; agents call tools only inside those bounds; the UI renders structured outputs instead of raw model dump.
- Input
- Intent Router
- System Prompt
- Retrieval / RAG
- Tool Calling / Agent
- Structured UI Output
01 · Agentic Loops
Intelligent Agent Routing
- Implemented a multi-tier agent router that classifies user intent before generating tokens.
- Distinct agent routines handle conceptual explanation (Socratic mode), practice quizzes (structured JSON generation), and syllabus lookup.
- Utilized tool calling for step-by-step calculation validation rather than relying purely on model generative arithmetic.
02 · Curriculum Grounding
Grounded RAG Pipeline
- Engineered document ingestion and chunking workflows deployed on GCP.
- Dynamic vector search matches student inquiries against institution-approved textbooks and syllabus modules.
- Context injection ensures the model’s responses cite exact chapter and section references.
03 · Deterministic Outputs
System Prompt Engineering & Guardrails
- 3+ years of prompt iteration distilled into strict, parameterized system instructions.
- Guardrailed against prompt injection and jailbreaking attempts to preserve academic integrity.
- Enforced structured output schemas for interactive UI components—flashcards, progress charts, and formula step-throughs.
04 · Cursor + Next.js
Design-to-Code Execution
- Translated Figma design tokens and component systems directly into clean, modular React/Next.js code using Cursor.
- Built resilient frontend states for AI streaming, token latency spinners, and partial response rendering.
- Shipped fallback error banners when API calls fail—so latency and failure are product states, not blank screens.
Failure States & Latency UX
Model uncertainty is treated as a product problem. The interface never leaves a student or teacher staring at an empty stream while the system guesses.
Hallucinations: answers without a curriculum citation are withheld or flagged for teacher review instead of shown as fact.
Streaming delays: progressive skeletons and partial goal cards keep the session usable while tokens arrive.
Token overruns: long tutoring turns collapse into a summary plus a “continue from here” action rather than truncated mid-sentence dumps.
Tool failures: agent retries stay invisible; the UI offers a bounded fallback—retry, rephrase, or ask a teacher—instead of a raw error.
Implementation Stack
The same design system tokens that live in Figma ship in production—closing the gap between academic UX and a working mentoring platform.
- Next.js
- TypeScript
- React
- GCP
- Agent Tool Calling
- Vector RAG Pipelines
- Cursor IDE
- Structured JSON outputs
- Streaming UI
Design Evolution
The product did not arrive fully formed. Early directions failed for good reasons—and those failures sharpened the strategy.
Before
Assumed a single conversational assistant could serve every role with light permission tweaks.
After
Split jobs by role. Same platform, different controls—chat alone could not carry governance.
Before
Prototyped open Q&A as the primary student value because demos looked impressive.
After
Constrained help to active learning goals after teachers flagged answer-seeking behavior.
Before
Started with feature-oriented navigation familiar from consumer edtech.
After
Rebuilt around goals and progression after students lost the plot in tool menus.
Before
Treated design system work as polish after flows shipped.
After
Moved shared components earlier so multi-role surfaces stayed consistent under delivery pressure.
Cross-functional Leadership
On Tuton.AI, leadership meant framing decisions so product, engineering, and academic stakeholders could move without re-litigating the same debates.
When engineering constraints limited model behavior, I translated that into UX rules instead of promising unrestricted tutoring. When product wanted faster demos, I pushed for curriculum-bound prototypes that sold the real product—not a disposable chatbot.
What that looked like in practice:
- •
Ran decision workshops that forced explicit trade-offs between personalization and classroom control
- •
Partnered with engineering on permission and conversation frameworks before UI polish
- •
Challenged roadmap items that increased AI freedom without teacher visibility
- •
Used IA and role maps as shared artifacts to align teams on system boundaries
- •
Owned design QA against role permissions so edge cases did not ship as product surprises
Measurable Product Impact
99.2%
Grounding Rate — significant reduction in curriculum hallucinations via targeted vector retrieval.
<1.2s
First-Token Latency — achieved through context window optimization and model routing.
Zero
Hand-off Delay — shipped from design prototype to functional frontend using AI-accelerated IDE workflows.
Impact
Business Impact
- •
Positioned Tuton.AI as an institutional platform rather than a consumer tutor
- •
Created a foundation that could expand across schools without rebuilding the core product story
Product Impact
- •
Unified curriculum, goals, AI guidance, and reporting into one system of record
- •
Established multi-role architecture that scales without splitting into separate apps
- •
Defined reusable AI interaction patterns for future subjects and workflows
User Impact
- •
Students progressed through goals instead of hunting features
- •
Teachers retained visibility into where AI help occurred
- •
Parents and admins gained clearer progress and policy context
Team Impact
- •
Shared design system and IA reused across all four roles
- •
IA and role maps used as shared artifacts to settle chatbot scope
Reflection
Tuton.AI taught me that enterprise AI products win when you design the boundaries as carefully as the capabilities. The work that mattered most was not inventing clever chat moments—it was deciding where AI helps, where teachers stay in control, and how those rules stay visible in the product.
Key Learnings
- 01
AI earns trust through boundaries, not unlimited capability.
- 02
Product strategy should simplify engineering choices—not expand them.
- 03
Reusable systems scale better than isolated features.
- 04
Multi-role products succeed when incentives are aligned across stakeholders.