Inspiration
College communication does not arrive in one place. It is scattered across Gmail, Google Classroom, WhatsApp groups, files, and last-minute notices. The problem is not just volume—it is that some messages are compulsory, time-sensitive, and easy to miss: registrations, lab records, attendance forms, polls, deadlines, and reminders.
At the same time, students receive question banks, unit notes, and assignment prompts without a clear way to decide what deserves attention first. I wanted to build something that treats student attention as limited and valuable.
“Triage” comes from the medical practice of sorting incoming cases by urgency. The same idea fits student communication: identify what needs action now, what is useful for study, and what is just noise.
What it does
Triage is a local-first AI student desk that turns scattered academic communication into clear next steps.
It can ingest pasted notices, uploaded text files, Gmail messages, Google Classroom announcements/coursework, and representative WhatsApp-style demo messages. Each item is classified into one of three categories:
- Obligation — deadlines, registrations, forms, mandatory notices, and polls.
- Study Material — question banks, unit notes, and academic material.
- Noise — messages that do not require action or study.
For obligations, Triage extracts explicit deadlines, identifies whether something is mandatory, groups work into Immediate, This Week, and Later, and shows it in an Action Queue.
For study material, Triage compares question-bank material with unit notes and produces a ranked study outline. Assignment help is intentionally scaffolded: it breaks work into requirements, concepts, an approach, and test cases, without generating a ready-to-submit answer.
Triage also includes a Human Review drawer. Nothing is sent or submitted externally. For completion polls and routine forms, it can draft an editable response such as “YES, completed,” but the student must copy it themselves. Approving an action only changes its status inside Triage.
How we built it
Triage is built as a web application with a Python/FastAPI backend, SQLite persistence, and a custom HTML/CSS/JavaScript frontend.
The backend uses the OpenAI API with structured JSON outputs to classify messages as Obligation, Study Material, or Noise, while extracting deadlines, mandatory status, and poll/form patterns. A separate study-planning flow ranks recurring topics from uploaded question-bank and unit-note text.
Google integrations use read-only OAuth for Gmail and Google Classroom in the local setup. Uploaded text files are preserved locally so the original source material can be revisited. WhatsApp is represented by clearly labelled simulated group messages in the demo rather than an unreliable live bridge.
The frontend is designed as a student command desk: a pulse-inspired navigation rail, Action Queue, ranked study cards, compact detail dialogs, deadline reminders, an Approval Drawer, light/dark/system themes, and reduced-motion support.
I used Codex as my primary engineering collaborator throughout the project: implementing backend flows, iterating on UI behavior and navigation, auditing bugs, testing the local demo flow, and refining the project into a deployable experience. The frontend is deployed on Vercel and the FastAPI backend is deployed on Railway, while the local demo remains the most reliable environment for OAuth-backed source connections.
Challenges we ran into
The hardest problem was not classification alone—it was making the product trustworthy.
A student-assistant tool can easily become unsafe or misleading if it silently submits forms, sends group replies, or invents personal data. I had to draw a clear boundary: Triage can identify, prioritize, and draft, but it cannot act externally without the student.
Google OAuth also introduced practical complexity. Gmail and Classroom need correct scopes, valid local tokens, and careful handling of deployment differences. The local version supports the intended read-only connection flow, while the hosted version is designed around a shared demo experience rather than pretending every personal integration is production-ready.
WhatsApp was another deliberate challenge. A real group integration would depend on unofficial tooling and fragile sessions, so I chose an explicit simulated WhatsApp datasource for the demo. That kept the core experience stable and made the limitation visible rather than hidden.
Finally, turning a dense dashboard into something usable required multiple UI iterations: horizontally navigable panels, reliable keyboard and arrow navigation, compact obligation cards, readable detail dialogs, and an approval flow that makes the human decision unmistakable.
Accomplishments that we're proud of
- Built a working end-to-end student triage flow: ingest, classify, persist, prioritize, review.
- Implemented structured AI classification with categories, deadlines, mandatory status, and poll/form detection.
- Built a human-in-the-loop Approval Drawer instead of automating external submissions.
- Added editable, copy-only drafts for completion polls and simple forms.
- Created a ranked Study Plan that focuses on structure and priorities rather than generating academic answers.
- Added an Assignment Scaffolding Assistant that helps students plan work without completing it for them.
- Implemented Gmail and Google Classroom sync paths with read-only OAuth for the local workflow.
- Added file upload archiving for uploaded text material.
- Built a polished, responsive dashboard with a custom pulse rail, urgency grouping, deadline reminders, themes, and reduced-motion support.
- Deployed the frontend and backend while retaining a dependable local demo path.
- Prepared believable, explicitly simulated demo data so the product can be demonstrated without exposing personal messages.
What we learned
We learned that useful student automation is less about doing everything automatically and more about making the right information visible at the right time.
Structured outputs matter. Asking an AI model for a label is not enough; the application needs reliable fields for category, deadline, requirement level, reasoning, and safe handling of uncertainty.
We also learned that “human in the loop” has to be visible in the product, not just stated in documentation. The Approval Drawer, editable drafts, and no-send boundary are central to the experience because they make the student’s control concrete.
Finally, we learned that honest product scope improves a demo. Simulated WhatsApp data is better than claiming a fragile live integration, and a local OAuth workflow is better than presenting a hosted connection as complete when it still needs per-user production authorization.
What's next for Triage
Next, Triage will move from a strong demo into a fuller multi-user product:
- Per-user hosted Google OAuth instead of local demo tokens.
- Durable hosted storage replacing local SQLite for production accounts.
- Real, permissioned source synchronization with clearer connection health and retry handling.
- Attachment ingestion and archiving beyond uploaded text files.
- Safer notification and reminder workflows.
- A production-ready WhatsApp integration path, only if it can be made reliable and policy-compliant.
- More robust routine-form assistance using user-provided profile information, always staged for review and never auto-submitted.
- Better source-level filtering, search, and an archive/history view.
- Accessibility and mobile refinements for students using Triage as a daily tool.
The core principle will remain unchanged: Triage can organize attention and draft the next step, but the student keeps control of every real-world action.
Log in or sign up for Devpost to join the conversation.