Understanding AI Agents Through Excel: The Essential Difference Between Skills and Tool Calls

Introduction: From Tool Calls to Skills

In AI Agent development, "Tool Call" and "Skill" are two core concepts. Many developers tend to conflate them, but in reality, a Skill is a higher-level business orchestration built on top of tool calls. This article uses a practical Excel agent case study to deeply analyze how Skills work and their API call chains, helping you truly understand the essential difference between these two concepts.

Tool Calls: Atomic, Single-Purpose Operations

In previous articles in this series, we covered the basic logic of tool calls: when an agent sends an API request to a large language model, it includes a list of available tools; the model returns which tools to call and with what parameters based on user intent; the agent executes the tools locally and returns the results to the model or displays them directly.

Tool Calling (also known as Function Calling / Tool Use) has been one of the most significant capability advancements in the LLM API space since 2023. OpenAI first introduced Function Calling for GPT models in June 2023, followed by Anthropic's Claude, Google's Gemini, and other major models. The core mechanism works as follows: available tools are declared in the API request using JSON Schema format—including their names, descriptions, and parameter structures—and the model determines during inference whether a tool call is needed, returning the tool name and parameter values in structured JSON format. This mechanism evolved large models from pure text generators into decision engines capable of interacting with external systems, forming the technical foundation for building AI Agents.

Taking the Excel agent as an example, its tools are quite basic:

get_cell_value: Retrieve the value of a single cell (data reading)
set_cell_value: Set the value of a specified cell (data writing)

Comparison of Tool and Skill definitions

These tools are characterized by their atomicity—each tool performs only one minimal-granularity operation. Atomicity is a classic design principle in software engineering, originating from the ACID properties of database transactions. In AI Agent tool design, atomicity means each tool is responsible for only one indivisible, minimal unit of operation. This design follows the Unix philosophy of "do one thing well," delivering high composability and testability. Atomic tools can be freely combined like LEGO bricks, rather than designing one massive multi-function tool. This is also consistent with the Single Responsibility Principle (SRP) in microservices architecture.

For example, if you ask "What number is in cell AI10?", the agent calls the get_cell_value tool and returns "123"—the entire process involves just one simple tool call.

Skills: Business Orchestration of Tool Calls

What Is a Skill?

A Skill is essentially a form of business orchestration over tool calls—or put another way, a Standard Operating Procedure (SOP). It combines multiple atomic tool calls with carefully designed prompt templates to accomplish a more complex business objective.

Standard Operating Procedure (SOP) is a core concept in enterprise management and industrial production, used to break down complex processes into repeatable, standardized steps. In the AI Agent domain, the SOP concept has been adopted to describe the orchestration logic of Skills, which shares similarities with workflow orchestration in RPA (Robotic Process Automation). The key difference is that traditional RPA workflows follow hard-coded deterministic paths, whereas Skill orchestration in AI Agents leverages the reasoning capabilities of large models to achieve flexible orchestration—the model can dynamically determine the order and parameters of tool calls based on context, providing a degree of fault tolerance and adaptability.

In this Excel agent, four Skills are defined. A typical example is "Data Summary":

Description: Summarize a selected data range by calculating the sum, average, maximum, and minimum values
Tools involved: sum_range (summation), average_range (averaging), etc.
Prompt template: "Please summarize the data range {range}, calculating the sum, average, minimum, and maximum, and return the results"

As you can see, a single Skill requires coordinating multiple tool calls and uses a prompt template to guide the large model in correctly orchestrating the execution sequence.

Practical Demo: Execution Process of the Data Summary Skill

When we ask the agent to "summarize the data from AI10 to AI12," it needs to read the data from three cells and then calculate the sum and average separately.

Data summary results display

The final results show: sum is 202, average is 67.33. One detail worth noting—the maximum and minimum values couldn't be retrieved because the tool list didn't include tools for calculating max and min values. This perfectly illustrates an important principle: a Skill's capability boundaries are determined by the capabilities of its underlying tools.

Another more complex Skill is "Draw Chart": drawing a bar chart based on data from AH10 to AI12, involving multiple steps such as data reading, label parsing, and chart rendering. This goes far beyond the scope of a single tool call—it's the result of multiple tools working in concert.

Deep Dive: The API Call Chain of a Skill

To thoroughly understand how Skills are implemented, let's dissect the complete API call chain of the "Data Summary" Skill.

JSON visualization of the API call chain

The entire process consists of two API calls. This "two-call" pattern is known in the industry as one complete iteration of the ReAct (Reasoning + Acting) loop. The first call is the Reasoning phase, where the model analyzes intent and decides on an action plan; the local execution in between is the Acting phase; the second call feeds the observation results back to the model for summarization. This pattern originates from the ReAct framework paper proposed by Google and Princeton University in 2022. In more complex scenarios, this loop may iterate multiple times—the model might need 3, 5, or even more rounds of tool calls to complete a task, with each round containing a complete reasoning-execution-observation cycle. Mainstream Agent frameworks like LangChain and AutoGen have this loop mechanism built in.

First Call: Tool Selection and Parameter Determination

Constructing the input:

System role definition: "You are an Excel assistant"
Available tools declaration: Informing the model of available tool names and parameter definitions in a standard format (e.g., sum_range, average_range)
User prompt: This is the key part—the agent doesn't send the user's raw input directly to the model. Instead, it first reads the Prompt template from the Skill table and wraps the user input into a more precise instruction: "Please summarize the data range AI10:AI12, calculating the sum, average, minimum, and maximum, and return the results"

The Prompt template plays a role in Skills that goes far beyond simple text substitution. It's effectively an "intent translation layer"—converting the user's vague natural language expression into structured instructions that the model can more easily understand and execute. This involves several key Prompt Engineering techniques: instruction clarification (converting "summarize data" into specific calculation requirements), context injection (embedding parameters like data ranges into the prompt), and output format constraints. High-quality Prompt templates can significantly improve tool call accuracy and reduce the probability of LLM "hallucinations" or misjudgments. This is why in production-grade Agent systems, Prompt template design and iteration often account for a substantial portion of engineering effort.

Model response:

After analysis, the large model returns the tools it believes should be called along with their parameters:

Call sum_range with parameter AI10:AI12
Call average_range with parameter AI10:AI12

Tool call instructions returned by the model

Second Call: Result Feedback and Natural Language Summary

After receiving the model's "call instructions," the agent executes these tools locally:

sum_range execution result: 202
average_range execution result: 67.333

It then initiates a second API request. This time, the message list contains:

The first three messages as historical context (system prompt, user input, model's tool call decisions)
Appended tool execution results: informing the model that "sum_range returned 202, average_range returned 67.333"

With this data, the model packages the results into a user-friendly table format and returns it, completing the entire Skill execution.

The Essence of Skills: Prompt Orchestration and Tool Composition

Through the analysis above, we can summarize the implementation essence of Skills:

1. Skills don't have a dedicated API endpoint

At the LLM API level, there is no standalone "Skill call" interface. Skill implementation relies entirely on the existing tool call mechanism.

2. The core lies in prompt orchestration

Skills guide the large model to correctly select and combine multiple tools through carefully designed Prompt templates. This is why Skill definitions need to include detailed descriptions and Prompt templates.

3. Skill = SOP + Toolset

You can think of a Skill as a standard operating procedure that specifies "which tools need to be called to accomplish a business objective, in what order, and with what parameters."

4. Stability remains a key challenge

Since Skills depend on the large model's comprehension and reasoning capabilities, the same request may produce different results. In the demo, we saw that multiple attempts were needed to get correct results—this is a critical engineering concern in current AI Agent development.

The non-determinism of LLM outputs stems from their probability-sampling-based generation mechanism. Even with temperature set to 0, differences in inference batches, model version updates, or even API server load-balancing strategies can lead to output variations. In engineering practice, the industry has adopted multiple strategies to improve Agent stability: setting temperature to 0 to reduce randomness, using Structured Output to constrain return formats, implementing retry mechanisms and result validation logic, and providing standard execution examples through few-shot examples in prompts. OpenAI's Structured Outputs feature launched in 2024 and Anthropic's Tool Use specification have both made improvements at the API level to enhance tool call determinism.

Conclusion

Once you understand the difference between Tool Calls and Skills, you've grasped the core design philosophy behind mainstream AI Agent frameworks like OpenAI Codex and Claude Code. OpenAI Codex uses a code execution sandbox as its core Skill carrier, compiling complex tasks into executable code snippets; Claude Code defines Skill boundaries through detailed instruction sets in system prompts, emphasizing sequential tool chain orchestration; Microsoft's AutoGen framework introduces multi-Agent collaboration, where different Agents each hold different Skill sets and complete cross-Skill task decomposition through conversation protocols. Despite different implementation paths, the underlying logic is consistent: all build higher-level business capability abstractions on top of tool call APIs through prompt engineering and workflow orchestration.

Tools are building blocks; Skills are models built from those blocks. True agent development is about designing atomic tools and then orchestrating them into powerful business capabilities through Skills. While this Excel-based agent is simple, it fully demonstrates the essence of this architecture.