A University Library Assistant

The problem

A public university’s library fields the same handful of student questions constantly — is a study room free right now, can a loan be renewed, what does the library own on a given topic — through a front desk and a phone line that can’t scale past business hours. The university’s own systems (catalog, room-booking, student records) already existed; what didn’t exist was a conversational layer in front of them that students would actually use instead of waiting in line.

The integration

The university’s own backend team owns the student-facing frontend and keeps all student data in their own systems — Wetel never touches raw student records. Wetel’s agent and workflow layer sits behind their frontend as the conversational brain: it holds the RAG-grounded knowledge base over the library’s catalog, runs the room-availability and loan-renewal logic as MCP tool calls against the university’s own APIs, and returns structured, ready-to-render responses (including dynamic action buttons — “renew this loan,” “book this room” — generated directly from tool output).

This is the pattern documented in MCP Connectors: the university’s real systems are the source of truth, reached through their own MCP server, with Wetel never storing a copy of anything sensitive.

What made this non-trivial

Data sovereignty was a hard requirement, not a preference. The university needed conversation history and student identifiers to live in their own database, not Wetel’s — solved via External Conversation Sync, which forwards each turn to a webhook the university’s backend controls, in a schema they define.

A white-labeled integration surface. The university’s own developers needed to build against a gateway that never surfaces “Wetel” in any student-facing string or error message — a thin relay layer in front of Wetel’s public GraphQL API, following the headless-agents integration model.

Multi-region deployment. The same agent configuration runs identically against two separate Wetel deployments (different cloud regions), proving the platform’s configuration is portable rather than tied to a specific box.

Result

A live, self-service student assistant handling room booking, catalog search, and loan renewal without a human in the loop for the common case, with the university’s own developers able to extend it against a documented, stable API surface rather than a bespoke one-off integration.