Laurel

One conversation instead of 23 university systems. Laurel answers from your record, acts with your OK and shows what's due before it's urgent, so you spend less time on admin.

Comment

Inspiration

It started with one question: "Can I study part-time, around a 9-to-5?"

Answering it properly meant visiting six places: Student Connect, the STEM College pages, the RMIT website, the course handbook, the timetable, and finally emailing someone directly. RMIT lists 23 digital systems spanning learning, enrolment, timetabling, payments and support. Each one works, but none of them talks to the others, and none of them tells a student what they're about to miss.

The friction falls hardest on students with the least slack: first-years, international students, and anyone fitting study around work. Every hour spent hunting through portals is an hour not spent learning. So we asked: what if the whole university fitted in one conversation?

What it does

Laurel is an AI agent built on IBM watsonx Orchestrate. It lives as a chat widget on RMIT's own pages and as a full web app.

  • Coming up: before you type anything, Laurel shows what needs your attention, most urgent first: assignment deadlines across all your classes, account holds, library loans and key dates.
  • Answers from your own record: results, GPA, fees, timetables, program rules and Canvas assignments, each with a source line.
  • Takes action, safely: enrolling, dropping a class and booking a study room all happen only after a check, a summary and your explicit yes.
  • Helps you study: "Plan my study week" fits two-hour sessions around your workshops and commitments, most urgent work first, each with a free study room.
  • Never leaves you stuck: for questions it can't answer (visas, scholarships), it names the right office and offers to draft the email.

How we built it

Laurel is a tool-calling agent, not a document search. The model reads the student's question, picks one of 31 Python tools, and writes its reply from the structured result. Every fact comes from a deterministic lookup, never from the model's memory.

  • Agent: watsonx Orchestrate runs the agent's instructions and tool list. The tools are Python functions that return JSON with a source block.
  • Identity: the logged-in student's number reaches the tools through the run context, so the model never sees or supplies it, and can't be talked into fetching someone else's record.
  • Confirmation in code: every action is split into a check_* tool and an action tool, and the action refuses without a matching check ID and student_confirmed: true.
  • Data: a fixed-seed generator builds the synthetic university (3 programs, 150 courses, 14 demo students, Canvas assignments, rooms, loans), anchored to RMIT's public program pages and published key dates, and a validator checks it.
  • Front ends: a React web app and a React chat widget served by a FastAPI backend, with a Chrome extension that puts the widget on the real RMIT website.
  • AI-assisted development: most of the code was written with Claude Code. We led the idea, the UX, the logo and the demo story, and reviewed, tested and tuned every behaviour.

Calculations happen in code, not in the model. For example, the weighted average mark (WAM) weights each mark $m_i$ by its course's credit points $c_i$:

$$ \text{WAM} = \frac{\sum_i m_i \, c_i}{\sum_i c_i} $$

Due-date status is computed the same way, as $d = t_{\text{due}} - t_{\text{today}}$ days, and the agent quotes the result ("due in 8 days", "overdue by 2 days") rather than working it out.

Challenges we ran into

  • The model doing its own date maths. Early on, Laurel told a student an assignment was "due in about a week" when it was actually five days overdue. It had counted from the data's snapshot date instead of today. We fixed it by moving the calculation into the tool, so the model only ever quotes a status it's given.
  • Rules in prompts aren't enough. "Ask before drafting an email" was in the instructions, but the agent sometimes drafted anyway. A single tool with an on/off switch made it skip the lookup entirely. What worked was splitting it into two tools that match the two steps: find_support_team names the right office, and draft_enquiry is only called after a yes.
  • A stale cookie that hid the widget's login. After a server restart, the browser extension sent an old web-app cookie alongside its own valid token. The backend checked the cookie first, so the widget silently lost the student's name and data. The fix was to trust the widget's token on its own whenever it's present.
  • Making the demo data honest. Students with all deadlines on the same day, or everything already overdue, didn't tell the story we wanted. We gave our demo student four real classes with staggered deadlines, so nothing is overdue on the demo date, but plenty is due soon.
  • Latency. A reply that calls several tools takes 15–25 seconds. We made Coming up load straight from the data with no model call, so the first thing a student sees is instant.

Accomplishments that we're proud of

  • It works end to end, live: a real agent on watsonx Orchestrate, calling 31 tools, inside a widget on the actual RMIT website.
  • Trust is built in, not bolted on: every answer carries a source, a student can only ever see their own record, and nothing changes without an explicit yes, enforced in code.
  • Proactive, not just reactive: Coming up tells students what matters before they ask, and "Plan my study week" turns deadlines, timetables and free rooms into an actual plan.
  • Tested like a product: hundreds of automated tests, plus scripted conversations run against the live agent before each change was accepted.
  • A brand of our own: the Laurel logo went from hand-drawn sketches to the final mark used across the widget, web app and extension.

What we learned

  • An agent is only as trustworthy as its tools. Anything that matters (dates, money, permissions, confirmations) belongs in code, where it can be tested, not in the prompt.
  • Tool names shape behaviour. The model reaches for whichever tool's name matches what it's about to do, so a name like draft_enquiry invites drafting.
  • Proactive beats reactive. Students rarely know what to ask. Showing them what's coming up changed Laurel from a help desk into something that keeps them ahead.
  • Test the conversation, not just the code. Alongside the unit tests, we ran scripted conversations against the live agent before every change, which caught problems the unit tests never would have.

What's next for Laurel

  • Real systems: connect to the university's actual systems (Canvas, enrolment, library) instead of synthetic data.
  • Real login: sign in with the university's existing student account.
  • Staff view: show the most common questions and where students get stuck, so the university can fix the underlying problems.
  • Beyond RMIT: every university has the same sprawl of systems, and Laurel's tools are data-driven, so adding a new program or institution is a data change, not a rewrite.

AI Acknowledgement

Building it

  • Most of the code was written with Claude Code (Anthropic's AI coding assistant, Claude Opus 5.5). That covers the Python tools, the agent setup, the web app and widget front ends, the synthetic data generator, the automated tests and the documentation.
  • AI was also used to help draft pitch wording and to research comparable university tools. All claims were checked against cited sources.

Running it

  • Laurel itself runs on IBM watsonx Orchestrate, whose hosted language model understands questions, chooses tools and writes replies.

Human-led

  • The original idea and problem framing
  • The overall approach and feature priorities
  • The UI and UX decisions (what appears where, and when)
  • The Laurel logo design, from hand-drawn sketches to the final mark
  • The demo narrative and pitch

Human-reviewed and refined

  • Every feature was reviewed and tested by hand in the web app and widget.
  • The agent's instructions and tool descriptions were reviewed, and conversations were iteratively tuned (for example, ask before drafting an email, never give an overdue status for an assignment that isn't overdue).
  • The demo data was shaped to tell a realistic story.

Checked, not just generated

  • Behaviour was verified with an automated test suite and with scripted conversations run against the live agent before each change was accepted.

Data

  • All student data is synthetic.
  • Key dates and program structures are transcribed from RMIT's public pages. No real student data or university systems were used.
Share this project:

Updates

Submission history