[RFC] Introducing Assistant Core Module

[ruanyl]

trafficstars

Introduction

This RFC proposes the introduction of an Assistant Core Module into OpenSearch Dashboards (OSD). The purpose of this module is to define a set of AI-related interfaces within OSD Core - without providing any default implementation, but enables plugins to implement the interfaces and consume AI features in a standardized and decoupled manner.

With the Assistant Core Module, AI-powered features (e.g., chat assistants, discover summary, alert insight) can be built into plugins or the core UI, relying on stable APIs provided by OSD Core rather than reinventing the wheel and duplicating basic infrastructure, or depend on specific plugins such as dashboards-assistant.

Motivation

• Decoupling AI Capabilities: Currently, AI-assisted features are typically implemented as an isolated plugin within dashboards-assistant. Other plugins that wish to use AI need to depend on this plugin, or duplicate the logics. For example alert insight feature is implemented in alert plugin, but have to optionally depend on dashboards-assistant plugin, otherwise it will have to duplicate the implementations such as the agent execution API, etc.
• Standardization: Defining AI interfaces in OSD Core provides a common contract for how AI features should be integrated, facilitating cross-plugin interoperability.
• Improve reusability: Provide utility methods to build AI features across the UI and backend, plugin developers can innovate and experiment with AI features without reinventing the wheel or duplicating basic infrastructure.

Detailed Design

The above diagram illustrates the proposed architecture:

• OSD Core Module (Public/Server): Contains IAssistant , the interface defines a set of APIs without the actual implementations. And AssistantService provide a minimum set of APIs for plugins to interact with the Assistant implementation, for example getAssistant() and setAssistant().
• dashboards-assistant plugin: Provides a concrete implementation of the IAssistant interface. Other plugins can also provide their own implementations if needed.
• Other components(e.g., query-assist, alerting-dashboards, observability-dashboards): These plugins consume the assistant via getAssistant() from the core service.

Interfaces

The interface design focuses on the minimal functionality required today, in order to avoid over-engineering. This lean approach is intentional, as AI architectures and patterns in the LLM ecosystem are evolving rapidly.

IAssistant

interface IAssistant {
   // Start a new conversation or resume an existing one
   chat: () => ChatService
   
   //Invoke LLM by executing an agent or model directly
   invoke: (input: IInput) => Promise<Response>
   
   // Check if the specified agents or models are available
   // Useful for conditionally enabling/disabling UI features
   checkAvailability: (input: {type: 'agent' | 'model', names: string[]}) => Promise<{available: boolean, reasons?: string[]}>
}

type IInput = 
 | {agentName: string, params: Record<string, any>}
 | {agentId: string, params: Record<string, any>}
 | {modelId: string, params: Record<string, any>}

interface ChatService {
   // Load conversation by id or load the most recent conversation
   load: (conversationId?: string, options?) => Promise<Response>
   
   // Send message to a given conversation
   send: (conversationId: string, options?) => Promise<Response>
   
   // Regenerate a message
   regenerate: (conversationId: string, interactionId: string) => Promise<Response>
   
   // List history conversations
   list: (options?) => Promise<Response>
}

AssistantService

class AssistantService {
   assistant: IAssistant
   
   setup() {
        return {
            setAssistant: (assistant: IAssistant) => this.assistant = assistant
        }
   }
   
   start() {
        return {
            getAssistant: () => this.assistant
        }
   }
}

Future thoughts

1. Extending as an MCP Server: The Assistant Core Module could evolve into an MCP server that allows plugins to register tools, resources, and agent capabilities dynamically.
2. Built-in MCP Client: The module could also provide a utility MCP client that simplifies message routing and tool invocation, abstracting away the complexity of low-level message processing.