CampusPilot

• 

  CampusPilot

• 

  Agent Orchestration

• 

  Final report

Inspiration

As a student, navigating campus life means juggling a dozen different systems just to answer basic daily questions. Dining portals, campus maps, financial aid pages, event boards. We wanted to build something that made all that friction disappear so students could spend less time searching and more time actually being students.

What it does

CampusPilot lets students ask plain English questions about dining, navigation, events, study spots, finances, and research and get back a real useful answer in seconds. It captures the student's live location from the browser and uses it to ground every response in where they actually are on campus rather than returning something generic.

How we built it

We built a FastAPI backend with a planner router aggregator pipeline and a Next.js frontend that takes students from prompt to results in real time. The core of the system is a set of specialized agents, each one responsible for a specific domain like dining, navigation, events, and finances, all running in parallel and merging into one unified response.

Challenges we ran into

Building multiple AI agents that work reliably together is genuinely hard. When one agent fails or slows down it can drag everything else down with it, and getting them to fail gracefully without breaking the whole response took far more iteration than we expected. Keeping the frontend honest about what was actually happening under the hood, rather than just guessing at completion, added another layer of complexity on top of an already moving system.

Accomplishments that we're proud of

The parallel agent architecture works and it is genuinely fast. Watching six agents spin up at once and converge into a single answer felt great when it finally clicked. We are also proud that the system degrades gracefully under partial failure, returning something useful to the student rather than breaking entirely, which took real work on both the backend and the frontend side.

What we learned

Designing around failure from day one completely changed how we structured the pipeline and the UI. We also learned that students tolerate waiting if they can see progress. The live WebSocket stream was added after watching people assume the app was broken after just a few seconds of silence on screen.

What's next for CampusPilot

More agents are coming. Bus schedules, office hours, financial aid deadlines, and campus alerts are all on the roadmap and the router is already built for them. Further out, we want to add personalized memory so the assistant learns each student's preferences and expand beyond UMD since the core pipeline is already campus agnostic and most school specific logic lives inside the agents themselves.

Built With

• fastapi
• javascript-frameworks-fastapi
• langgraph
• next.js
• next.js-platform-/-transport-websockets
• python
• typescript