What Shipping Duvi on Nalum Taught Us About Real AI Assistants

A website assistant becomes useful when it leaves the demo environment. Users stop asking polished test questions. They write incomplete names, mix several intentions into one message, and expect the assistant to understand the page they are currently looking for.

That is why we deployed a Duvi-powered assistant on Nalum, the alumni platform serving the NSUT community. The assistant is now live across the site, giving us a real environment in which to test grounded conversational navigation.

A production test, not a chatbot demo

An alumni platform contains several different kinds of information. A visitor might be looking for an event, an alumni initiative, a way to contribute, career resources, or simply the correct section of the website. Their question often reflects the outcome they want rather than the words used in the navigation menu.

A conventional search box expects the visitor to know the right keyword. A conversational assistant can instead interpret the request, answer from approved material, and direct the visitor to the relevant resource.

Nalum gives us a useful production test because the questions are naturally varied. It allows us to observe where retrieval works, where the source content is unclear, and where the assistant should admit that it does not have enough information.

The integration took two lines

Duvi was added through the website widget, the same installation path available in the Duvi quickstart. The widget script loads once in the global application shell, which makes the assistant available across public pages without coupling it to the React rendering tree.

The visible integration is intentionally small. Most of the work is behind it: crawling approved sources, breaking content into useful retrieval units, creating embeddings, selecting relevant context, and keeping the final answer tied to that context.

This separation is important. The alumni site owns its interface and content. Duvi supplies the conversational layer and can be updated independently as retrieval and agent behaviour improve.

Grounding matters more than a clever prompt

The current assistant is grounded in approved public website content. It is intended to help visitors understand and navigate what Nalum already publishes, rather than inventing information from a general model.

For every answer, the important questions are practical:

• Did retrieval select the correct source?
• Was there enough context to answer accurately?
• Should the assistant answer, ask a follow-up question, or direct the user to a page?
• Can the response help the visitor continue on Nalum instead of trapping them inside a chat window?

This deployment gives us real queries with which to evaluate those decisions. We are not publishing resolution rates or engagement claims yet. The deployment is new, and useful measurements need actual traffic rather than invented launch-day numbers.

The boundary around alumni data

Public website content and private alumni records are not the same thing. Embedding a website assistant does not mean placing the underlying alumni database into a publicly searchable vector index.

The first version therefore focuses on approved public information. Contact details, personal profiles, and other permissioned records should remain behind the platform's existing access controls.

If Duvi later supports authenticated alumni discovery, mentorship matching, event registration, or recruitment workflows, those capabilities should use controlled APIs. The API must decide what the authenticated user may access before returning anything to the assistant.

This is the same model Duvi uses for other agent integrations: the model interprets intent, while the connected system remains responsible for authorization and the final data boundary.

What this deployment gives Duvi

Nalum is valuable to us because it turns broad product claims into specific engineering questions. We can now test how the assistant handles ambiguous requests, missing source material, retrieval failures, mobile sessions, and changes to the underlying website.

It also exposes operational details that disappear in a demo. Content security policies must allow the widget. Deployment pipelines must publish the updated application shell. The assistant must load without interfering with the host application's rendering or performance.

Those details are part of the product. A useful agent is not only a model that can produce a good answer. It is a system that can be deployed, observed, constrained, and improved without destabilizing the website around it.

What comes next

The immediate goal is to learn from real usage and improve the public-content experience. Controlled actions can follow where they solve a demonstrated need, not merely because an API can be connected.

Possible next steps include permissioned event information, mentorship workflows, career resources, and authenticated alumni discovery. Each one will require a clear access policy and an explicit answer to what information the assistant may return.

This is a Duvi deployment on Nalum, not an announcement of institutional procurement or endorsement by NSUT. It is something more useful for the product at this stage: a live environment where the assistant has to work for real people.

If you want to add a grounded assistant to your own website, start with the Duvi quickstart or explore the platform in Duvi Studio.