AI assistants & Chat interfaces

AI assistants and chat interfaces are the most direct way to put AI capability in the hands of users. They provide a conversational layer through which users can ask questions, retrieve information, complete tasks, and interact with the knowledge and tools your organisation has made available. On GLBNXT Platform, assistants and chat interfaces are built on managed model endpoints, configurable frontend components, and optional extensions for retrieval, tool use, and memory that allow you to shape exactly what the assistant can do and what it has access to.

This section covers the architectural patterns, platform components, and implementation guidance for building AI assistants and chat interfaces on GLBNXT Platform.

What This Pattern Is For

AI assistants and chat interfaces are the right architectural choice when the primary interaction model is conversational and the primary output is a response generated by a language model. This covers a broad range of use cases, from simple single-turn question and answer tools to sophisticated multi-turn agents that maintain context, retrieve information, and take action on behalf of the user.

Common use cases in this category include:

• Internal knowledge assistants that help employees find information, navigate policies, or get answers from organisational data

• Compliance and legal Q&A tools that provide guidance grounded in regulatory documents, internal policies, or legal reference material

• Customer support automation that handles routine enquiries, escalates complex cases, and maintains conversation history across interactions

• Tender analysis and procurement assistants that help teams review, compare, and summarise large volumes of structured documentation

• Sector-specific assistants for public sector, healthcare, and financial services organisations operating under strict compliance requirements

Core Architecture

The foundational architecture for an AI assistant on GLBNXT Platform consists of three components working together: a language model, a system prompt, and a chat interface. This is the simplest working configuration and the recommended starting point for any assistant use case.

The language model provides the reasoning and generation capability. The system prompt defines the assistant's role, scope, tone, and behavioural boundaries. The chat interface provides the conversational frontend through which users interact with the assistant.

From this foundation, the architecture can be extended in several directions depending on what the assistant needs to do.

Extending the Base Architecture

Adding Knowledge Retrieval

When your assistant needs to answer questions based on your organisation's own data rather than relying solely on the model's trained knowledge, a retrieval layer is added to the architecture. This connects the assistant to a vector database containing embeddings of your source documents, enabling the model to ground its responses in retrieved context at query time.

This extended pattern is a RAG-based assistant. The user's query is used to retrieve the most relevant content from the vector database, the retrieved content is injected into the model's context alongside the query, and the model generates a response grounded in that specific information. The result is an assistant that answers accurately from your data without the model needing to have been trained on it.

For detailed guidance on building the retrieval layer, see the RAG and Knowledge Systems section.

Adding Tool Use

When your assistant needs to do more than generate text, tools extend its capabilities to include actions. A tool-enabled assistant can query a database, call an external API, retrieve a file, run a calculation, or trigger a workflow as part of responding to a user request. The model decides when to use a tool, calls it with the appropriate inputs, receives the result, and incorporates it into its response.

Tool use transforms an assistant from a text generation interface into an active participant that can interact with your systems and data in real time. This pattern is appropriate for use cases where the value of the assistant depends on its ability to take action, not just produce text.

Adding Memory

By default, language models do not retain information between separate conversations. Each session starts without any knowledge of previous interactions. For many use cases this is sufficient, but for applications where continuity matters, memory can be added to the architecture.

Session memory maintains context within a single conversation, allowing the assistant to refer back to earlier parts of the exchange without the user repeating themselves. Persistent memory retains selected information across multiple sessions, enabling the assistant to build a picture of the user's context, preferences, or prior requests over time.

Memory management on GLBNXT Platform is implemented at the application layer, with storage provided by Postgres for structured memory and vector databases for semantic retrieval of past context.

Adding Agent Capabilities

When the task a user brings to the assistant is too complex for a single model interaction, agent capabilities extend the architecture to support multi-step reasoning, planning, and execution. An agent-enabled assistant can break a complex request into subtasks, work through them sequentially or in parallel, use tools at each step, and synthesise a final response once the process is complete.

Agent architectures require more careful design than simple assistant configurations, particularly around tool access, error handling, and the boundaries of what the agent is permitted to do autonomously. For detailed guidance, see the Multi-Agent Workflows and Automation section.

Platform Components

Building an AI assistant on GLBNXT Platform draws on the following managed components.

Chat interface: a hosted, configurable conversational frontend available in your platform environment. It connects to any model endpoint in your Model Hub and supports system prompt configuration, conversation history management, and basic access control without requiring custom frontend development. For applications that require a custom interface, the platform provides the API layer that custom frontends connect to.

Model endpoints: the inference layer that serves language model responses. Your assistant connects to a model endpoint in your Model Hub. The choice of model affects response quality, latency, and capability. Your GLBNXT contact can advise on model selection for specific assistant use cases.

Vector database: required if your assistant uses retrieval-augmented generation. Weaviate and Qdrant are available in your environment. The vector database stores the embeddings of your source documents and serves retrieval queries at inference time.

Postgres: used for storing conversation history, user data, memory, and any structured application state your assistant requires across sessions.

Workflow automation: connects your assistant to external systems, APIs, and data sources. Used when your assistant needs to trigger processes, retrieve live data, or hand off tasks to downstream systems as part of handling a user request.

Compliance Considerations

AI assistants deployed in enterprise environments, particularly in regulated sectors, require careful attention to compliance from the start of the design process. GLBNXT Platform provides the controls needed to deploy assistants that meet enterprise and regulatory requirements.

Key compliance considerations for assistant deployments include:

Data access boundaries: defining clearly which data sources the assistant can access and ensuring that retrieval and tool use respect the access controls applied to those sources. Users should not be able to retrieve information through the assistant that they would not be permitted to access directly.

Audit logging: all model inference requests are logged by the platform as part of the audit trail. For regulated use cases, ensure that your assistant configuration does not strip query or response content from logs in ways that would reduce audit completeness.

System prompt governance: the system prompt defines the assistant's behaviour and scope. In regulated environments, system prompts should be version-controlled, reviewed, and approved through an appropriate governance process before deployment. Changes to system prompts should be treated as changes to the application, not as routine configuration updates.

Output review for high-stakes use cases: for assistants used in legal, compliance, medical, or financial contexts, consider whether the application design should include a human review step for outputs before they are acted upon. The assistant can accelerate and inform decision-making, but the governance model for the use case should define where human judgement remains in the loop.

Getting Started

The fastest path to a working AI assistant on GLBNXT Platform is to begin with the base architecture and extend it incrementally as your requirements become clear.

Start by configuring a chat interface connected to a model in your Model Hub with a system prompt that defines the assistant's role and scope. Test the base configuration with representative queries from your intended users. Once the base behaviour is correct, add retrieval, tool use, or memory as your use case requires.

For step-by-step guidance on deploying your first assistant, see the Your First AI Application section. For guidance on adding a retrieval layer, see RAG and Knowledge Systems.