Article body
Full article
Abstract: The AI transformation of BI has moved beyond the “impressive demos, messy production” phase. What truly differentiates solutions is no longer model intelligence but Agent architecture—how tasks are planned, tools orchestrated, context managed, and safety ensured. This article dissects Hengshi Data Agent’s core technical architecture, from task orchestration engines and tool calling protocols to context window management and security sandbox mechanisms, providing technical decision-makers with an “Agent architecture selection” evaluation framework.
I. A Real Problem: Why a “Smart Model” Doesn’t Equal a “Usable Agent”
Calling a large language model directly for data analysis in a BI scenario runs into a series of engineering challenges.
Challenge 1: The model “free-styles” too much. You ask “What were sales in East China last month?” and the model might return a SQL query, an analytical paragraph, or even ask you first whether you want to add filter conditions. For enterprise BI, unpredictable behavior equals unusable.
Challenge 2: Broken tool calling chains. A complete analytical task requires multiple steps: first query the data catalog to find the right table, then check metric definitions to confirm口径, then generate the query logic, and finally visualize the results. If each step is left to the model’s free play, any single error breaks the entire chain.
Challenge 3: “Amnesia” in long conversations. Multi-turn conversations between users and Agents can last tens of minutes, covering multiple analytical topics. The model’s limited context window can easily be filled by conversation history, causing a cliff-like drop in answer quality.
The core design philosophy of Hengshi Data Agent is: treat the large model as a “reasoning engine,” not an “execution engine.” Reasoning (understanding intent, planning paths, matching semantics) is delegated to the model, while execution (querying data, calculating metrics, generating charts) is delegated to deterministic tool chains.
II. Overview: The Four-Layer Architecture of Data Agent
Hengshi Data Agent’s technical architecture can be abstracted into four layers, from top to bottom: Intent Understanding Layer, Task Planning Layer, Tool Execution Layer, and Context Management Layer.
The Intent Understanding Layer parses the user’s natural language input and maps it to structured analytical intent. It is not simple keyword matching but uses the NL2Metrics semantic matching engine to align the user’s vague expressions with standard definitions already established in the metrics platform.
The Task Planning Layer is responsible for breaking down intent into an executable sequence of steps. The Agent uses a “plan-execute-verify” loop, avoiding the brittleness of traditional “generate the full plan at once” approaches.
The Tool Execution Layer connects to Hengshi BI engine’s full capability stack, including data queries, metric calculations, chart rendering, report generation, and permission verification. Every tool has a strict input/output contract, and the Agent cannot bypass contracts to directly manipulate underlying resources.
The Context Management Layer maintains the Agent’s “working memory” during long, multi-turn conversations. It records “analytical state”—the current dataset being analyzed, applied filter conditions, generated intermediate results, and the drill-down path of the analysis.
III. Task Orchestration Engine: Evolved Plan-then-Execute
III.1 Why “One-Shot Planning” Doesn’t Work
A common approach in early Agent solutions: after a user asks a question, the model generates a complete execution plan at once, then executes step by step. This works for simple tasks but frequently fails in BI scenarios.
The reason is that BI analysis has strong “path dependency.” You analyze why East China sales dropped, and in the first step discover it was dragged down by the apparel category—so the second step should drill into that category’s specific SKUs. But before executing the first step, you don’t know where the second step should go. One-shot planning cannot handle this dynamic reasoning need.
III.2 Hengshi’s Approach: Layered Planning + Dynamic Re-planning
Hengshi Data Agent’s task orchestration engine uses a two-layer planning structure.
The upper layer is “macro path planning.” When receiving a user question, the Agent first makes a global judgment: Is this a query-type question (pull data directly), an analysis-type question (requires multi-dimensional drill-down), or a creation-type question (needs to generate a dashboard or report)? Based on the question type, it selects the corresponding analytical SOP (Standard Operating Procedure).
The lower layer is “dynamic step planning.” Within each SOP framework, the Agent does not generate all steps at once but plans only the current step. After executing the current step, it observes the result and then decides what to do next.
III.3 Tool Calling Protocol: Strict Input/Output Contracts
Hengshi Data Agent does not directly generate SQL but interacts with the BI engine through a “Function Call” protocol. Each tool has a clear input Schema—required parameters, parameter types and value ranges, which parameters are required vs. optional. Each tool also has a clear output Schema—the data structure it returns, what fields mean, and what it returns on errors. The Agent must strictly match the Schema before calling a tool, and the engine side also performs input validation on received calls, filtering out unexpected parameters.
IV. Context Management: The Secret Behind Agents That Don’t “Forget”
IV.1 Conversation Context vs. Analytical State
General Agent solutions typically stuff the entire conversation history into the context window. In BI scenarios, this has two problems: conversation history grows quickly (one analysis may involve dozens of interactions), and raw conversation text has low information density (lots of natural language redundancy).
Hengshi Data Agent’s approach is to separately manage “conversation context” and “analytical state.” Conversation context is kept concise, retaining only the last few turns of dialogue text to maintain natural interaction flow. Analytical state is stored in structured form with key information about the current analysis task: current dataset, applied filter conditions, generated intermediate results, and the drill-down path of the analysis. These structured states are far more compact than raw conversation text, and when the Agent needs to recall “what did I do before,” reading analytical state is far more efficient than browsing the full conversation history.
IV.2 Sliding Window + Key Event Anchors
For long analytical sessions, Hengshi Data Agent employs a hybrid “sliding window + key event anchor” strategy. The sliding window retains the complete information of the last N turns of conversation, ensuring short-range context continuity. Key event anchors are automatically extracted milestone events from the session—for example, “the user switched datasets,” “the user issued an export instruction,” “the user modified a core metric definition”—these anchor events are persistently retained even if they occurred outside the sliding window. When the Agent needs to understand the overall flow of the current session, it first looks at anchor events to form a global view, then examines details in the sliding window.
IV.3 State Persistence and Session Recovery
Analytical state can be persistently stored. If a user closes their browser halfway through an analysis today, tomorrow when they reopen it, the Agent can restore yesterday’s analytical state and continue from where it left off. This is extremely valuable for deep business analysis scenarios requiring continuous multi-day analysis (such as preparing for monthly business review meetings).
V. Security Sandbox: The Engineering Realization of the NL2Metrics Approach
V.1 Why Agents Can’t Be Allowed to Run SQL Directly
As mentioned earlier, Hengshi chose NL2Metrics over NL2SQL, with security as a core consideration. If AI-generated SQL were allowed to run directly on the database, security risks would emerge from multiple dimensions: privilege escalation (the Agent might bypass application-layer permission controls to access sensitive data directly), performance risk (an unoptimized AI-generated SQL could consume all database resources), and data consistency risk (if the Agent “misinterprets” a metric definition, different users asking the same question might get different answers).
V.2 Hengshi’s Three-Layer Security Control
Layer 1: Metric Permission Control. All data access must go through the metric semantic layer’s permission verification. The Agent cannot bypass this layer—even if the model “thinks of” a sensitive metric during reasoning, if the current user doesn’t have query permission for that metric, the tool execution layer directly rejects the request.
Layer 2: Query Parameter Allowlist. When the Agent calls data query tools, it can only pass pre-defined parameter combinations. For example, if a metric only allows querying by “region” and “time” dimensions, the Agent cannot attempt to query by “customer” dimension. The allowlist mechanism fundamentally limits the Agent’s operational boundaries.
Layer 3: Resource Quotas and Circuit Breakers. Every query initiated by the Agent has resource quota limits—maximum scan rows, maximum execution time, and maximum returned data volume. Exceeding any one of these limits triggers a circuit breaker, canceling the query and returning an error rather than continuing to wait. This protects the underlying data warehouse’s stability.
V.3 Audit Trail
Every operation initiated by the Agent—including what metrics were queried, what filter conditions were applied, and what results were returned—is completely recorded in the audit log. Enterprises can trace “who queried what data through the Agent and when,” meeting compliance audit requirements.
VI. Multi-Model Adaptation: Not Locking Into One Model, But Embracing an Ecosystem
Hengshi Data Agent’s architecture design does not bind to any specific model. Its model adaptation layer does three things.
Model Abstraction Layer. Defines a unified reasoning interface, shielding API differences between different models. GPT-4, Claude, DeepSeek, and Tongyi Qianwen can all connect to the Agent engine through the same interface.
Capability-Based Routing. Different models excel at different tasks. Deep reasoning tasks (such as multi-dimensional root cause analysis) are routed to models with strong reasoning capabilities; template-matching tasks (such as standard口径 identification and matching) can use lightweight models; generation tasks (such as natural language analytical report writing) are routed to models strong at text generation. This tiered routing strategy balances cost and effectiveness.
Private Deployment Adaptation. In local deployment solutions like HENGSHI BOX, Data Agent can directly call locally deployed open-source models (such as DeepSeek, Qwen, etc.), with all inference completed locally and data never leaving the premises—meeting compliance requirements for strongly regulated industries like financial institutions.
VII. Evaluation Framework: How to Judge a BI Agent’s Architectural Maturity
Task Planning: A mature solution should support dynamic planning rather than one-shot plan generation, multi-step reasoning rather than single-step Q&A, and explainable/intervenable task paths rather than a black box.
Tool Calling: A mature solution should have strict input/output contracts rather than free-format calling, complete auditable tool invocations, and permission verification at the tool layer rather than relying on model self-awareness.
Context Management: A mature solution should separate dialogue and analytical state, support long sessions without losing thread, and persist and recover analytical state.
Security Control: A mature solution should have metric-layer or semantic-layer permission control, query parameter allowlist restrictions, and resource quota and circuit breaker protection.
Model Adaptation: A mature solution should not be locked into a single model, should support capability-based tiered routing, and should support private deployment.
VIII. FAQ
Q1: If business metrics change frequently, won’t the NL2Metrics approach be too heavyweight?
A frequently changing metric system does put pressure on any BI solution. But the advantage of NL2Metrics is that metric changes only need to be modified once in the metrics platform, and all analyses referencing that metric (whether Agent analysis, dashboards, or reports) automatically take effect. In contrast, if a metric definition changes in an NL2SQL solution, previously generated SQL won’t automatically update, and there’s no guarantee the newly generated SQL is correct.
Q2: Can the model adaptation layer of Data Agent connect to proprietary models?
Yes. The model abstraction layer defines a unified reasoning interface, and proprietary models can connect as long as they implement this interface. The interface primarily includes text completion, function calling, and embedding as three major capabilities.
Q3: Will audit logs affect Agent response speed?
Audit logs use an asynchronous write mechanism and do not block the Agent’s main flow. Log writing is executed asynchronously after the tool call returns, with virtually no impact on user experience.
Q4: Which part of the architecture is most likely to become a bottleneck?
In most actual deployments, the bottleneck is not Agent inference speed but data query performance. If the underlying data warehouse’s query response is slow, no matter how fast the Agent is, users won’t perceive it. This is also why Hengshi emphasizes “build the metric layer first, then add Agent”—the process of establishing the metric system is simultaneously a process of data governance and performance optimization.
Conclusion
Hengshi Data Agent’s architecture design reflects a key cognitive shift in the BI industry’s approach to AI technology: don’t imagine giving the model a “universal remote control” to manipulate everything, but place the model in a carefully designed “cockpit,” giving it a clear dashboard (metric semantic layer), a safe steering wheel (tool contracts), a reliable navigation system (task orchestration engine), and an itinerary recorder that never loses data (context management).
This philosophy that “constraints bring reliability” may be the underlying code that allows enterprise-grade AI analytics to truly enter production environments.