Think of the busiest hour at a university library’s front desk. One student wants to know if a study room is free. The next wants to renew a book that is due tomorrow. A third asks whether the library has anything on a topic for an essay. None of these questions is hard. All of them are frequent, and the desk closes at night while the essays do not.
The desk staff do not answer from memory. They look at the room schedule, the loan record and the catalog, and they answer from what those systems say. An AI employee in that seat should work the same way: answer from the library’s own records, act only through the library’s own systems, and leave the library in charge of both.
This post walks through how one documented deployment does that. It is based on our anonymous case study of a university library assistant, and it marks where the documentation is silent, because a case walk is only useful if it is honest about its gaps.
The short answer: three jobs, all through the library’s own systems
The assistant does three things: it answers questions from a knowledge base built from the library’s catalog, it checks study-room availability, and it renews loans, each through the library’s own systems. The case study describes the result as a self-service student assistant for room booking, catalog search and loan renewal, handling the common case without a person stepping in.
The division of work is the important part:
- The library owns the student-facing app and keeps all student data in its own systems.
- Wetel holds the conversation layer: the AI employee’s persona, its workflow, and a knowledge base over the catalog.
- The library’s own systems stay the source of truth. Room availability and loan renewal are reached through a connector the library runs, so the AI employee can only do what the library’s systems allow.
How a question moves through it
Each student message runs through a workflow that works out what the student wants and sends it down one of three paths. The case study does not publish its graph, so the diagram below is a sketch of the shape it describes, built from the standard pattern in our docs (classify the message, then dispatch on the result), not the deployment’s actual configuration.
flowchart TD M["Student message"] --> C["Work out what<br/>the student wants"] C --> R{"Which path?"} R -- question --> K["Answer from the<br/>catalog knowledge base"] R -- room --> T1["Check rooms in the<br/>library's booking system"] R -- renewal --> T2["Check and renew through<br/>the library's loan system"] K --> A1["Reply"] T1 --> A2["Reply with a<br/>'book this room' button"] T2 --> A3["Reply with a<br/>'renew this loan' button"]Here is what each part does, as far as the docs say.
1. It works out the request. A classification step labels the message, and a router sends it down the matching path. A router matches the label exactly; a message that fits none of the labels goes to a default path you choose.
2. Questions are answered from the library’s own catalog. The answering step has a knowledge base attached. For each message, the most similar passages from the library’s catalog are found and handed to the model as reference material before it replies. The model answers from the institution’s own documents rather than from its general knowledge.
3. Rooms and renewals go through the library’s systems. These paths use tool steps that call tools exposed by the library’s own server through a connector. The AI employee asks the library’s systems on each request and works from what they return.
4. The reply offers the next action. The case study notes that replies come back structured and ready for the library’s app to display, including action buttons such as “renew this loan” or “book this room”, generated from what the tool returned. The student sees options that come from the library’s real data.
5. The student never sees our name. The library’s developers built against a thin relay of their own in front of Wetel’s API, so no platform name appears in any student-facing message or error (headless agents describes this model).
What it will not do
It acts only through the tools the library chose to expose, and it does not hold the library’s student records. A few limits follow from how the pieces are documented:
- No action beyond the library’s tools. A tool step can call only the tools the library’s own server offers. If the library’s server does not expose an action, the AI employee cannot take it.
- No student records of its own. The case study states student data stays in the library’s systems. The AI employee works with what a tool returns for the current request.
- No invented ids. Our docs recommend matching a name a student types (a room code, say) to an internal id with a lookup helper rather than a model, because models confuse one field’s digits for another’s id. Whether this deployment uses it is not stated; it is the documented practice for this kind of lookup (workflow best practices).
There are also two honest caveats about failures:
- A failed tool call gives the student a generic reply, and the real error is recorded for staff. A workflow can instead draw separate success and failure paths out of a tool step, so a failure goes to a reply someone wrote (“I couldn’t reach the room system just now, please try again”).
- If the knowledge base cannot be reached, the reply still goes out without it. The docs call this fail-open: one bad moment in retrieval should not take the assistant offline. The trade-off is that an attached knowledge base is not proof it was used for a given reply, so staff should check the run record when an answer looks off (fail-open retrieval).
Where people stay in charge
The library keeps control of the systems, the app and the records, and staff can inspect what the AI employee did on every run. Concretely:
- The systems decide. Whether a room is free or a loan can be renewed is answered by the library’s own systems, under the library’s own rules. The AI employee asks; it does not overrule.
- The library owns the experience. Its developers built the student app and the relay in front of it, and can extend it against the documented API.
- The library keeps its own copy of conversations. The case study uses external conversation sync, which sends each turn to the library’s own backend in a format the library defines. This is best-effort by design: if the library’s backend is down, a turn’s copy can be dropped after retries, so it is a record for reporting, not a guaranteed pipeline.
- Staff can read the run record. For each run, a signed-in user of the workspace can see which steps ran, what each tool step sent, what came back, and, for answering steps, which catalog passages were retrieved or whether retrieval failed (observability).
The case study does not describe a step that hands a conversation to a person, and it describes the common case as handled without one. If you are building something similar, the docs give you two places to add one:
- A fallback path. A router can send a conversation that keeps falling through to its default path to a branch you choose, for example one that tells the student how to reach library staff.
- A sign-off step. An approval step pauses the workflow until a workspace owner approves or rejects. You add it yourself; it is not on by default, only owners decide, and notices are in the app (email notice is not available yet). For room bookings and renewals that is probably more than the job needs, which is part of why this deployment is a good fit: both are routine, and the library’s own systems apply the library’s rules.
What the case study does not tell us
It is one deployment, and no measured outcomes have been published. We have not published how many questions it answers, how often its answers are correct, how many bookings or renewals it handles, or whether students or staff are satisfied, and we will not imply a number we have not measured.
It also does not tell us:
- the exact workflow graph, prompts or classification labels
- how library staff review conversations day to day
- what happens when a renewal is refused by the library’s system, beyond what the library’s own tool returns
If you run a library or a student service and want to judge whether this would work for you, test it on your own catalog and your own systems, with your staff reading the run records, before relying on it. Our post on trying a workflow safely before anyone sees it is a good start.
If a library assistant like this is the work you are weighing up, tell us which work you’d hand over first.
Related reference docs
- Case study: a university library assistant: the anonymous deployment this post walks through
- Knowledge Base (RAG): building a knowledge base from your own documents and attaching it to an answering step
- MCP connectors: connecting a server you run so a workflow can call its tools
- Tool node: calling a connected tool, timeouts, and success and failure paths
- Router node: dispatching on a classified request, with a fallback for messages that fit no label
- External conversation sync: keeping a best-effort copy of every turn in your own backend
- Headless agents: running an AI employee behind your own app
- Observability: reading the run record for each workflow run
- Approval node: adding a workspace owner’s sign-off before an action