Inspiration
Campus offices and students juggle many systems catalogs, holds, schedules, and policies and generic chatbots either hallucinate or ignore who is asking wich can give wrong info to wrong people. We wanted a realistic demo of a Texas A&M University–San Antonio–style assistant that respects **roles and least privilege: students see their world, faculty see their sections, and staff see only what their unit should, while guests stay on public information.
What it does
JagAssist is a signed-in, role-aware chat UI that talks to an LLM configured to answer only from database-backed tools—not free-form invention. Users log in as **student, **professor, **staff* (with scopes such as international office vs. student business services), or guest. The assistant can query **synthetic* academic and campus data (courses, enrollments, holds, buildings/maps pointers, degree-plan style outputs, etc.) according to strict system prompts and tool availability so answers stay aligned with the demo dataset and permissions.
How we built it
- Frontend: Next.js (App Router), React, Tailwind CSS; chat and login flows with client-side session checks.
- Auth: HTTP-only session cookie with JWT (jose), bcrypt-hashed users in auth.sqlite.
- Data: Multiple SQLite files with Drizzle ORM—e.g. canonical **academic/student data, separate staff and guest DBs, plus seed/import scripts for a rich demo catalog.
- AI: OpenAI Chat Completions with function/tool calling; the API route injects **role- and scope-specific system instructions and exposes toolsForRole so the model can only invoke allowed tools; results are fed back in a multi-step loop with a step cap.
Challenges we ran into
- Grounding vs. helpfulness: Keeping the model from “helpfully” inventing policies, people, or numbers when tools return nothing—handled with explicit system rules and tool-only answers.
- Permission modeling: Encoding staff scopes (e.g. tuition/residency-only vs. international populations) and professor vs. student boundaries in both tool lists and prompts so they stay consistent.
- Data realism without production data: Designing seed data and optional catalog import so demos feel credible while remaining clearly non-official and synthetic.
- Multi-database layout: Routing the right Drizzle schema and queries per role without duplicating logic everywhere.
Accomplishments that we're proud of
- A clear separation: UI → authenticated API → **role-scoped tools → SQLite, with the model as an interface layer rather than the source of truth.
- Demonstrable least privilege in one flow—same product, different capabilities per login.
- A coherent stack (Next.js + Drizzle + SQLite + OpenAI tools) that is easy to run locally for judges or teammates.
What we learned
- Tool calling is a practical way to constrain campus Q&A: the hard part is schema, policies, and empty states, not the chat bubble.
- Role and scope belong in both the tool layer and the system prompt; one without the other breaks down under edge cases.
- Synthetic but structured data is enough to tell a strong UX and governance story for a hackathon without touching FERPA-sensitive systems.
What's next for JagAssist
- JagAssist can build on this foundation by adding streaming replies, richer **analytics for admins, and optional **integrations (read-only campus APIs where available) while keeping the same permission-first design.
- Short term: polish onboarding, **example prompts per role, and deployment notes so non-technical stakeholders can try it safely.
- Longer term: explore audit logs of tool usage and human-in-the-loop handoff for high-stakes questions.
Log in or sign up for Devpost to join the conversation.