Beyond the Chatbox: Turning Data Agent Goals into Executable Analytics Workflows

The first experience with conversational analytics is compelling: ask a question and get data back. A few weeks later, most teams hit the same wall. Analysts still maintain datasets, build charts, watch for anomalies, and transfer conclusions into another business system. A chat interface lowers the query barrier, but it does not shorten the full chain of work.

The value of a Data Agent depends on how much real work it can complete. HENGSHI SENSE 6.2, for example, separates modeling, creation, querying, and page operations into distinct capabilities. A user can ask the system to join order and customer data, build a regional sales dashboard, and explain a decline in East China. A task planner breaks the goal into steps, then coordinates semantic modeling, metric retrieval, chart configuration, and explanation. The result is a workflow with visible progress, intermediate evidence, and a concrete deliverable.

From a Business Goal to a Task Graph

A compound request needs planning before execution. The system must identify data objects, business metrics, time ranges, and the expected deliverable. It must also make dependencies explicit. A dataset must be confirmed before a dashboard is created. A standard calendar definition must be selected before year-over-year growth is calculated. Query results must be validated before an anomaly is explained.

The task graph makes those dependencies reviewable and lets a user pause, revise, or rerun one step. A business user may only say, “Find out why East China sales dropped.” The agent has to translate that goal into metric confirmation, trend analysis, regional and product breakdowns, and anomaly attribution, retaining the input, tool call, and result at each step.

Four Capabilities, One Workflow

Capability	Primary responsibility	Typical deliverable
Modeling agent	Discover data, validate fields, configure joins and metrics	Reusable dataset or semantic model
Creation agent	Map analytical intent to charts and page configuration	Dashboard, chart, or report
Query agent	Plan and run queries, then explain the result	Data, evidence, and conclusion
Navigation agent	Navigate, change configuration, and explain the action	Visible page change and execution receipt

These are not four isolated chatbots. The task planner owns dependencies, timeouts, retries, and human takeover. Shared state lets a modeling output become the input for subsequent creation and query steps.

The Semantic Layer Defines the Answer Boundary

A language model can understand words, but it cannot infer whether a company’s revenue metric includes tax or whether an active customer means a login in seven days or a payment in thirty. The Data Agent must retrieve metric definitions, dimensions, permissions, and lineage from the semantic layer before it generates a query or configuration. Shared metrics keep dashboards, conversational queries, and APIs consistent.

The semantic layer also resolves ambiguity. When a user asks for “sales,” the system can show candidate metrics with definitions and scopes. One brief confirmation is cheaper than allowing a report with the wrong business definition into an operating review.

Headless APIs Make Execution Governable

A reliable agent does not automate mouse coordinates. It uses Headless APIs to create datasets, configure joins, build charts, and change styles. APIs can validate parameters, record audit events, and return structured errors. A page assistant remains useful for navigation and explanation; governed interfaces should handle changes to core resources.

Read and write operations need different controls:

• Queries can run within the current user’s data permissions.
• Resource creation starts with a preview of targets, dependencies, and impact.
• Changes to critical metrics or sharing scope require approval.
• Cross-system actions need idempotency, rollback, or compensation.
• Agent permissions never exceed the permissions of the current user.

Broad Context Does Not Mean Broad Authority

A Data Agent may cover many product areas, but every call remains bound to the current tenant, user, and resource policy.

Area	Covered capability	Example operation
Application creation	Dashboard and page management	Create a sales analytics dashboard
Data marketplace	Package browsing and resource discovery	Locate an East China sales dataset
Dashboard	Chart operations and interactions	Change a bar chart to a line chart
Dataset	Field and relationship management	Add a customer dimension
Data connection	Source management and connection tests	Check a MySQL connection
Data pipeline	ETL workflow configuration	Schedule a daily synchronization
Permissions	Role and data authorization	Grant read-only regional access
API management	Key management and usage statistics	Review API call volume
User management	Accounts and organization structure	Create a data analytics team

Start with One Short, Measurable Chain

A first deployment should target a frequent task with clear boundaries, such as checking core metrics every morning and producing an anomaly summary, or generating a weekly dashboard from an approved dataset. Measure task success, metric clarification, human takeover, tool retries, and audit completeness before expanding into modeling or cross-system execution.

A mature Data Agent is not defined by how human its conversation sounds. It is defined by how reliably it completes a task and how clearly a user can inspect what it did.

Engineering Details

1. A Full-Stack BI Agent

1.1 From Question Answering to Workflow Execution

A conventional Text-to-SQL assistant follows one short path:

Natural-language request → intent detection → SQL generation → database query → result

That path handles queries. It cannot create a regional sales dashboard, add year-over-year and month-over-month metrics, configure a product chart, and place KPI cards from one request.

HENGSHI SENSE 6.2 adds three execution capabilities:

• A Task Planner breaks a compound request into ordered steps and tracks progress.
• Modeling, creation, and query agents share outputs across steps.
• Agents call governed Headless APIs instead of simulating mouse input.

1.2 Four Agent Capabilities

Modeling Agent

The modeling agent discovers datasets, validates field types, configures LEFT, INNER, or RIGHT joins, and recommends relationships. For a request to join orders and customers by customer ID, it identifies the two datasets, checks key compatibility, detects an existing relationship or Cartesian-product risk, calls the semantic modeling API, and returns a preview.

Creation Agent

The creation agent converts an analytical description into a chart configuration. A regional ranking request requires the agent to locate the region dimension, resolve the sales metric, select an aggregation, sort the result, choose a chart, and create it through an API. Follow-up instructions can change the chart type or palette while preserving the data binding.

Query Agent

The query agent in 6.2 plans analysis, searches related datasets, and uses execution errors as correction signals. It can inspect syntax, missing-field, and permission errors before retrying. User corrections and frequently used dimensions inform later recommendations.

Navigation Agent

The navigation agent opens product pages, changes chart titles or presentation settings through page APIs, and explains the action to the user.

1.3 AI Runtime Enhancements

Version 6.2 streams intermediate output for long tasks, detects the user’s language, shows progress for each subtask, and supports Markdown-formatted Agent preferences. Preferences can set the default chart type, date format, and display unit. Feedback also updates frequently used dimensions and chart choices.

1.4 Product Context Coverage

Area	Covered capability	Example operation
Application creation	Dashboard and page management	Create a sales analytics dashboard
Data marketplace	Package browsing and resource discovery	Find an East China sales dataset
Dashboard	Chart operations and interactions	Change a bar chart to a line chart
Dataset	Field and relationship management	Add a customer dimension
Data connection	Source management and connection tests	Test a MySQL connection
Data pipeline	ETL workflow configuration	Schedule a daily synchronization
Permissions	Role and data authorization	Grant regional read-only access
API management	Key management and usage statistics	Review API calls from last week
User management	Accounts and organization structure	Create a data analytics team

2. Metric Asset Governance

2.1 The Engineering Problem

A medium or large enterprise may maintain hundreds or thousands of metrics across departments, systems, and reports. Finance and sales can use different definitions for revenue. Analysts may not know where a metric is defined or who owns it. Duplicate definitions accumulate, and one metric change can affect many reports.

2.2 Metric Favorites

HENGSHI SENSE 6.2 supports up to 1,000 favorites per user. An inverted index searches names, topic paths, and descriptions. Each favorite shows its topic path, such as Sales Management > Regional Analysis > East China Sales, and links to the metric detail or a dashboard that uses it.

2.3 Search Across Product Contexts

Metric management, the metric marketplace, and dashboard editing use one search index. The current product context changes result ranking and available actions. Search results preserve the user’s terms, return up to 1,000 rows, and use pagination and lazy loading for large result sets.

3. Data Marketplace and Platform Administration

3.1 Marketplace Controls

Folders and data packages can carry a pin weight for list ordering. A locked data package records its lock state and owner, and write APIs reject changes until the locking user unlocks it. Dataset copy operations inspect metric dependencies and copy the required atomic metrics across applications.

3.2 Administrative Controls

Version 6.2 adds an application-level watermark switch and a template engine for user name, email, phone number, and system time. A global sorting configuration controls default list order across product modules.

4. What the 6.2 Architecture Changes

HENGSHI SENSE 6.2 defines a Data Agent that can execute modeling, creation, query, and administration tasks through platform APIs. Metric favorites, shared search, and cross-application synchronization make governed metrics easier to reuse. Large exports, watermark controls, and package locking support production deployments. Headless APIs provide the validation, audit, and structured failure handling required for agent execution.

Source and Verification Note

Internal material was used to organize HENGSHI capabilities and engineering methods. Competitor and version information was checked against official pages available on August 26, 2026. Features can vary by release, region, license, and deployment mode; confirm them in the target environment before purchase or publication.

Further reading: HENGSHI SENSE Product and Technology White Paper.