Building an E-commerce AI Agent by Hand in 90 Minutes: A Practical Guide to Database Tool Calling

From Generating Content to Executing Actions: What Makes AI Agents So Powerful

Generative AI (GenAI) can already write copy, generate images, and produce code, but at its core it does only one thing—output content. When you ask "Where is my order?", a chatbot can politely respond, but it cannot actually go query the database. What truly turns AI from "can talk" into "can do" is Agentic AI.

According to a demonstration in a 90-minute hands-on course by a Bilibili creator, the core difference between an AI Agent and an ordinary chatbot is this: an Agent will think and plan actions, break goals down into executable steps, and use "tools" to connect to external systems such as databases, APIs, and vector stores to perform real operations like queries and updates, then generate a natural-language reply based on the execution results.

This course runs through a single e-commerce customer service Agent from start to finish: the frontend uses Streamlit for the interface, the backend uses Python + LangChain, the model is bound to OpenAI GPT, and the database is a MySQL orders table. The user enters an order ID and the Agent can look up its status; when the user asks to cancel an order, the Agent first checks whether the status allows cancellation, then decides whether to execute or refuse.

Tool Calling: The Core Mechanism by Which Agents Execute Actions

A Tool Is Just a Function, and the Docstring Is Its Manual

The most critical concept in the course is Tool Calling. A tool is essentially an ordinary function responsible for performing a specific action. In the e-commerce case, the developer writes two functions: get_order_status(order_id) and cancel_order(order_id). Through LangChain's @tool decorator, these two functions are exposed as tools and bound to the large language model.

One detail worth noting: the LM itself does not execute tools. Its only job is tool selection: based on the user's question and the tool's docstring, it decides which tool to call and what arguments to pass. The actual function execution and database reads and writes are all handled by the developer's application code.

During the demonstration, the creator deliberately deleted the tool's docstring, and the application failed to start, reporting an error saying "the function must have a docstring." This confirms an easily overlooked detail: the docstring is not a comment—it is the sole basis on which the LM routes tools. The function name can be arbitrary, but the description must be accurate.

Function Calling is a capability OpenAI introduced for GPT-3.5/GPT-4 in June 2023, allowing the model to output structured JSON during a conversation to request calls to developer-defined external functions rather than directly generating text. LangChain's @tool decorator is essentially a wrapper around this underlying protocol: it converts the Python function's name, parameter types, and docstring into a JSON Schema and sends it with the request to the model. What the model returns is not the function call itself but a tool_calls field containing the function name and arguments, which the application code parses and executes on its own. So the accurate description of "tool calling" is "tool selection + application execution"—the model side always plays the role of advisor. This mechanism also gives the model's output a verifiable structure, reducing the fragility of parsing free-form text.

Two LM Calls: The Skeleton of an Agent's Workflow

An ordinary GenAI application communicates with the LM only once, whereas an Agent application typically communicates twice. The standard flow given in the course is:

1. Step 0: Create the tools and bind them to the LM client object;
2. The user asks a question, and the question is sent to the LM with tools bound;
3. The LM returns a tool selection result (tool name + arguments);
4. The application executes the corresponding tool, which accesses MySQL and returns a result;
5. The original question and the tool result are sent to the LM again, and the LM generates the final reply.

This "select—execute—regenerate" loop is the key to making Agents land in real business. The first call handles "what to do," and the second call handles "how to say it."

ReAct (Reasoning + Acting) is the theoretical backdrop for understanding the two-call loop above. This paradigm was proposed by Shunyu Yao et al. in 2022, and its core is to have the language model alternate between "reasoning" and "acting": first think about what information the current state requires, then choose an action (such as calling a tool), observe the returned result, and continue reasoning. The flow in the course is precisely a minimal implementation of ReAct—the first LM call corresponds to Thought/Action, tool execution corresponds to Observation, and the second LM call corresponds to generating the final answer based on the observation. In more complex scenarios, LangChain's AgentExecutor repeats this loop for multiple rounds until the model determines that no more tool calls are needed. Understanding ReAct helps developers anticipate an Agent's behavior paths and failure modes in multi-tool, multi-step tasks.

Business Logic Belongs in Code, Not in the Model

The scene in the e-commerce Agent demo that best reflects engineering thinking is the safeguard logic for cancelling orders. The developer does not let the LM decide "whether a delivered order can be cancelled"; instead, inside the cancel_order function, the current status is queried first: if the status is "delivered," it directly returns "The order cannot be cancelled because it has already been delivered"; if it is already "cancelled," it notes that there is no need to repeat the operation; only when the status permits is the UPDATE executed.

The result: order 1001 has the status "shipped," and the Agent successfully cancels it; order 1002 has the status "delivered," and the Agent replies, "Your order has been delivered and cannot be cancelled." The database contains only the word "delivered," but the final reply is a complete sentence generated by the LM based on the tool's returned result. Business rules are guaranteed by code, and expression is handled by the model—the boundary between the two is clear.

This design also explains why tool calling is so important for Agents: the LM cannot directly access your private database, company documents, payment API, or email system. Tools are a controlled window opened for the model—data stays inside the application, and permissions remain in the code.

Permissions and trust boundaries are an often-underestimated part of Agent engineering. Tool calling connects the model to real systems, but it also means that a single misjudgment by the model can trigger a write operation (such as an UPDATE, a refund, or sending an email). The industry-standard practice is to follow the principle of least privilege: grant the database account used by the Agent only the necessary tables and operations, perform secondary validation inside write-operation tools, and require human confirmation or write audit logs for sensitive actions. Locking status validation inside the cancel_order function in the course is essentially treating "the model is untrustworthy" as a design premise. This approach is consistent with traditional input validation—do not rely on the caller (here, the LM) to behave, but enforce constraints at the system boundary, thereby keeping the Agent's risk within a predictable range.

Hands-on Path and Pitfall Log

The course's project setup is divided into six steps: create the database and table and insert three sample orders, create the project and virtual environment, configure the OpenAI key in .env, write the database service, implement the Agent with tool calling, and finally build the UI with Streamlit. Dependencies include openai, langchain, streamlit, mysql-connector-python, and python-dotenv.

The demonstration also exposed real compatibility issues: the developer initially hit an "unexpected keyword argument" error when using the response_api=true parameter, then got a message that GPT-3.5 does not support this function tool calling, and finally switched to GPT-4o to get it working. This shows that tool calling capability is strongly tied to the specific model version, and when selecting a model you should first confirm whether it supports function calling.

Another practice worth borrowing: after finishing the Agent's core logic, hand the code directly to ChatGPT to generate the Streamlit interface, writing not a single line of frontend logic by hand. For developers without frontend experience, this is a low-cost path to quickly validate an Agent's effectiveness.

Editor's View: The Barrier to Agents Is Not the Model but Engineering Constraints

The value of this course is not in teaching an e-commerce query demo, but in revealing the real division of labor in Agent development: the model is responsible for understanding and selecting, while the developer is responsible for defining tools, writing business rules, and executing operations. How well the tool descriptions are written directly determines how accurate the routing is; at which layer business validation is placed directly determines whether the Agent will cause trouble.

For developers who want to get started with Agents, the advice is to begin with "one action, one tool," write the docstrings clearly first, and then lock hard logic such as status validation and permission checks inside the functions. Models will become more and more powerful, but the boundary of "what can be done and what cannot" should always remain in the hands of the code.