Article body
Full article
ChatBI lets a user access data through natural language. Agentic BI takes responsibility for a complete analytical task. A sales example makes the boundary clear. “What was East China’s revenue this month?” asks for conversational analysis. “Find the cause of the revenue decline, prepare a review, and send the priority account list to the sales team” requires planning, analysis, deliverable creation, and action. That task belongs to Agentic BI.
Analysis Agents Own the Evidence Chain
An analysis agent receives a business goal and builds a problem tree. A revenue decline might result from customer count, average order value, product mix, or refunds. The system reads metric definitions, calls query tools, compares results, and adjusts the next step based on intermediate evidence. It must retain the metric, filters, source data, and result for every step so that business users can review the conclusion.
The analysis agent also manages uncertainty. If data is missing, it should name the gap and offer a testable hypothesis. If metric definitions conflict, it should pause and ask for a decision. Enterprises need an explainable analytical process, not a confident paragraph with no evidence.
Operations Agents Connect Business Systems
An operations agent turns a conclusion into an executable task. It can create a dashboard, update a subscription, produce an account list, or call CRM, ticketing, and notification systems. Every action needs explicit parameters, permissions, and state feedback. The system must also handle timeouts, partial failure, and repeated calls without creating duplicate tasks.
High-risk actions need Dry Run. The agent first shows the target objects, impact, and expected outcome. It executes only after approval. The operations agent then returns the write result to the analysis agent, which can monitor subsequent metric changes.
Engineering Boundaries Between the Two Agent Types
| Dimension | ChatBI | Agentic BI |
|---|---|---|
| Technical role | Natural-language analytical entry point | Plannable and executable analytics-agent system |
| Coverage | Query and explanation | Modeling, querying, creation, delivery, and feedback |
| Core components | LLM, semantic layer, query engine | Agents, orchestrator, semantic layer, CLI or APIs |
| Data modeling | Prepared in advance | Created or modified within authorized boundaries |
| Visualization | Returns tables or charts | Creates complete analytical resources |
| Error handling | Reports the error or asks again | Classifies, corrects, retries, or hands off |
| Enterprise governance | Query permissions and audit | Tool permissions, approval, idempotency, rollback, and audit |
The supporting responsibilities should also remain explicit:
- The analysis agent manages hypotheses, evidence, and conclusions.
- The operations agent manages parameters, permissions, execution, and receipts.
- The orchestrator manages dependencies, timeouts, retries, and human takeover.
- The semantic layer supplies common metrics, dimensions, calendars, and business terms.
- The CLI or API supplies stable and reviewable tool contracts.
- The permission system decides what each principal can read and change.
HENGSHI CLI currently covers command domains such as data connections, datasets, semantic models, dashboards, permissions, exports, and data pipelines. These commands give each responsibility structured parameters and receipts. An agent can call the tool, and a reviewer can use the same command contract to inspect the target and impact.
Three Shared State Families
The agents need shared state to coordinate.
| State | Contents | Typical check |
|---|---|---|
| Business state | Goal, constraints, success criteria, deadline | Does the task still serve the original objective? |
| Analytical state | Hypotheses, metrics, filters, evidence, confidence | Can the conclusion be derived from query results? |
| Execution state | Dry Run, approval, progress, errors, rollback points | Can the write be retried without duplication? |
Without business state, an agent can complete steps while missing the objective. Without analytical state, an action lacks evidence. Without execution state, retries can corrupt resources during a long task.
One Collaboration Sequence
Consider “analyze the East China revenue decline and notify the responsible sales owners”:
- The orchestrator divides the task into metric confirmation, attribution, account-list generation, and notification.
- The analysis agent reads the “revenue” definition and confirms time and region.
- Query tools return customer count, average order value, product mix, and refund data.
- The analysis agent builds an evidence chain and selects the accounts with the largest impact.
- The operations agent prepares the account list and notification parameters, then runs a Dry Run.
- After the user confirms the impact, the operations agent performs the write and returns resource IDs.
- The orchestrator records the receipt, and the analysis agent checks revenue and follow-up state in the next period.
Each step needs structured inputs and outputs. Natural language works for goals and explanations. Resource IDs, permissions, approvals, and error codes should use machine-verifiable fields.
Four Production Thresholds
Idempotency
Every write task needs a stable idempotency key or duplicate-detection mechanism. A network timeout only shows that the client did not receive a result. It does not authorize creating the resource again.
Least Privilege
Tool permissions should be bound to the current task. Permission to query a metric should not grant the right to modify a dataset or send external notifications.
Layered Failure Handling
Syntax errors, missing parameters, permission denials, and downstream timeouts require different responses. Automatic correction suits parameter and syntax problems. Permission and metric-definition conflicts belong with an authorized person.
Replayable Audit
Audit records should capture the plan version, metrics, tool parameters, approver, receipt, and final result. A team should be able to replay the decision process without re-executing high-risk actions.
Procurement Should Measure Task Completion
One successful demo question does not prove Agentic capability. A procurement test should use 10 to 20 real tasks and record completion rate, human interventions, recoverability, definition consistency, and audit completeness. A platform that only recommends actions remains an analysis assistant. A platform that delivers resources and actions within governed boundaries has the engineering foundation for Agentic BI.