Inspiration

About CampusFlow

Inspiration

As students, we deal with information coming from different places, such as learning management systems (LMS), emails, department announcements, and calendars. Sometimes, a deadline changes in one place but remains the same somewhere else. Students then have to manually check multiple sources, figure out which information is reliable, and reorganize their study plans.

We realized that the real problem is not just managing deadlines. It is understanding what has changed, why it matters, and what to do next.

This inspired us to build CampusFlow — an ambient AI academic copilot that turns scattered academic information into clear, evidence-backed actions.

What it does

CampusFlow brings academic information into one workspace and helps students move from information to action.

Its key capabilities include:

  • Academic Memory: Organizes academic records, courses, deadlines, announcements, and source information.
  • Change Radar: Detects changes and compares information across sources. When two sources disagree, it preserves both claims and flags the conflict instead of guessing the correct answer.
  • Personalized Context: Uses relevant academic information and student availability to provide more useful recommendations.
  • Voice, Chat, and Dashboard: Gives students different ways to ask questions, inspect evidence, and understand academic updates.
  • Study Planning: Proposes study plans and possible actions based on deadlines and available time.
  • Human-Controlled Actions: Requires user approval before permitted calendar changes and keeps an auditable record of important actions.

Our main goal is to make academic information more reliable, understandable, and actionable without taking control away from students.

How we built it

We designed CampusFlow around a layered architecture that separates the student experience, application logic, AI orchestration, tool access, and data connections.

The planned technology stack includes React and TypeScript for the frontend, FastAPI for the application backend, PostgreSQL for academic records and evidence, and a self-hosted Model Context Protocol (MCP) server for controlled tool access.

The architecture also plans integrations with LMS data, Gmail, and Google Calendar. Through typed tools, the system can retrieve upcoming deadlines, search authorized academic messages, compare notice versions, check calendar availability, and propose study plans.

We designed safeguards into the workflow. Academic information should retain its source, timestamps, and version history. Conflicting claims should remain visible rather than being silently overwritten. Actions that affect external systems should require authorization, approval where applicable, and verification of the actual result.

For the demonstration, our blueprint specifies deterministic sample LMS data with seeded changes, allowing us to test deadline conflicts without depending entirely on live integrations. The pitch also identifies synthetic demo data as a fallback if OAuth setup is delayed.

Challenges we considered

One of the biggest challenges was designing a system that does more than simply return an AI-generated answer.

For example, if the LMS lists a deadline as October 28 but an email lists October 30, automatically selecting one date could mislead a student. CampusFlow is designed to preserve both pieces of evidence, identify the conflict, and request verification rather than inventing a resolution.

Another challenge was balancing automation with user control. An AI assistant may recommend a useful study schedule, but it should not make external changes without the appropriate permission. This led us to separate recommendations, approvals, execution, and verification into distinct stages.

We also had to consider practical integration issues, including expired authentication tokens, stale information, provider failures, time zones, duplicate actions, and maintaining a reliable history of changes.

These are important engineering challenges that our architecture and proposed testing plan are designed to address.

What we learned

Working on CampusFlow helped us understand that building a useful AI application involves much more than connecting a language model to a chat interface.

We learned to think about data reliability, source attribution, version history, tool permissions, human approval, and failure handling as core parts of the product. We also explored how MCP can provide a structured bridge between an AI application and the tools it is allowed to use.

Most importantly, we learned that useful AI should not hide uncertainty. When information conflicts or an action fails, the system should make that clear instead of pretending everything is correct.

What's next

Our next steps are to implement and test the core workflow, strengthen the academic memory layer, integrate authorized Google services, and validate the MCP server's security and reliability.

We also plan to evaluate the system against measurable acceptance targets, including correct identification of seeded deadline changes, source-backed answers, safe handling of unresolved conflicts, and zero unauthorized writes in authorization tests. These are proposed targets, not results we are claiming to have achieved.

Our vision

CampusFlow is built around one simple idea: students should spend less time searching for academic information and more time learning.

By connecting academic memory, evidence-backed intelligence, and controlled actions, we want to make everyday student life clearer, more organized, and less stressful.

CampusFlow — Make Every Academic Change Actionable.

Team: Quantum Burner 2.0

Built With

  • ai-agents
  • artificial-intelligence
  • fastapi
  • gmail-api
  • google-calendar-api
  • large-language-models
  • model-context-protocol-(mcp)
  • oauth-2.0
  • postgresql
  • python
  • react
  • rest
  • typescript
Share this project:

Updates

Submission history