Azure AI Agent Service stores agent state, threads, instructions, and context in the cloud, which removes much of the persistence work from the application.
2
An agent combines reasoning, data access, and actions, using tools such as SQL functions, file search, code interpreter, and Bing grounding.
3
Simple tool use can answer useful questions, but multi-step planning is needed when the agent must discover which data sources or tools are required.
Summary
Cedric Vidal runs a code-first workshop around a sales analysis agent for an outdoor equipment retailer. The agent accepts plain-English questions, generates SQL for sales data, searches product documents, creates charts with Python, and can use Bing for competitor information. Vidal explains Azure AI Agent Service's stateful model, including agents, threads, runs, instructions, tools, and cloud-managed data connections. He also shows how function calling works in practice: the model emits structured information describing a function and its arguments, while application code executes the function. The workshop's examples use SQLite, Azure AI Search, Azure OpenAI, and the Azure AI Foundry SDK for Python. Vidal is direct about the limits. Models can choose the wrong tool, miss a needed data source, and perform arithmetic poorly. More complex tasks need specialized agents, routing, or an orchestration loop with a clear definition of done.
An agent receives a goal and works with tools and information
Vidal defines an agent as semi-autonomous software that receives a goal and works toward it using tools and information from databases and other data stores. It can iterate until the system stabilizes and the goal is met, although the workshop uses a simpler design without that looping behavior. He says an agent needs to reason over context, integrate with data sources, and act on the world. The example application combines sales records with product information, then chooses a suitable output such as a table or pie chart based on the user's request.
Azure AI Agent Service moves state and context management into Azure
Vidal contrasts Azure AI Agent Service with a typical stateless LLM application. In the usual model, the developer stores conversations, manages context, retrieves information, and executes tools. Agent Service manages the agent's state, configuration, and context in the cloud. The application creates or reconnects to an agent, creates or reuses a thread, starts a run, checks its status, and displays the response. Instructions are attached to the agent and reused across requests. Data sources and tools can be configured through Azure AI Foundry or the Python SDK.
Function calling routes a model's structured request to application code
Vidal prefers the term 'function routing' because the LLM does not execute code. It generates a JSON description of the function to use and the values for its parameters. The application then maps that specification to an actual function and runs it. Structured output makes this cleaner than older approaches that asked a model to return comma-separated function names and arguments. The model chooses among available functions based on the user's request and the function schemas and descriptions supplied to it. A classification model is different because it selects among categories, while function routing can extract parameter values across several dimensions.
A sales agent can turn plain English into SQL for a relational database
In the workshop code, the sales function accepts a SQL query and executes it with the SQLite driver. The function itself is simple. The model generates the query from the user's question, using the database schema included in the agent instructions. For a request about sales by region, it can select revenue, group by region, and apply the default limit described in the instructions. Vidal says this approach can work with familiar databases such as PostgreSQL, MySQL, SQLite, or MongoDB because models have seen examples of them during training. An unfamiliar database syntax may work poorly.
Grounding joins structured sales data with information from product documents
The document-grounding example creates an Azure AI Search vector store from a PDF containing product information. The documents are split into pieces and uploaded to the vector database, with Azure AI Search handling the chunking in this setup. File-search instructions give the agent access to product brands and categories that do not exist in the sales database. A question about sales by product type can therefore combine revenue from SQL with brand information retrieved from the PDF. Vidal presents this as a way to join structured database records with unstructured documents without building a separate aggregated system.
Tool descriptions and database documentation shape what the model can do
The instructions file describes the agent's role, mission, available tools, formatting, localization, and examples. The function schema, function name, parameter names, and parameter documentation are also passed to the model. Vidal says the database schema must be included so the model knows the available tables and columns. Developers can add semantic descriptions when database names are cryptic. He warns that instructions such as 'never return this confidential column' are not a sufficient access-control system. The application should apply the same access restrictions and safety measures used by normal code.
Code interpreter is useful for charts and files, while arithmetic needs a dedicated tool
The code interpreter takes data and generates Python code in a sandbox. In the workshop it creates a pie chart, saves the image inside the sandbox, and returns it to the client. Vidal says it is also useful for reading CSV or other structured files and extracting information. He does not trust it for accurate arithmetic. For calculations, he recommends a separate calculator tool that accepts a mathematical expression, so the model can delegate the computation instead of producing the result itself. The chart example shows how a single natural-language request can lead to a database query followed by generated visualization code.
Complex questions need routing and planning across specialized agents
Giving one agent many tools increases the chance that it selects the wrong one. Vidal suggests specialized agents for areas such as sales and products, with a first agent classifying the question and routing it to the appropriate specialist. A coordinator can then decide whether another agent is needed. More advanced systems inspect an answer, ask whether it actually answers the question, and choose another data source or tool when it does not. Azure AI Agent Service's simpler workflow can fall short when a question requires several unspoken steps. Vidal says the hardest part of looping systems is defining when the work is done.
"An agent is semi autonomous software to which you give a goal and it will work to achieve that goal relentlessly using tools and information that you can pull from databases and data stores at large."03:40
Who should watch
You are building a Python agent that needs persistent conversations, cloud-managed threads, and built-in access to data and tools.
Your application must combine relational data with product documents or generate charts from query results.
You need a clear explanation of where simple tool calling stops working and when routing or multi-step planning becomes necessary.
