From Conversational Data Q&A to Reviewable Action: An Engineering Approach to Collaboration Between HENGSHI Data Agent and Tool Execution

Abstract: Enterprise analytics often involves understanding questions, querying metrics, creating charts, and delivering assets at the same time. Connecting these steps requires reviewable definitions, explicit operational interfaces, and clear responsibility boundaries. HENGSHI Data Agent places data Q&A, modeling, report creation, and intelligent reporting within BI semantics and permission context; HENGSHI CLI (whose public command is hbi) provides a BI engineering execution plane for tool-calling Agents, supporting previews and result echoing. In this collaboration, Data Agent can perform analysis and creation; when an external Agent needs to operate BI assets, the CLI provides the standard execution entry point. Business owners define objectives, review high-impact actions, and accept the results.

I. Start with ChatBI, but Do Not Treat ChatBI as the End Point

Conversational data Q&A has significantly lowered the barrier to analysis. In HENGSHI, Data Agent can independently determine intent from user input, decompose requirements, and conduct hybrid retrieval across data marts, application marts, and application-creation assets within the data scope that the signed-in user is permitted to access. For complex questions, it initiates one or more data queries as needed. It can also read the signed-in user’s attributes and current page context, so questions such as “How did my department perform this month?” or “Explain this dashboard” do not necessarily begin from scratch.

This does not mean natural language can bypass data governance. The quality of data Q&A still depends on metrics, field descriptions, and business terminology being captured in advance. HENGSHI’s NL2Metrics path is based on its modeling and semantic layer: it maps concepts such as repurchase rate, GMV, budget, and fiscal year to reusable metrics, instead of having the model assemble definitions ad hoc in every conversation. Data-set knowledge management can maintain intended usage, implicit rules, synonyms, and domain-specific terms; vectorization and “intelligent learning” can assist retrieval, but learned content must be manually inspected, added, removed, or edited. The official manual also explicitly notes that large-model output is uncertain and that the same input does not guarantee exactly the same response.

Accordingly, the relationship among ChatBI, Data Agent, and tool execution should be progressive rather than substitutive: ChatBI is suitable for immediate exploration; Data Agent can decompose complex questions into an analytical process and assist in creating metrics, dashboards, and data interpretations; and the tool layer places clearly specified asset operations on a reviewable execution path. What enterprises truly need to manage is the definition, permission, approval, and receipt at every step.

II. Define Collaboration Boundaries by “Analytical Responsibilities” and “Execution Responsibilities”

Responsibility layer	Capability foundation in HENGSHI	Suitable outputs	Checks to retain
Analysis and expression	Data Agent covers data Q&A, modeling, reports, and intelligent reporting; it can decompose by intent and query multiple times.	Problem decomposition, metric explanations, data interpretation, and report or dashboard drafts.	Business owners review metric definitions, data scope, anomaly explanations, and conclusion wording.
BI engineering execution	hbi organizes connections, data sets, HQL, dashboards, permissions, and related capabilities into an Agent-oriented command surface, with structured output, --dry-run, and SSE echoing.	Verifiable plans, BI asset changes, authorization operations, or execution results in automated flows.	Read state first, preview before execution, then execute; changes must follow existing roles, spaces, and publication processes.
Integration and orchestration	Data Agent can be integrated through iframe, JS SDK, or API; the official website lists collaboration with Agent platforms such as Dify and Coze and compatibility with SDK/API/iframe integration.	Data-Q&A experiences in proprietary pages, or calls orchestrated by enterprise backends, multi-Agent systems, or workflows.	Callers remain responsible for identity propagation, authorization scope, failure handling, and business-process governance.

This division describes engineering responsibilities. In an actual project, the same business assistant may analyze first and call tools afterward, or an enterprise orchestration service may call Data Agent and hbi separately. The model is responsible for understanding, decomposition, and generation, while tools and backend services carry out queries and changes. Each step should return inspectable results, with business owners retaining control over key decisions.

III. The Operating Mode and the Integration Method Are Different Things

When designing a solution, answer “who continuously drives the interaction” before answering “how the system is integrated.” Data Agent’s Agent mode is suitable for data-Q&A experiences that need continuous execution, step-by-step feedback, and a retained run process. Workflow mode is suitable when backend workflows centrally drive the process, manage execution logic, and stabilize delivery. iframe, JS SDK, and API are different integration methods: iframe reuses a complete page; JS SDK keeps the enterprise’s own page shell while embedding HENGSHI frontend capabilities; API is better suited to orchestration by enterprise backends, multiple Agents, or workflows. API is not equivalent to Workflow, and an iframe does not determine the operating mode. Separating these two sets of concepts clarifies authentication, session ownership, frontend and backend responsibilities, and troubleshooting boundaries.

IV. Walk Through “Discovery—Validation—Delivery—Receipt” with a Sales-Analysis Case

Suppose a sales leader proposes: “Sales in East China are below plan this month. Identify the main changes and give me a dashboard draft that I can discuss with the regional team.” A sound workflow should not generate a conclusion directly, much less directly change pricing or customer strategy. It can begin with the following chain.

Figure 1: Collaboration from analysis to action; external business actions require interface and approval integration

1. Confirm the context first: read the current application, accessible data sets, published sales-amount and target-attainment metrics, and the user’s organizational scope. If “East China” has multiple organizational definitions, the Agent should ask for clarification or list the filters it uses.
2. Then run decomposition queries: examine variances and their contributions by dimensions such as time, city, product line, and channel, and record the metric definitions and time window used by the query in the result. Here, “contribution” describes changes in data groups; it does not automatically prove causality.
3. Produce a discussable draft: present verified data findings, hypotheses to be validated, and information recommended for further collection separately. Data Agent can assist in generating an interpretive report or dashboard draft; the business owner decides whether to adopt the conclusion and layout.
4. Enter delivery validation: if a dashboard is to be created or adjusted, the tool layer first reads the asset state and generates a plan. For operations that support previewing, it first confirms the impact scope; for the rest, it first verifies the plan and target resources. Only then should an authorized person approve the actual change and return the result to the requester.

Read accessible data and metric definitions
Analyze sales variances; list data findings, supporting evidence, and hypotheses to be validated
Generate a dashboard draft and a list of resources proposed for change
Inspect existing assets; run dry-run for commands that support previewing
If the checks pass and the authorization or approval requirements for the action have been met:
    Submit the change through a tool supported by the current version
    Read back the asset and confirm that the result matches expectations
    Record the asset link, execution identity, time, and completion status
Otherwise:
    Retain the draft and return the failure reason or conditions that must be added

Here, failure status is also part of the delivery. A missing metric definition, lack of user access, delayed data refresh, a preview that reveals an overwrite of an existing asset, or a missing owner approval should all stop the process at the draft or preview stage. At a minimum, the receipt should state which definitions were used, who approved what, which asset the change affected, when it was completed, and how to locate logs or roll back when it fails. Only then can an Agent’s “done” be verified jointly by people and systems.

V. Why the Tool Layer Needs Previewing, Structured Output, and Human Confirmation

HENGSHI CLI is intended for coding-oriented or persistent Agents that can invoke shells or tools. It centralizes common BI engineering actions under the hbi command. Its role is not to replace the HENGSHI SENSE page, but to serve as a bridge: it connects step orchestration from Agents or automated flows above to real business actions in the HENGSHI SENSE backend below, including connection, query, modeling, authorization, and publication. Official documentation lists command domains for data connections and data-set ingestion, HQL/HE queries, dashboard and element creation, permission operations, environment checks, and supporting skills.

For authorization, deployment, migration, and other operations that support previews, --dry-run can first be used to inspect the preview; the concrete scope is governed by the help for the current subcommand. Structured output such as JSON, YAML, and tables is convenient for people and other systems to record and review; SSE echoing enables changes made outside the UI to return to the frontend experience. The CLI page also states that tokens enter the system Keyring and that OAuth and enterprise SSO are supported, avoiding the need to write sensitive credentials into local configuration. These mechanisms make operational impact and execution results easier to inspect and help catch errors in advance.

Projects should still follow least privilege, environment isolation, change approval, audit trails, and rollback plans. The exact permission granularity in different versions, deployment modes, and enterprise processes should be verified item by item during project acceptance; it should not be broadly replaced by a claim that everything is “fully automated.”

VI. External Business Actions Are an Integration Design, Not an Out-of-the-Box Automation Promise

Proposed action	What analysis can trigger	Conditions that must be completed before implementation
ERP purchase requisition or transfer	Generate recommendations or requisition drafts from reviewed inventory, demand, and safety thresholds.	An ERP interface, material-master-data mapping, an approval chain, idempotent handling, exception rollback, and purchaser confirmation.
CRM price changes or customer follow-up	Produce a candidate customer list, communication recommendations, or quotation drafts from sales analysis.	A CRM write interface and field rules, quotation permissions, customer compliance checks, sales-owner approval, and an operation receipt.
Account risk control and predictive maintenance	Organize anomaly patterns, threshold triggers, or equipment-health signals into items pending verification.	Validated rules or models, business-system interfaces, human review, emergency-response procedures, and audit requirements.

HENGSHI provides data-intelligence capabilities that can be integrated and extended: Data Agent’s API access is suitable for orchestration by enterprise backends, multi-Agent systems, or workflows; BIPaaS embedding mechanisms address SaaS multi-tenancy, single sign-on, and fine-grained permission control. Actions such as “automatically place a purchase order,” “adjust a CRM price,” “freeze an account,” or “schedule maintenance” are all process designs created after an enterprise connects analytical results to external systems. They require authorization for the target-system interface, as well as business-side configuration of approvals, responsible owners, failure compensation, and audit rules. Making these boundaries clear is more conducive to expanding automation progressively in high-impact scenarios.

VII. Start with One Verifiable Scenario and Gradually Form a Closed Loop

Start with a scenario that has both a stable metric system and a clear business owner, such as a weekly sales review. In the first phase, complete metric and synonym governance and confirm data permissions and the data-refresh cadence. In the second phase, allow Data Agent to decompose questions, interpret data, and produce dashboard drafts within that scope, with the business team reviewing the results. In the third phase, connect approved BI asset operations to the hbi preview-and-echo path. Only after draft quality, approval timeliness, and exception handling have stabilized should the organization assess whether to connect notifications, tickets, or other external actions to established enterprise processes.

The value of HENGSHI Data Agent is to let enterprises analyze and create more naturally on top of semantic metrics, user permissions, and page context. The value of HENGSHI CLI is to give Agent operations on BI assets a reusable tool interface and a reviewable engineering process. Together, they can connect insight, delivery, and business processes into an explainable, verifiable, and governable workflow.