Campus Concierge

Campus Concierge page

Inspiration

Being a student often means being broke, hungry, and having 40 minutes between classes, with dining hours in one tab and bus info in another. We wanted to ask one plain-English question, like "I have $10, I'm hungry, and class starts in 40 minutes. What can I eat, and which bus helps me get there and back fast?", and get one trustworthy answer.

What it does

Hokie Concierge is a small team of three AI agents behind a chat and a map:

The Concierge (main agent) reads your question, decides which specialist agent to ask, and writes the final answer.
The Dining Scout finds campus food options by budget and keywords.
The Transit Guide finds nearby bus stops and routes.

The Concierge sends real HTTP requests to the two specialists, then answers using only what they returned. If the data doesn't cover the question, it says so instead of guessing. The page shows:

A map with a pin for each result.
A status chip per agent.
An "Agent conversation" panel that shows the agents talking: plan, identity check, request, response.
A "sample data" banner whenever any data isn't fully verified.

How we built it

Web app: Next.js (App Router) with TypeScript and React. Chat and results are on the left, and the map, built with Leaflet and OpenStreetMap, is on the right.
Agents: the main agent plans with Gemini, then calls the Dining and Transit agents at their own endpoints inside the app. Each agent searches its own dataset and returns results with locations. Gemini then writes the reply under strict rules: never invent hours, prices, or places.
Data: [dining options and bus stops we collected by hand from official campus and transit pages on DATE, with source links and coordinates / placeholder data, clearly labeled as sample].
Reliability: Gemini can be overloaded, so we added retries, backup models, and a plain-summary fallback that the interface labels honestly. If a specialist's HTTP call fails, the main agent asks the agent's own data directly and says so in the trace.
Hosting: deployed on Vercel at [DOMAIN], a GoDaddy Registry domain pointed at Vercel with DNS records.

Challenges we ran into

We're beginners and changed direction several times: [we started with Python agent servers and a phone app, then moved to one deployable web app]. Vercel can't run separate Python servers, so we rebuilt both specialist agents inside the Next.js app. Our map and chat worked locally but not when deployed, until we fixed how the map loads and how the chat reaches the server. During testing, Gemini also returned "503 high demand" errors, which pushed us to add retries and honest fallbacks so the demo wouldn't die.

Accomplishments that we're proud of

Three agents that communicate over HTTP, with a visible trace of every step.
Answers grounded in the data, with honest labels: our agent identity check is a placeholder that the UI plainly marks as "mock", and fallbacks are announced instead of hidden.
A live app at [DOMAIN] that anyone can open.

What we learned

How to split a system into agents with clear contracts, how to deploy a Next.js app and point a custom domain at it, and how much error handling and honest labeling matter when a demo depends on an outside AI service.

What's next for Campus Concierge

Real verified identity for agents (replacing our labeled placeholder), live bus arrival times, more specialist agents (events, careers, campus resources), and "near me" ranking from the user's location.