DEV Community: Ayush Raj

I Built CampusCopilot — A Personal AI Learning System for College Students

Ayush Raj — Sun, 04 Oct 2026 12:31:13 +0000

I Built CampusCopilot — A Personal AI Learning System for College Students

#devchallenge #weekendchallenge #hf26challenge

Hacktoberfest Weekend Challenge: Build for a Friend 🤝

🚀 CampusCopilot — Your Personal AI Developer Campus

What if your AI didn't just answer your study questions, but actually understood where you were struggling and told you what to work on next?

I built CampusCopilot for a college friend who was struggling with DSA, coding practice, study materials, assignments, and exams.

Instead of building another generic AI chatbot, I wanted to build something that connects the entire learning process:

Study → Practice → Make mistakes → Understand weaknesses → Get a better next step

The result is CampusCopilot — a personal AI learning workspace for college students.

🎯 The Problem

College students often have everything scattered across different places.

Notes are stored in PDFs.

Coding practice happens on different platforms.

Assignments are tracked separately.

Exam dates live in calendars.

And when students use an AI chatbot, the conversation usually doesn't become an actual learning plan.

I wanted CampusCopilot to answer a different question:

"Given everything this student has been doing, what should they do next?"

🧠 The Core Idea

Most AI learning tools follow:

Question → Answer

CampusCopilot tries to create:

Study → Practice → Performance → Weakness → Recommendation → Action

The AI isn't only there to answer questions.

It should help the student decide what to do next.

📸 CampusCopilot in Action

🏠 Dashboard

The dashboard answers:

"What should I do today?"

It brings together:

Next Best Move
Today's Focus
Study time
Topics completed
Quiz accuracy
Coding problems solved
Current streak
Weakest areas
Upcoming deadlines

📚 StudyBuddy

StudyBuddy turns uploaded study material into an interactive learning workspace.

💻 CodeExplain

CodeExplain focuses on understanding bugs instead of simply copying fixes.

📅 Campus Planner

Campus Planner brings exams, assignments and daily tasks into one workspace.

📊 Learning Profile

The Learning Profile turns learning activity into meaningful insights.

🔄 The Learning Loop

This is the core idea behind CampusCopilot:

Study

↓

Practice

↓

Make mistakes

↓

Identify weak areas

↓

Update learning profile

↓

Recommend next action

↓

Practice again

For example, if a student repeatedly struggles with recursion and has low practice accuracy, CampusCopilot can identify it as a weak topic and recommend a focused practice session.

Instead of simply saying:

"Here is an explanation of recursion."

It can say:

"Recursion is currently one of your weakest areas. Spend 35 minutes practicing it."

The goal isn't just to provide an answer.

The goal is to help the student make progress.

📚 StudyBuddy

StudyBuddy turns uploaded study material into an interactive learning workspace.

It provides four learning modes.

🔎 Ask

Ask questions about uploaded study material and retrieve relevant context before generating the response.

👨‍🏫 Teach Me

Learn a concept progressively through:

Simple explanation
Code example
Intuitive analogy
Quick check

🧠 Quiz Me

Practice with questions and track performance.

🆘 I'm Stuck

Get a concept re-framed using different explanations, analogies and problem-solving approaches.

The idea is to make studying interactive instead of simply reading PDFs.

🔎 Grounded Study Assistance

For uploaded study materials, CampusCopilot uses a retrieval pipeline:

PDF → Text Extraction → Chunking → TF-IDF Retrieval → Cosine Similarity → Relevant Context → Llama → Grounded Response

This helps StudyBuddy focus its responses on the student's own uploaded material instead of treating every question like a completely generic chatbot request.

💻 CodeExplain

As a CSE student, one of the most frustrating experiences is getting code that doesn't work and not understanding why.

CodeExplain focuses on teaching rather than simply fixing.

It breaks problems into six stages:

What happened — simple error explanation
Why it happened — underlying programming concept
Where — exact location in the code
How to fix it — clean corrected code
What you should learn — core concept
What you should practice next — targeted practice

It supports:

Python
Java
C++
JavaScript
C

For example, a recursion error isn't treated as just something to patch.

CampusCopilot explains the relationship between the recursive call, the base case and the call stack so the student understands the underlying concept.

"Don't just fix my code. Help me understand why I made the mistake."

📅 Campus Planner

Campus Planner brings exams, assignments and tasks into the same workspace.

Students can manage:

Upcoming exams
Assignments
Daily tasks
Priorities
Deadlines

It also includes Build My Study Plan.

A student can provide:

Available study hours
Subjects
Exam dates
Confidence levels

CampusCopilot can then generate an intelligent, time-blocked study plan.

📊 Learning Profile

The Learning Profile turns learning activity into something meaningful.

It tracks:

Study time
Quiz accuracy
Coding problems solved
Topics mastered
Weak topics
Current streak
Learning progress

Instead of showing only activity numbers, the profile helps answer:

"What am I good at?"

"Where am I struggling?"

"What should I practice next?"

🎯 The Next Best Move

This is one of the ideas I care most about in CampusCopilot.

For example, if a student repeatedly struggles with recursion:

Recursion → 42% Accuracy → Weak Topic Detected → Priority Focus → 35-Minute Practice Session → Quiz → Updated Performance → Updated Recommendation

Instead of simply giving another explanation, CampusCopilot can recommend an action.

The goal is not just knowledge delivery.

The goal is progress.

🔗 The Complete Learning Journey

The different parts of CampusCopilot are connected:

Dashboard → StudyBuddy → Quiz → Learning Performance → Weak Topic → CodeExplain / Practice → Campus Planner → Study Plan → Dashboard

This creates a continuous learning loop instead of a collection of disconnected AI features.

🤖 Why Local AI?

One of the most important technical decisions was supporting a local AI setup.

CampusCopilot can run:

CampusCopilot → AI Service Layer → Ollama → Llama 3.1 8B

This creates a local-first option for working with personal study materials, code and learning context.

The Settings page clearly communicates whether the application is using:

REAL LOCAL AI

DEMO MODE

If Ollama is unavailable, CampusCopilot does not pretend that a simulated response came from the local model.

Instead, it provides explicit controls to retry the connection or use Demo Mode.

🏗️ AI Architecture

The overall architecture is:

Student

↓

CampusCopilot Workspace

↓

StudyBuddy / CodeExplain / Campus Planner

↓

Retrieval Layer

↓

TF-IDF + Cosine Similarity

↓

AI Service Layer

↓

Ollama

↓

Llama 3.1 8B

The architecture keeps the AI service layer modular so the application can work with a local model while keeping the rest of the learning system independent from the model implementation.

🧩 Unified State

Another important part of the project is the shared learning state.

CampusCopilot uses a unified application state so that the different sections aren't isolated demos.

The application maintains a single source of truth for the student's learning context using:

campus_copilot_state_v3

stored in local browser storage.

This allows information such as learning activity, tasks, progress and weak areas to remain connected across the application.

🧠 What Makes CampusCopilot Different?

There are already thousands of AI chatbots.

I didn't want to build another one.

The interesting part of CampusCopilot is the connection between the features.

A student can:

Study a topic → take a quiz → perform poorly → have the weak area identified → receive a practice recommendation → practice the topic → see progress reflected in their profile.

That creates a learning loop instead of a collection of disconnected AI features.

🛠️ Technology

Frontend

React
TypeScript
Vite

AI

Llama 3.1 8B
Ollama
Modular AI service layer

Retrieval

PDF processing
Text chunking
TF-IDF
Cosine similarity

State

Unified application state
Persistent local browser storage

Deployment

Vercel

🎨 Product Design

I wanted the product to feel different from a generic AI chatbot.

The interface was designed as a developer-focused campus workspace rather than a traditional chatbot.

The design uses:

Dark-first interface
Optional light mode
Developer-inspired visual language
Glassmorphism panels
Modern typography
Code-focused UI
Dashboard-style information hierarchy
Responsive layouts
Developer-inspired visual elements

The goal was to make it feel like a personal developer campus, not another ChatGPT clone.

🧪 Testing & Product Readiness

I tested CampusCopilot as a complete student journey rather than only testing individual screens.

The main flows were checked:

Dashboard navigation
StudyBuddy
Uploaded study material interaction
Grounded question flow
Quiz flow
CodeExplain
Campus Planner
Study plan generation
Learning Profile
State persistence
Demo Mode
Local AI connection handling
Empty states
Loading states
Error handling
Responsive navigation

I also added explicit loading states such as:

"Thinking..."
"Analyzing your code..."
"Preparing your question..."
"Building your study plan..."

and protected the application against accidental double submissions.

The production build was verified successfully with npm run build with 0 TypeScript or Vite build errors.

🧹 Product Audit & Polish

Before deployment, I performed a complete product audit and removed:

Obsolete boilerplate
Console errors
Duplicate mock data
Unnecessary hardcoded values

I also added meaningful empty states such as:

"You're all caught up!"
"No practice problems solved yet"
"No upcoming exams scheduled"

The goal was to make the application feel like a complete product rather than a collection of hackathon screens.

🔌 Real Local AI + Demo Mode

CampusCopilot supports two clearly communicated modes.

REAL LOCAL AI

When Ollama is running on port 11434, CampusCopilot can use:

Llama 3.1 8B Instruct

DEMO MODE

If Ollama isn't available, the user can explicitly choose Demo Mode.

The application provides:

[Retry Connection]

and

[Use Demo Mode]

instead of silently pretending that Demo Mode responses are real model responses.

This makes the hackathon demo more reliable while keeping the local AI architecture transparent.

🎥 Demo Video

Watch the complete CampusCopilot demonstration:

YouTube Demo

The demo covers:

Dashboard → StudyBuddy → CodeExplain → Campus Planner → Learning Profile

🤖 AI Development / Agent Sessions

AI-assisted development was used during the project for coding assistance, debugging, iteration and documentation.

The development process involved repeatedly:

Build → Test → Find bugs → Debug → Improve → Test again

The important part wasn't simply generating code.

The final product decisions, feature design, architecture and testing decisions were made based on the actual product requirements.

🌐 Live Demo

🚀 Try CampusCopilot:

https://campus-copilot-flax.vercel.app/

The deployed version can be explored in Demo Mode.

The local setup supports Llama 3.1 through Ollama.

💻 GitHub Repository

The complete source code is available here:

https://github.com/iam-ayushraj05/campus-copilot

💡 Why I Built It for a Friend

The project started with a simple problem.

My friend didn't need another place to ask an AI questions.

They needed something that could help organize the entire learning process.

They were dealing with:

DSA practice
Coding mistakes
Study materials
Assignments
Upcoming exams

at the same time.

That made me think:

"What if the AI could understand all of those signals together?"

That became CampusCopilot.

🌱 Why Open Innovation Matters

For students, AI should not always mean sending every piece of personal context to a remote service.

Study materials, source code, learning history and mistakes can all be personal.

Open-weight models make it possible to explore architectures where AI can run locally and the student has more control over their data and environment.

That's one of the reasons I wanted to experiment with Llama 3.1 through Ollama.

🚧 What I Learned

The hardest part wasn't getting an AI model to answer a question.

It was deciding:

"What should happen after the answer?"

A useful AI learning product needs to connect:

Conversation → Practice → Performance → Weakness Detection → Recommendation → Action

That changed how I think about AI applications.

The AI model isn't the entire product.

The system built around the AI is the product.

🔮 What's Next?

There is still a lot I want to improve:

Better retrieval and embeddings
More programming practice
Richer learning analytics
More personalized recommendations
Support for additional local models
Better evaluation of actual learning progress
More adaptive quizzes
Stronger long-term learning memory

But the core idea will remain the same:

Help students understand what they need to learn, why they need to learn it, and what they should do next.

🏆 Built for the Hackathon

CampusCopilot was built for the Hacktoberfest Weekend Challenge: Build for a Friend.

The project started with a real student problem rather than starting with a technology and searching for a problem afterward.

The goal was simple:

Build something a college student could actually use.

The project combines:

AI-assisted learning
Local open-weight AI
Grounded retrieval
Coding education
Personalized recommendations
Learning analytics
Study planning
Persistent learning state

All inside one connected developer-focused campus workspace.

❤️ Final Thought

I started CampusCopilot because one student was struggling to keep everything together.

What started as a solution for a friend became an experiment in a bigger question:

"What if AI stopped being just an answer machine and became a learning companion that actually understands your progress?"

That's what I'm trying to build with CampusCopilot.

Study smarter. Understand your code. Know what to do next. 🚀

🔗 Project Links

🌐 Live Demo

https://campus-copilot-flax.vercel.app/

💻 GitHub Repository

https://github.com/iam-ayushraj05/campus-copilot

🎥 Demo Video

🤖 AI Disclosure

AI tools were used during the development of CampusCopilot for coding assistance, debugging, iteration, testing support and documentation.

The product concept, problem definition, feature design, architecture decisions, implementation direction, testing, evaluation and final product decisions were made by me.

🏷️ Tags

devchallenge

weekendchallenge

hf26challenge

react

Building Suraksha AI: My 10-Day Journey Building a Voice Agent for Disaster Response in India

Ayush Raj — Fri, 14 Aug 2026 21:00:55 +0000

Introduction

Over the past 10 days, I participated in 10 Days of Voice Agents — VoiceForBharat Edition, where I built Suraksha AI, a voice-first disaster response assistant designed for users in India.

The goal was simple: make disaster-safety information easier to access through natural voice conversations.

During emergencies such as floods, earthquakes, cyclones, landslides, or heatwaves, people may not have the time or ability to navigate websites or read long instructions. A voice assistant can provide short, conversational guidance and help users reach the right kind of assistance.

Suraksha AI was built for the Disaster Response track.

1. The Problem

India experiences many different types of natural disasters, including floods, cyclones, earthquakes, landslides, lightning, and extreme heat.

During these situations, people may need answers to questions such as:

What should I do right now?
Is there a recent disaster event in my area?
Where can I get emergency assistance?
What should I take with me?
Can I get help from a human?
Can the assistant remember important information for future conversations?

Traditional information systems often require users to search, read, and navigate multiple pages.

I wanted to explore a different approach:

What if disaster assistance could happen through a natural voice conversation?

That idea became Suraksha AI.

2. Meet Suraksha AI

Suraksha AI is a real-time voice assistant focused on disaster preparedness and emergency guidance.

It can help users with:

Flood safety
Earthquake safety
Cyclone preparation
Landslide awareness
Heatwave precautions
Lightning and severe-weather safety
Emergency preparedness
Recent disaster-event information
Human-help escalation
Shelter-related conversations

The assistant is designed to remain calm, concise, and practical because emergency conversations should not overwhelm the user with unnecessary information.

Voice is especially useful here because the user can simply speak naturally instead of navigating a complicated interface.

3. How the System Works

The core voice pipeline looks like this:

User Speech
     ↓
Deepgram Nova-3
     ↓
Google Gemini
     ↓
Murf Falcon
     ↓
User Voice

LiveKit provides the real-time communication layer that connects the different components.

Main technologies

LiveKit Agents

Used to build and manage the real-time voice-agent workflow.

Deepgram Nova-3

Used for speech-to-text so the user's voice can be converted into text.

Google Gemini

Used as the reasoning and conversation engine.

Murf Falcon

Used for natural, low-latency voice generation. I used an Indian voice to make the assistant feel more natural for the target users.

Next.js

Used for the frontend experience, including the voice interface, transcript, status indicators, and overall UI.

Python

Used for the LiveKit agent and backend logic.

4. Important Features I Built

🗣️ Natural Voice Conversation

The most important part of the project is the ability to communicate naturally through voice.

For example, a user can ask:

"There is a flood in my area. What should I do?"

The assistant can respond with concise safety guidance instead of requiring the user to read a long emergency document.

🛡️ Safety Guardrails

A disaster-response assistant cannot simply generate any answer.

I added explicit guardrails to prevent Suraksha AI from:

Inventing disaster information
Claiming an area is completely safe
Pretending to be emergency authorities
Pretending to be NDRF, SDRF, IMD, police, or a doctor
Claiming that rescue teams have been contacted
Inventing emergency numbers
Giving fake live disaster information
Creating human-help requests without user permission

For immediate emergencies, the assistant directs the user toward emergency services such as 112 rather than pretending that the AI itself has contacted responders.

This was an important design decision because an AI assistant should never create a false sense of security during an emergency.

🌐 Disaster Alert Tool

Suraksha AI can use a disaster-alert tool to retrieve recent disaster-event information from GDACS.

This creates an important distinction between:

General knowledge

and

Current disaster information.

The assistant should not present general knowledge as if it were live information.

When live verification is unavailable, the system is designed to say so rather than inventing an alert.

🧠 Persistent Caller Memory

I also implemented persistent caller memory.

With permission, the system can store information such as:

Name
Location
Household size
Mobility needs
Language preference
Last check-in

However, sensitive information such as passwords, PINs, OTPs, Aadhaar numbers, and financial credentials should never be stored.

The system also requires explicit permission before saving caller information.

🆘 Human Help Escalation

One of the features I found particularly important was human escalation.

AI should not pretend that it can solve every emergency.

If a user is trapped, injured, or needs urgent local assistance that the AI cannot provide, Suraksha AI can prepare a human-help escalation request.

But there is an important safety gate:

The user's explicit permission is required before creating the escalation.

The system can explain why human help is appropriate, explain what information will be shared, and ask the user whether they want to proceed.

This makes the AI an interface to human assistance rather than pretending to replace human responders.

🏠 Shelter Specialist Handoff

I also implemented a specialist-agent handoff for shelter-related conversations.

For example:

"Where can I stay if my house is flooded?"

Instead of continuing the conversation entirely as the general disaster assistant, Suraksha AI can transfer the conversation to a Shelter Information Specialist.

The specialist receives the existing conversation context so that the user does not have to repeat their situation.

This was one of the more interesting parts of the project because it demonstrated how multiple specialized agents can work together instead of putting every responsibility into one huge prompt.

The shelter specialist is also explicitly prevented from inventing shelter names, addresses, availability, or opening times when verified live shelter data is unavailable.

5. The Frontend

The frontend was built with Next.js and designed around a voice-first experience.

It provides:

Voice interaction
Live conversation transcript
Agent status
Suggested voice queries
Disaster-response themed interface
Real-time interaction feedback

The idea was to make the interface understandable even when the user is focused primarily on speaking.

6. The Challenges I Faced

Building a voice agent was very different from simply building a chatbot.

One of the biggest challenges was agent behavior.

A prompt may say:

"Transfer shelter-related questions to the specialist."

But the actual conversation can be unpredictable.

Users may say:

"I need a shelter."

or:

"There is a flood and I'm trapped. I need a relief center."

or even:

"Can you connect me with the shelter specialist?"

These variations required careful tool descriptions and system-prompt instructions.

Another challenge was making the handoff feel natural.

The main agent needed to clearly announce the transfer, the specialist needed to continue from the existing context, and the user should not have to repeat their emergency.

I also had to test situations where multiple intents appeared together, such as:

flood + trapped + shelter + human help

That taught me an important lesson:

Voice agents need behavioral testing, not just code testing.

A function can work perfectly while the overall conversation still feels wrong.

7. What I Learned

This challenge taught me that building a voice agent is much more than connecting an LLM to text-to-speech.

The hardest part is designing the conversation architecture.

I learned to think about:

What should the agent know?
What should it never claim?
When should it use a tool?
When should it ask for permission?
When should it transfer the conversation?
What information should be remembered?
What information should never be stored?
What happens when a tool fails?
How should the agent behave during an emergency?

These decisions are just as important as the underlying AI model.

8. How You Can Build a Voice Agent

A basic real-time voice agent needs four major pieces:

1. Speech-to-Text

Converts the user's voice into text.

For Suraksha AI, I used Deepgram Nova-3.

2. LLM

Processes the user's request and decides what the agent should say or which tool it should use.

I used Google Gemini.

3. Text-to-Speech

Converts the generated response back into natural speech.

I used Murf Falcon.

4. Real-Time Transport

Connects the user's microphone, agent, audio output, and real-time events.

I used LiveKit Agents.

The architecture can be represented as:

                 ┌──────────────────┐
                 │      User        │
                 │     Speech       │
                 └────────┬─────────┘
                          │
                          ▼
                 ┌──────────────────┐
                 │  Deepgram STT    │
                 │    Nova-3        │
                 └────────┬─────────┘
                          │
                          ▼
                 ┌──────────────────┐
                 │   Google Gemini  │
                 │       LLM        │
                 └───────┬───┬──────┘
                         │   │
               ┌─────────┘   └──────────┐
               ▼                        ▼
       ┌───────────────┐        ┌───────────────┐
       │   AI Tools    │        │ Specialist /  │
       │ GDACS / Memory│        │   Escalation  │
       └───────────────┘        └───────────────┘
                         │
                         ▼
                 ┌──────────────────┐
                 │    Murf Falcon   │
                 │       TTS        │
                 └────────┬─────────┘
                          │
                          ▼
                 ┌──────────────────┐
                 │      User        │
                 │      Voice       │
                 └──────────────────┘

9. Running the Project

After cloning the repository, install the project dependencies and configure the required environment variables.

Keep API keys in environment files such as:

.env.local

and make sure those files are included in .gitignore.

Never commit API keys, phone numbers, caller data, or private credentials to GitHub.

The general development workflow is:

git clone https://github.com/iam-ayushraj05/suraksha-ai.git
cd suraksha-ai

# Install frontend dependencies
npm install

# Install backend dependencies
uv sync

# Configure environment variables
# Add the required API keys to your local .env files

# Start the LiveKit agent
uv run python src/agent.py dev

# Start the frontend in another terminal
npm run dev

The exact commands may vary depending on the project structure and environment.

Once both the backend agent and frontend are running, connect to the application and test conversations through the voice interface.

I recommend testing multiple scenarios rather than just saying:

"Hello."

For example:

"There is a flood in my area. What should I do?"

"Is there a recent disaster near Patna?"

"I need a relief shelter."

"I am trapped and need human help."

"Can you remember my location?"

"How do I prepare for an earthquake?"

Testing different conversation paths is where many voice-agent problems become visible.

10. Evidence From the Build

During the challenge, I tested Suraksha AI through real voice conversations and iterated on the agent behavior.

Some useful evidence to include with this post:

Screenshot of the Suraksha AI interface
Screenshot of the live transcript
Short demo video
Architecture diagram
Shelter specialist handoff
Human escalation flow
Disaster-alert tool response
GitHub repository

These demonstrate the actual system much better than screenshots of code alone.

11. What I Would Build Next

Suraksha AI is still an early version.

There are several directions I would like to explore next.

📍 Verified Shelter Discovery

Integrate trusted government or verified local shelter datasets so that the specialist can provide actual shelter locations instead of only explaining how users can find them.

🗺️ Location-Aware Assistance

With appropriate user permission, the system could use reliable location information to provide more relevant emergency guidance.

📞 Human/Responder Integration

The escalation system could eventually integrate with authorized emergency-response workflows rather than simply creating an internal request.

🛰️ More Real-Time Disaster Data

Additional trusted sources could provide information about weather, flooding, cyclones, earthquakes, and other hazards.

🧑‍🤝‍🧑 More Specialist Agents

The architecture could be expanded with specialists for:

Medical guidance
Evacuation information
Shelter discovery
Weather information
Family reunification
Relief-resource information

📊 Better Analytics

Call analytics could help measure:

Response latency
Successful conversations
Escalation rate
Tool failures
Handoff success
Common emergency questions

12. Repository and Demo

💻 GitHub

https://github.com/iam-ayushraj05/suraksha-ai

🚨 Project

Suraksha AI — AI Disaster Response Voice Assistant for India

The repository contains the implementation and documentation for the project.

📸 Screenshots

Add screenshots of the final Suraksha AI interface, transcript, specialist handoff, and escalation flow here.

Final Thoughts

The biggest takeaway from these 10 days is that building a useful voice agent is not simply about making an AI that can talk.

It is about building a system that knows:

when to answer, when to use a tool, when to ask permission, when to transfer to another agent, and when to involve a human.

Suraksha AI started as a voice-agent challenge project, but the experience showed me how voice interfaces, AI agents, real-time systems, tools, memory, and human escalation can come together to solve real-world problems.

I'm grateful for the opportunity to learn, experiment, break things, debug them, and keep improving the system throughout the challenge.

10 Days of Voice Agents — VoiceForBharat Edition

Built with LiveKit, Google Gemini, Deepgram, Next.js, Python, and Murf Falcon.

Thanks to Murf AI for the opportunity to build and learn through this challenge.

VoiceForBharat #VoiceAgents #AI #GenerativeAI #LiveKit #MurfAI #MurfFalcon #DisasterResponse #India #BuildInPublic