SOTA Virtual Assistant

This project came out of the OutSystems sAIL Hackathon in April 2026. Our team was matched with the School of the Arts (SOTA), a specialised arts school in Singapore, to solve a real operational problem: their administrative staff were drowning in repetitive queries from students, parents, and teachers, things like "what events are happening this week," "where do I submit a leave form," "what's the IBCP curriculum structure." The answers existed, they were just buried across internal documents, scattered PDFs, and the school website.

We built a three-part system on the OutSystems ODC platform. A document upload portal lets SOTA staff submit internal documents (policies, curriculum guides, event announcements) for approval. When a document gets uploaded, a Gemini LLM call extracts metadata like title, subject, target audience, and date, then auto-tags it. The document goes into a review queue where a designated reviewer can approve, reject, or request changes. On approval, the document gets chunked and embedded into a Pinecone vector database.

The review workflow sends email notifications to reviewers as soon as a new document lands. The review screen lists pending, approved, rejected, and archived documents with filtering and search, and each document shows up alongside any similar existing documents the system detected against the vector store on upload, so reviewers can catch duplicates or outdated versions before approving.

The virtual assistant chat interface is the piece users actually interact with. A supervisor agent reads the question, figures out the intent, and routes it to either the RAG agent for knowledge queries or the Forms agent for document upload requests. The RAG agent searches Pinecone, pulls the top 10 results, reranks them down to the top 6 with bge-reranker-v2-m3, then passes those chunks as context to Qwen 3.6 Plus to generate a grounded answer. Session memory means follow-up questions work naturally instead of resetting each time. If someone asks for a specific form, like "I need to apply for leave of absence," the RAG agent finds the relevant form link in the vector store and hands it back directly.

The human-in-the-loop governance is the design decision I care about most. Nothing enters the knowledge base without a human reviewing and approving it first. The LLM never answers from unvetted content. The upload flow, the review queue, the vector store ingestion pipeline all exist because of that constraint. It means the school controls exactly what their virtual assistant knows, and wrong or outdated information can be traced back to a specific approved document.

We sat with SOTA's admin staff, heard their frustrations firsthand, and built the approval workflow because they told us straight up they needed editorial control over what gets published to students and parents. We'd originally planned a simpler direct-upload pipeline, but talking to the actual users meant governance had to come before speed, so the architecture changed around that.

A real school is planning to put what we built in front of their community, and that matters to me more than a hackathon placement.