Overview¶
The goal of this AppJar is to provide AI-powered assistant capabilities within the application, allowing users to interact with an intelligent conversational interface from within their workflow.
Modern enterprise applications increasingly benefit from integrated AI assistance that can answer questions, guide users through tasks, and surface relevant information without requiring them to leave the application. The AI Support AppJar embeds this capability directly, making AI assistance available to users in context and giving administrators full control over how that assistance is configured, monitored, and extended.
The same conversations are reachable two ways: a full chat view, and a floating chat bubble that opens over whatever page the user is on. The second matters more than it sounds — a question asked without abandoning the task at hand is a question users actually ask.
Assistants¶
An assistant is the central concept in the AI Support AppJar. Each assistant combines a language model with a prompt that shapes its behaviour and personality. Administrators can define multiple assistants for different purposes — for example, one assistant for customer support, another for internal knowledge queries — and designate one as the default for users who have not selected a specific one.
Assistants can be associated with content categories, which control which documents are available to them as context. This allows each assistant to draw from a curated subset of the organisation's knowledge base rather than everything available.
Sessions and Conversations¶
When a user starts a conversation, the AppJar creates a session. A session tracks the full exchange between the user and the assistant, including all messages, timestamps, and participants. Sessions persist across logins so that users can resume conversations where they left off, and they can be archived or closed when no longer active.
Administrators can join sessions as participants, making AI Support suitable for use cases where human oversight or intervention is required alongside AI responses. Each participant's activity is tracked separately so that administrators can identify where their attention is needed. A conversation can be handed from the assistant to a person and back, and administrators can exchange notes within a session that the end user never sees.
Users can rate sessions and leave optional comments, providing feedback that helps administrators evaluate assistant quality and tune configurations over time. A user can also subscribe to a conversation to be alerted whenever a new message arrives in it, which suits a question that someone else is expected to answer.
Sessions that nobody returns to would otherwise accumulate indefinitely, so the appjar can close conversations automatically once they have been inactive for a configurable period.
Language Models¶
The AppJar supports two families of language models: OpenAI-compatible models and locally hosted models via Ollama. Each model is configured independently with its connection details, and administrators can designate one as the system default. Multiple models can be active simultaneously, with different assistants using different models depending on the task.
OpenAI-compatible models support text, image, video, audio, and PDF content. Ollama models support text and image content. All model exchanges are recorded with full request and response detail, including token counts, to support cost monitoring and usage analysis.
A model can optionally be designated the system model, which additionally handles the work that surrounds a conversation rather than taking part in it, such as summarising sessions and screening messages for inappropriate language. The same model can still power assistants like any other, and when no system model is designated, that work falls back to the model of the assistant handling the conversation.
Answering with Application Data¶
Documents cover what an organisation has written down, but many questions can only be answered from live application state — the status of an order, the balance of an account. Assistants can therefore call application code during a conversation: a developer exposes selected methods as tools, and the language model decides when to invoke them and feeds the results into its answer. Which code is reachable this way is restricted by configuration, so exposing a tool is a deliberate decision rather than a side effect of adding a service.
Prompts¶
A prompt is the set of instructions that governs an assistant's behaviour: its tone, scope, constraints, and response format. Administrators create and manage prompts through a dedicated view and assign them to assistants. System prompts are distinguished from user-facing prompts, and prompts can be enabled or disabled independently of the assistants that reference them.
Documents and Retrieval¶
The AI Support AppJar includes a retrieval-augmented generation (RAG) system that allows assistants to draw on an organisation's own documents when answering questions. Administrators upload documents and assign them to one or more categories. When a user asks a question, the assistant retrieves the most relevant document passages using semantic vector search and incorporates them into its response.
Vector embeddings are stored in a PostgreSQL pgvector table and are generated automatically when documents are uploaded. Administrators can also enable an advanced RAG mode on individual assistants, which reformulates the user's question into several queries to improve recall, and an optional re-ranking model can reorder the retrieved passages by relevance before they reach the language model.
Because retrieval decides what the assistant is able to say, administrators can query the embedding store directly to check which passages a given question returns, and inspect the retrieval behind any answer that has already been given.
Documents can reference external data sources in addition to directly uploaded content, allowing the knowledge base to remain in sync with authoritative systems outside the application.
Categories¶
Categories are the organisational layer that connects assistants to documents. An administrator assigns categories to both assistants and documents, and the assistant uses only documents that share at least one category with it. This scoping ensures that each assistant stays focused on the domain it is configured for, and it allows the same document to be available to multiple assistants without duplication.
Messaging Channels¶
The AppJar can extend its conversational capabilities to external messaging platforms. Administrators configure channels that connect WhatsApp, Facebook Messenger, or Instagram accounts to the application. Each channel is linked to a specific AI assistant, so incoming messages from any of these platforms are routed through the same RAG pipeline as the web-based Chat view. Conversations from external channels create sessions in the system, which are visible and manageable through the same administrator tools.
Inspector and Audit¶
Every exchange between the application and a language model is recorded in full, including the request sent, the response received, the prompt and categories in use, and the document passages retrieved as context. Administrators can review this record through the LLM Inspector view to diagnose unexpected responses, verify that retrieval is working as intended, and track token consumption over time.