Kampus: Campus AI with a talking Owl

talking owl
claude
chatgpt

Inspiration

Most of us already ask ChatGPT or Claude about everything, except campus life. What's due this week is in Canvas. A free study room is on the library's booking site. The next train is in the SEPTA app. Courses are in Banner. That's four apps, four logins, and an AI assistant that knows nothing about any of it.

Universities can't simply let AI assistants into their systems either. Student records are protected by FERPA, and schools like Temple require security approval before non-public data goes anywhere near AI. So we asked: what would a connection look like that students would want to use, and that a university's IT office would sign off on?

What it does

Kampus puts your campus inside the AI assistant you already use. It's an MCP server (the open standard that both Claude and ChatGPT speak) that connects assistants to real campus systems:

Study rooms: live availability from Temple's and Saint Joseph's library booking systems, plus a two-step booking (a proposal, then a write you approve). Bookings are simulated in the demo.
Courses: live Fall 2026 sections from Temple's course catalog.
Transit: live SEPTA Regional Rail, and the Broad Street Line (the B) from SEPTA's official schedule.
Library hours: live from Temple's library site.
Deadlines: from a synthetic Canvas. We never touch real student data.

The part that sets it apart is the school stays in control. Every tool has a data class (Public or Sensitive), and every call is checked against role × tool × data class × which assistant is asking:

Claude, set up as the school's approved assistant, can read your deadlines.
ChatGPT, on the same server with the same student logged in, is refused, because it isn't the school's approved workspace.
Every decision is written to an audit log that records which feature was used and when, never what you asked or the answer, with the student ID hashed.

We also built a talking owl. Anyone can walk up and ask about rooms, trains or library hours. It connects as a public device, so when you ask it "what's due this week?", it politely refuses. Personal data never goes through a voice pipeline.

And it's not Temple-only: Saint Joseph's University runs on the same software with one config file pointing at their own library system.

How we built it

One small, strict server. Kampus is an MCP server written in Rust. It speaks both current MCP protocol versions, so it works in Claude and ChatGPT without any per-assistant code.
Login through the school's own identity provider. We use Keycloak as a stand-in for university single sign-on (Temple itself runs Keycloak). Approved assistants are pre-registered clients whose secret only the school's admin holds; anything that registers itself is unapproved by definition.
Policy on every call, before any data is touched. Tools are never hidden: everyone sees the same tool list, and refusals are explicit and audited.
Adapters per vendor, not per school. One library-booking adapter serves both Temple and Saint Joseph's. Everything school-specific lives in two config files.
Real data first. We recorded real responses from every public source and built against them. That's how we caught the course catalog silently returning "no results" without a session, and SEPTA's live feed not covering the subway.
The owl: a Raspberry Pi 5 with two round-screen eyes, a webcam mic and a Bluetooth speaker. Gemini Live listens and thinks, ElevenLabs speaks, and a small bridge on the Pi calls kampus with the owl's own device credential.

Challenges we ran into

Making identity mean something. A plain OAuth client ID can't tell a school's ChatGPT workspace from someone's personal account. We had to design approval around pre-registered clients instead.
Real-world data quirks. The course catalog needs a session before it returns anything, the Broad Street Line isn't in SEPTA's live arrivals feed, and the campus night shuttle only runs at night. Each needed an honest fallback, so the tools say "unknown" instead of guessing.
Getting real assistants to log in. Claude and ChatGPT each look for login information differently, and our identity provider needed extra scopes and settings before either would finish signing in.
Echo on a tiny robot. The owl's mic sits inches from its speaker, so it would hear itself. We mute the mic while it talks.
Infrastructure plans changing mid-hackathon. When our planned cloud server fell through, we moved everything (the identity provider, both school instances and the tunnel) onto a laptop, then onto our own domain, in the middle of the night.

Accomplishments that we're proud of

The same server gives different answers to Claude and ChatGPT for the same student, purely because of school policy, and you can watch the decision land in the audit log.
A second university with zero code changes.
A talking owl whose best feature is knowing what not to say.
Everything public is live; everything personal is synthetic. Nothing about real students is ever touched.

What we learned

Privacy has to be built into the architecture, not bolted on. Checking policy on every call and hiding nothing turned out simpler and safer.
"I don't know" is a feature. Both Claude and ChatGPT handled our honest "no service" and "not permitted" answers gracefully.
AI coding agents move fast when humans own the contracts and the integration. Recording real API responses up front was the best decision we made.

What's next

NFC on the talking owl so students can tap their student ID and can get personalised answers.
More campus services: dining, events and building info.
A pilot conversation with a university IT office, and publishing Kampus as an app in ChatGPT's and Claude's directories.