Enterprise ChatBI in Practice: Building a Decentralized Data Analytics Agent with LangGraph and Multi-MCP

ChatBI: Making Data Analysis as Simple as Stating Your Requirements

In the wave of enterprise-grade large language model adoption, ChatBI (Conversational Business Intelligence) stands out as a direction brimming with potential — yet full of engineering challenges. Bilibili creator Wesley breaks down exactly how to build a ChatBI agent from scratch in his enterprise LLM tutorial series, centering the tech stack on two of today's hottest approaches: Multi-MCP (Multi-Model Context Protocol) and the enterprise agent framework LangGraph.

Wesley holds a Master's degree in Mathematics from UCLA and brings eight years of AI industry experience, with research spanning intelligent customer service, recommendation systems, and LLM-based agents. He's candid about the fact that ChatBI applications aren't common in the market — major platforms have dabbled in the space but rarely promote it heavily, which is itself a signal that real engineering challenges lurk beneath the surface. Understanding where these agents excel and where they fall short matters far more than blindly stacking features.

The Pain Points of Traditional Dashboards and Three-Tier Analytics Workflows

To appreciate ChatBI's value, you first need to understand what it's replacing. Wesley uses a common enterprise data dashboard as his example: these dashboards look polished, work well for external presentations, and suit fixed business structures — but their drawbacks are equally obvious. Every time you need a new metric column or a different visualization, you have to run the full development cycle again. They simply can't handle personalized or dynamic queries. Want to see "data without order IDs" or "average completion time"? A static dashboard usually can't help — you're stuck manually exporting data and running your own calculations.

The deeper problem lies in the traditional enterprise three-tier analytics workflow. The business stakeholder (operations team or an executive) raises a request, which gets picked up by a product manager or data analyst who pulls figures from a database, ES index, or Excel file. For something like sales forecasting, the task gets escalated again to an ML engineer for secondary modeling. Wesley identifies three chronic pain points in this chain:

• Requirements are rarely clear the first time: Stakeholders often revise their ask after seeing initial results, sending feedback rippling back through the chain — sometimes multiple times.
• Multi-person handoffs drag out timelines: A single analysis touches multiple people, inflating delivery cycles.
• Low-frequency requests waste headcount: Ad hoc queries like "compare this year's Singles' Day sales to last year's" get a dedicated development effort, only to be glanced at once. The return on investment is terrible.

The Core ChatBI Pipeline: From Semantic Understanding to Intelligent Summarization

The design philosophy behind a ChatBI system is to compress that three-tier workflow into an autonomous system where users simply state what they need. Whether it's a business operator, an analytics manager, or a modeling engineer, everyone interacts through natural language — for example: "Help me forecast sales for a specific product over the next three months."

The first gate is a semantic understanding module that handles intent routing: small talk goes to free-form generation, image requests go to an image-generation agent, and data analysis requests go to the data analytics agent. Through a pre-orchestrated agent workflow graph, each request gets routed to the appropriate downstream node.

For data analysis requests, the critical step is NL2SQL — converting natural language into SQL queries to retrieve data, which effectively automates the data-pulling function traditionally performed by analysts. Once data is retrieved, simple requests can be resolved immediately with a report, document, or one-line answer. Complex requests like sales forecasting proceed to the NL2Python stage, where machine learning or deep learning algorithms build a predictive model from historical data, generate charts, and produce an intelligent summary to return to the user.

Wesley emphasizes that the entire system operates as a "highly flexible autonomous decision-making pipeline": it independently judges whether data retrieval is needed, whether modeling is required, and whether the current data is already sufficient to answer the question — outputting results as charts, documents, or text as appropriate.

NL2SQL (Natural Language to SQL) is the technology that converts a user's natural language description into an executable SQL query — one of the core capabilities of any ChatBI system. The technical challenge is significant: the model must understand business semantics (e.g., mapping "Singles' Day" to specific date ranges), correctly map table and column names (which depends on schema injection), and handle complex SQL constructs like multi-table joins, aggregate functions, and conditional filters. Enterprise deployments typically inject database schemas, column comments, and domain-specific vocabularies into the prompt as context, or use RAG to retrieve relevant schema fragments and improve generation accuracy. NL2SQL accuracy is the single biggest determinant of ChatBI usability — and the core engineering challenge that makes this space difficult to crack.

NL2Python takes this a step further, converting natural language requirements into Python data analysis or machine learning code. It handles scenarios that SQL alone can't address, such as predictive modeling and statistical analysis. Generated code typically runs in a sandboxed environment, with results passed back to the main workflow for chart generation and summary output. Security isolation is a critical engineering consideration here.

From Centralized Multi-MCP to Decentralized LangGraph

The technical evolution path in the course is genuinely instructive. Wesley starts with a simple data analytics agent built using the traditional Multi-MCP + centralized LLM scheduling approach. This method requires minimal code and is fast to prototype — but its weaknesses are equally apparent: poor stability and limited scalability. When a single large model acts as the sole central scheduler coordinating multiple MCP tools, it starts to buckle under the load. As the number of tool calls grows, the model struggles to keep up, and scheduling chaos ensues.

To address this, the course's centerpiece is a LangGraph + decentralized architecture refactor of the ChatBI system. Compared to the centralized approach, a decentralized multi-agent framework delivers dramatically better stability and scalability. Wesley highlights a key advantage of LangGraph: new capabilities can be "plugged in indefinitely." Beyond data analytics, you can attach a RAG (Retrieval-Augmented Generation) module — when the system detects a domain-specific question, it routes to the RAG agent for retrieval-augmented response generation.

This means the "BI" in ChatBI is just the entry point. The underlying architecture is essentially an infinitely extensible enterprise agent platform.

MCP (Model Context Protocol) is an open standard proposed by Anthropic in late 2024, designed to give large models a unified tool-calling interface. Developers can package capabilities like database queries, file operations, and API calls as MCP services, which models can uniformly discover and invoke through the protocol — no custom integration needed per tool. Multi-MCP means running multiple such services simultaneously. In centralized scheduling, the LLM acts as both "brain" and "central dispatcher," planning tool call sequences, parsing return values, and deciding next steps — all within a single inference pass. As the number of tools grows and call chains lengthen, context window pressure and reasoning complexity skyrocket, leading to scrambled call ordering or the model "forgetting" its original objective midway through. This is the fundamental reason centralized architectures suffer from poor stability.

LangGraph is a framework within the LangChain ecosystem specifically designed for building stateful multi-agent workflows. It uses directed graphs (DAGs or cyclic graphs) to explicitly orchestrate agent collaboration. Each node represents an independent agent or processing step; edges represent data flow and control flow; and routing logic is determined by code rather than model inference. This "decentralized" design distributes scheduling responsibility away from a single model and across the graph structure itself. Each agent focuses only on its own subtask, dramatically improving the overall system's predictability and fault tolerance.

Who Should Pay Attention to This Architecture

The audience for this ChatBI system is broad: data analysts and data mining engineers can use it to work more efficiently, while operations staff and managers can get analysis results directly through natural language — no more navigating the long chain of requirements handoffs.

For teams exploring LLM deployment, this case study offers a clear engineering-first blueprint: play to the strengths, and know the limits. Hand off high-frequency, standardized tasks to ChatBI for automation; route genuinely complex scenarios to human judgment as a safety net. This kind of pragmatic, human-in-the-loop philosophy is arguably more aligned with real enterprise needs than chasing the grand narrative of full automation.

RAG (Retrieval-Augmented Generation) refers to retrieving relevant document fragments from an external knowledge base before the LLM generates a response, injecting them as context so the model can answer questions about private or real-time knowledge beyond its training data. In a ChatBI architecture, the RAG module can handle unstructured content Q&A — policy lookups, product documentation, historical reports — the kind of requests that can't be answered with a SQL query against a database but can be retrieved from a document library. Plugging RAG in as an independent agent node within the LangGraph workflow exemplifies the decentralized architecture's design philosophy of "add capabilities on demand": new functionality requires only adding a graph node and a routing condition, without refactoring existing pipelines. System complexity scales linearly and remains controllable.

Summary

The value of Wesley's ChatBI tutorial series isn't in showing off flashy technology — it's in connecting a real enterprise pain point (the inefficiency of the three-tier analytics workflow) with two cutting-edge technologies (Multi-MCP and LangGraph) into a complete, coherent engineering solution. The progression from a simple centralized scheduling prototype to a stable, decentralized multi-agent architecture is clear and methodical, making it a genuinely useful reference for developers looking to put LangGraph, MCP, RAG, and NL2SQL into real-world production.