Inside the Function Calling Engine: How Hengshi Data Agent Executes Tools

Article body

Full article

14 min read

Introduction

The defining capability of an AI Agent is action.

A language model that only talks behaves like an advanced search engine: you ask, and it answers, but the answer cannot change a system. An Agent can analyze a problem, invoke tools, perform operations, and change system state.

Function Calling supplies the technical bridge between language and action. It turns a language model from a text generator into an execution planner.

Hengshi Data Agent includes a complete Function Calling engine that handles tool registration, intent matching, argument generation, execution, and result interpretation. This article explains each layer of that engine.

1. Function Calling Fundamentals

1.1 From a Prompt to a Function Call

Function Calling asks the LLM to produce a structured call request instead of a natural-language answer.

Consider a user asking, “What were East China’s sales last month?”

Without Function Calling, the LLM might answer, “East China generated about RMB 12.5 million in sales last month.” That number could be fabricated.

With Function Calling, the LLM produces a structured request:

Function: query_metric
Arguments: { metric: "sales", time_range: "last_month", region: "east_china" }

The system invokes the query function, receives the verified result of RMB 12,563,400, and asks the LLM to present that result to the user.

This changes the LLM’s role. It selects tools and generates arguments; the tool result determines the answer. The model’s parameterized knowledge no longer supplies the business fact.

1.2 The Standard Function Calling Flow

A complete Function Calling flow has five steps:

Step 1: Register tools. The system registers the available functions. Each definition includes a name, a description, and an argument schema expressed as JSON Schema.

Step 2: Match intent. The LLM compares the user’s request with the function descriptions and chooses a function. The quality of those descriptions has a direct effect on selection accuracy.

Step 3: Generate arguments. The LLM extracts values from the request and formats them according to the JSON Schema. It may convert “last month” into a date-range expression and “East China” into a regional filter.

Step 4: Execute the function. The system passes the generated arguments to the function implementation, which runs inside a secure sandbox.

Step 5: Interpret the result. The LLM turns the function result into a user-facing response. It describes structured output such as a table or chart and explains errors or retry options when execution fails.

2. The Hengshi Data Agent Tool Registry

2.1 Tool Schema Design

Every Hengshi Data Agent tool follows a standard schema with three groups of fields.

Basic information:

Tool name: a globally unique identifier
Display name: a readable name shown to users
Description: an explanation of the tool’s purpose and applicable situations; this field has the greatest effect on intent-matching accuracy

Argument definitions:

Argument name, type, and required status
Argument description, including its meaning and how the LLM should derive it from the request
Enum constraints for values such as bar chart, line chart, or pie chart
Default values when the user omits an argument

Return format:

Return type, such as a data table, scalar value, chart configuration, or file link
Return schema for structured fields

2.2 Tool Categories and Levels

Hengshi Data Agent groups tools into four functional areas.

Data query tools:

query_dataset: query detailed records with dataset and filter conditions
aggregate_metric: aggregate a metric by one or more dimensions
compare_periods: compare time periods, including year-over-year and period-over-period analysis
rank_entities: rank entities by a metric

Analytical reasoning tools:

detect_anomaly: detect anomalies in a time series
find_correlation: find correlations between two metrics
segment_analysis: segment data by a dimension
root_cause_analysis: attribute changes in a metric to contributing factors

Visualization tools:

create_chart: generate a chart
compose_dashboard: combine charts into a dashboard
apply_chart_style: apply a chart style template

Collaboration tools:

export_report: export a report as PDF, Excel, or an image
send_notification: send analysis results to a notification channel
create_alert: create a data-alert rule

2.3 Dynamic Tool Registration

Users do not all receive the same tool set. Hengshi builds the available tool list at runtime from the current user’s role, permissions, and tenant.

A business user might see query, visualization, and export tools. An administrator can also see tools for alert creation and subscription management. This runtime filtering enforces access control while reducing the LLM’s selection space, which improves intent matching.

3. Intent Matching and Argument Generation

3.1 Selecting Multiple Tools

One request may require several tools. The request “Analyze why sales declined last month and generate a report” needs root-cause analysis followed by report export.

Hengshi Data Agent uses three selection patterns:

Serial dependency detection: If tool B needs the output of tool A, the LLM marks a serial dependency. It plans the call to A first and generates the call to B after A returns.

Independent parallel detection: If two tools have no dependency, as in a request to query East China and North China sales at the same time, the engine runs both calls in parallel to reduce the total wait.

Conditional branch detection: A later action may depend on an earlier result. For “Trigger an alert if sales fell by more than 10%,” the LLM generates a condition and the engine evaluates that condition before entering the alert branch.

3.2 Improving Argument Extraction Accuracy

Argument extraction presents several recurring sources of error.

Ambiguous time expressions: “Last month” could mean the previous calendar month or a rolling 30-day window. “The past week” may include today or exclude it. Hengshi embeds time-parsing rules in the argument schema. The LLM preserves the original expression, and a dedicated date parser converts it into a standard range.

Ambiguous entity names: “East China” may cover different areas in different companies. An entity map in the metrics semantic layer resolves the user’s wording to the company’s standard region code.

Missing units: A user who says “sales of 1,250” may mean RMB 1,250, RMB 12.5 million, or 1,250 thousand. Hengshi records the default unit in the argument description and requires every returned value to include its unit.

3.3 Argument Validation and Error Recovery

LLM-generated arguments can contain type errors, out-of-range values, or invalid enum members. Hengshi applies two validation layers.

Schema validation: The engine validates arguments against JSON Schema before invoking the function. This layer rejects wrong types, missing required fields, and invalid enum values.

Semantic validation: Each tool then evaluates business rules. A request for month 13 of 2025 may pass syntax checks but fail because the month does not exist. A negative sales amount may be numerically valid but violate the tool’s business constraints.

Error recovery: The system returns validation details to the LLM instead of exposing the first error to the user. If the LLM generates region: "East China" while the system requires region: "east_china", the engine returns the accepted values, such as east_china and south_china. The LLM corrects the argument and retries.

4. The Function Execution Engine

4.1 Execution Sandbox

Functions run in an isolated sandbox with explicit security controls.

SQL injection protection: Query functions pass arguments as parameters instead of concatenating strings. SQL fragments embedded in a user’s message cannot enter the query statement.

Resource limits: Each call has a 30-second CPU limit, a 512 MB memory limit, and a 10,000-row result limit. The engine stops calls that exceed these limits and returns a readable error.

Network isolation: Collaboration tools such as notification delivery require outbound network access. They connect through an allowlisted proxy, which blocks data transmission to unauthorized addresses.

4.2 Asynchronous Execution and Streaming Results

Large queries and report exports can take too long for a synchronous response. Hengshi supports asynchronous execution:

A tool returns a task ID at once, and the interface shows a progress message such as “Query in progress…”
The job runs in the background and pushes results over WebSocket when it finishes
A long-running job such as a full export can send its download link through a notification channel

4.3 Result Caching and Reuse

The engine can reuse a result when two users submit the same request or one user repeats a similar request within a short period:

Cache key = function name + argument hash
The time to live depends on tool type: 5 minutes for query tools, 30 minutes for analytical tools, and no caching for export tools
A cache hit returns the result without running the function again

5. From Individual Tools to Agentic Workflows

5.1 Tool-Chain Orchestration

A single call handles a simple task. Complex analysis needs several tools working together. Hengshi Data Agent supports three tool-chain structures.

Linear chain: Tool A → Tool B → Tool C. Each output becomes the next input. A typical flow queries data, detects anomalies, generates a report, and sends a notification.

Branching chain: The result from tool A chooses B or C. A flow may query sales, check whether the decline exceeds a threshold, and either trigger an alert or record a normal status.

Looping chain: The result from tool A determines whether to call A again. A paginated query checks for another page, requests it when present, and merges all pages when complete.

5.2 Dynamic Replanning

The Agent builds the tool chain during execution instead of following a fixed workflow. An unexpected result prompts it to reassess the remaining steps.

Suppose the Agent plans to query sales for “South China” but receives no records. The area may have no data, or the name may not exist in the system. The Agent changes its plan and queries the list of configured regions. It finds that the standard name is “South China Division,” corrects the argument, and runs the sales query again.

This adaptive replanning separates Agentic BI from a fixed BI workflow. The Agent can adjust to observed results during execution.

6. Results and Optimization

6.1 Tool Selection Accuracy

Hengshi Data Agent achieves 94.7% tool-selection accuracy on its internal test set. Analysis of the remaining errors identifies three primary causes:

Unclear tool descriptions: The LLM hesitates between tools with similar functions. More precise descriptions now state both applicable and excluded situations.
Multiple-tool confusion: A request needs several tools, but the LLM omits one. A self-review instruction asks it to check for missing calls.
Argument extraction errors: Time expressions and entity names cause extraction failures. Richer argument descriptions and semantic validation address these cases.

6.2 End-to-End Latency

Function Calling latency has three components:

LLM inference for intent matching and argument generation: 1.2 seconds on average
Function execution: 0.8 seconds on average for query tools and 3 to 5 seconds for analytical tools
Result interpretation and response generation: 0.6 seconds on average

Hengshi reduces this latency through three measures:

Shorter tool descriptions reduce the number of tool-list tokens in the prompt
Independent calls run in parallel, so total latency follows the slowest call instead of the sum
Cached results skip execution for frequent requests

7. Conclusion

Function Calling gives AI Agents the ability to act. It combines an LLM’s language understanding with the deterministic execution of software tools. The LLM interprets intent, selects tools, and generates arguments; the tools perform exact operations and return facts.

The Hengshi Data Agent Function Calling engine centers on three design choices:

Dynamic tool registration: Role and permission checks limit each user’s tool space and improve selection accuracy
Multi-tool orchestration: Linear, branching, and looping chains cover complex analytical tasks
Dynamic replanning: The Agent adapts later steps to the results it observes during execution

A BI system crosses from intelligent question answering into intelligent agency when it can orchestrate tool chains instead of issuing isolated function calls.