[KongchangAI]
· 2 min read· 1,262 words

Open-Source Intelligent Business Data Assistant: A Deep Dive into the RAG+MCP+RBAC Memory-Driven Architecture

Open-Source Intelligent Business Data Assistant: A Deep Dive into the RAG+MCP+RBAC Memory-Driven Architecture

Open-source conversational BI assistant integrating RAG, MCP, and RBAC for verifiable, auditable enterprise data analysis.

This open-source conversational BI project targets enterprise data analysis with an "evidence-backed" core principle — every AI response must cite traceable SQL queries, data tables, and knowledge documents. It combines RAG (sentence-transformers + FAISS) for knowledge grounding, Hindsight-style persistent memory for cross-session continuity, MCP protocol for read-only safe database access, and enterprise RBAC with field-level data redaction. Built on FastAPI + React and compatible with both OpenAI and local models, it offers a complete, deployable architectural blueprint for teams building enterprise-grade conversational BI.

In the realm of Conversational Business Intelligence (Conversational BI), a persistent challenge for developers is: how do you make AI responses reproducible, strictly grounded in verifiable data, and equipped with persistent analytical memory across sessions? Recently, a developer shared their open-source project in the r/LocalLLaMA, r/LangChain, and r/Python communities — a memory-driven business data assistant that integrates RAG, the MCP tool protocol, and RBAC access control. It offers a comprehensive engineering reference for tackling these problems.

Project Architecture and Feature Overview

Why Enterprise BI Assistants Need "Verifiability"

When general-purpose LLMs face enterprise data analysis scenarios, the biggest risk isn't a lack of capability — it's hallucination and lack of traceability. When an AI produces a KPI value or generates a chart, if you can't trace back which table it queried, what SQL it executed, or which business rule document it referenced, that answer carries almost no credibility in enterprise decision-making contexts.

This project is built around the core principle of Evidence-Backed responses: every generated chart or KPI answer cites the exact SQL queries, data tables, and knowledge documents it used. This design transforms AI from a "black-box answer machine" into an "auditable analysis tool" — a non-negotiable requirement for enterprises deploying AI data assistants.

Memory Architecture: Giving Analysis Continuity

One of the project's standout features is what it calls Persistent Analytical Memory — a mechanism the author describes as Hindsight-style memory. It remembers users' past queries, user-specific analytical contexts, and multi-turn analytical findings across sessions.

This design addresses a core pain point of conversational BI. Traditional Q&A-style data analysis is typically stateless — every question starts from scratch, forcing users to repeatedly re-explain the background. With persistent memory, the assistant can gradually build up an understanding of a business metric across multiple conversation turns, forming a coherent analytical thread. This ability to "remember context" is exactly what separates a simple query tool from a truly intelligent assistant.

What is "Hindsight-style Memory"? The concept borrows from the cognitive science notion of "hindsight," emphasizing that the system can reflectively summarize historical interactions after the fact, rather than simply storing chat logs verbatim. In engineering terms, this type of memory typically has two layers: short-term memory (the context window for the current session) and long-term memory (persistent cross-session storage, usually written to a database or vector index). Rather than stuffing all historical messages into the context window (which is limited by token count and introduces noise), Hindsight-style memory distills key findings and user preferences into compressed semantic summaries, which are retrieved on demand when a new session begins. This design allows the assistant to gradually "learn" a particular analyst's business focus areas over time, rather than rebuilding context from zero every session.

RAG and Knowledge Grounding: Anchoring Answers to Enterprise Data

To ensure responses are strictly based on the enterprise's own data semantics, the project uses a RAG (Retrieval-Augmented Generation) approach — generating vectors via sentence-transformers and performing vector retrieval with FAISS — to semantically search across the company's table schemas, KPI definitions, and business rules.

The significance of this layer is that it prevents the model from "guessing" the meaning of enterprise metrics based on generalized knowledge. Instead, it retrieves the corresponding definitions and rules from the actual knowledge base. For example, when a user asks about a custom KPI, the system first retrieves the precise definition document for that KPI and then generates a response based on it, achieving Knowledge Grounding.

What is RAG? RAG (Retrieval-Augmented Generation) decouples "retrieval" from "generation": instead of relying on knowledge memorized during training, the model retrieves relevant snippets from an external knowledge base in real time during inference and injects them into the prompt as context for generating answers. This architecture dramatically reduces hallucination risk, since the model's output has explicit document sources that can be cross-referenced. In this project, sentence-transformers encodes text (such as table structure descriptions and KPI definitions) into high-dimensional vectors, while FAISS (Facebook AI Similarity Search) is an efficient approximate nearest-neighbor vector search library capable of finding the most semantically similar document snippets from millions of vectors in milliseconds. Together, they form a complete offline indexing and online retrieval pipeline — one of the most common technical combinations in enterprise private knowledge base Q&A scenarios today.

MCP Tool Protocol: Safe Database Access

The project introduces the Model Context Protocol (MCP) tool registration mechanism to handle database queries. Notably, it features a read-only validation design — managing tool calls through the MCP registry to ensure AI access to the database is restricted to a safe scope, preventing risks from arbitrary write operations.

As MCP rapidly gains traction in the AI Agent space as a protocol standard, its value lies in providing a standardized, controllable interface for models to call external tools. Applying it in high-sensitivity scenarios like database access, combined with read-only constraints, is a pragmatic approach to security engineering.

What is MCP? Model Context Protocol (MCP) was proposed and open-sourced by Anthropic in late 2024, with the goal of establishing a standardized protocol for interactions between AI models and external tools and data sources — analogous to what USB ports are to hardware devices. Previously, every AI application had to implement its own function calling or tool registration logic, resulting in severe interface fragmentation. MCP uses a unified tool description format (JSON Schema) and lifecycle management to enable models to discover and invoke any external tool in a consistent manner. In database access scenarios, MCP's tool registration mechanism can precisely declare the capability boundaries of each tool — for example, exposing only SELECT query interfaces while blocking INSERT, UPDATE, and DELETE — thereby enforcing read-only constraints at the protocol level rather than relying solely on application-layer business logic. This is more engineering-reliable than a traditional "add an if check in the code" approach and is also easier to audit.

RBAC Access Control: Preventing Data Leakage

The sensitivity of enterprise data makes access control indispensable. The project implements enterprise-grade Role-Based Access Control (RBAC) with field-level restrictions, defining roles such as Analyst, Admin, Manager, and Employee, with data redaction applied per role to prevent unauthorized access from causing data leaks.

Field-level data redaction means the same dataset presents at different granularities depending on the viewer's role — this is a fundamental distinction between enterprise BI systems and personal analysis tools, and a key marker of the project's "enterprise-grade" positioning.

Technology Stack at a Glance

From an engineering perspective, the project adopts a mainstream and mature technology combination:

  • Backend: Python, FastAPI, SQLAlchemy; supports SQLite / PostgreSQL
  • AI / Agent Layer: RAG vector retrieval, structured tool calling (supports OpenAI or local models)
  • Frontend: React, TypeScript, Vite, Tailwind CSS, Recharts

Worth noting is that the AI layer supports both OpenAI and local models simultaneously. This is quite appealing for enterprise scenarios that prioritize data privacy and prefer on-premises deployment — which also explains why the project sparked discussion in the r/LocalLLaMA community.

Conclusion and Outlook

The value of this open-source project lies not in any single technical breakthrough, but in the way it systematically integrates RAG, memory, MCP, and RBAC into a deployable business data assistant architecture, consistently centered around the core goals of verifiability, reproducibility, and auditability. For teams exploring enterprise-grade conversational BI, it provides an engineering blueprint well worth referencing.

The author has also solicited community feedback on the memory architecture and MCP tool integration, and is asking what features the community would like to see next. This kind of open, iterative development is precisely what keeps open-source projects vital.

#conversational BI#RAG#MCP tool protocol#RBAC#enterprise AI assistant#persistent memory#knowledge grounding#FastAPI#open-source LLM#local LLM deployment
Share:

Related articles