If you’re embedded in the world of software development, AI, and Large Language Models (LLMs), you probably talk about and use AI agents all the time. If you want to go beyond using agents and start to create your own, this article is for you.
But before we build our first one, have you ever stopped to think about what an AI agent is? Let’s pin down exactly what we mean by the term — agent.
As you might expect, there are as many answers to this question as there are LLMs, but I think a broad definition that most agree with is that …
An AI agent is a software system that uses an LLM that calls one or more tools in a loop to reach a goal.
The “goal” an agent reaches can be anything from answering a simple question to controlling your browser to book an airline ticket or developing highly complex software.
Bear in mind that in agentic systems, the loop describes the cycle between the model, the application and its tools. It doesn’t require a literal while or for statement. The example I’ll use makes one pass through that cycle: the model requests a tool, Python runs it, and the model uses the result to answer. Because one turn is enough, the steps are written out explicitly.
In the rest of this article, I’ll show you how to build your first AI agent. It won’t do anything complex, but that’s by design to keep things simple to begin with, not because it can’t.
The problem our AI agent will solve
Suppose you run a small online shop and want a support assistant that can answer questions about orders. The order data sits in a database, so a language model can’t answer those questions on its own. It needs a controlled way to ask your application for the facts.
We’ll build that controlled route using a fictional shop and a small SQLite database. The database has two tables. The orders table stores the order number, customer and date. The order_items table stores the products, quantities, and prices for each order.
Our sample database contains order 1001 for Sarah Jones. She bought one mechanical keyboard for GBP 79.95 and two USB-C cables at GBP 8.50 each. The correct order total is therefore GBP 96.95.
Rather than making the user look up the order and write SQL, we’ll let them ask an LLM:
What is the total value of order 1001?
The model will recognise that it needs an order total and request a Python function called get_order_total. That function will query SQLite and return the real value. The model can then turn the result into an ordinary sentence.
The model can ask for an operation, but Python decides whether it’s allowed and performs it.
Our first version has four moving parts:
1. A language model receives a question and a description of a Python function.
2. The model asks for that function to be called with some arguments.
3. Python checks the requested function name, calls the permitted function and sends its result back.
4. The model writes an answer using the result.
The model doesn’t run the function or connect to SQLite. Your Python program still controls both. We’ll run the model locally through Ollama, so the example doesn’t need a cloud account or an API key. The program will also print the requested function, its arguments and the database result, making the exchange visible rather than hiding it inside an agent framework.
The code in this article uses Ollama’s Python library, but the general client-side tool pattern is shared by other LLM APIs, including OpenAI and Anthropic. SDK classes, field names, and message formats differ by provider, so this script isn’t portable as-is. The parts worth carrying across are the allowlist, argument validation, function dispatch, returned tool result and bounded loop.
What you’ll need
You’ll need Windows 10 or 11, enough free disk space for a local model, and PowerShell. The example also works on macOS and Linux, although the installation commands differ.
We’ll use uv to install Python and manage the project. If uv isn’t already installed, open PowerShell and run:
Close PowerShell, open a fresh window and check it:
Next, install Ollama. If you’ve never heard of Ollama, it’s a versatile, powerful tool that lets you run large language models directly on your local machine, as long as you have enough RAM to accommodate your chosen model. Download the Windows installer from https://ollama.com/download/windows, run it, then open a new PowerShell window and run the command shown below.
The download is about 3.4 GB as of this writing. Model availability and sizes can change, so check for errors when you run the command above, and make sure the model fits in your memory.
Create the project
Create a new directory and add the Ollama Python library:
uv will download Python 3.14 if it can’t find a suitable copy. You don’t need to activate the virtual environment; uv run will use it automatically.
We’ll build the database before involving the model. That gives us something deterministic to check: if the database contains the wrong data, there’s no point in debugging the agent.
The database will sit beside the Python scripts and can be recreated whenever you want to reset the example.
Creating our test database
Create the file build_shop_database.py with this code:
Run it like this:
SQLite is part of Python’s standard library, so you don’t need to install a database server. The closing(…) wrapper is required because, although sqlite3.Connection used in a plain with block handles transactions, it doesn’t close the connection when the block ends. Explicitly closing it avoids a locked database file on Windows
Creating our AI agent
Create the file single_tool.py and insert the following code.
How the agent code works
The MODEL variable contains the Ollama model name. Reading it from the OLLAMA_MODEL environment lets you try another installed model without editing the script. DATABASE_PATH points to the database file shop_agent.db in the same directory as single_tool.py, so the command works regardless of your current drive or user folder.
get_order_total() is ordinary application code. It opens SQLite in read-only mode, runs a parameterised query and returns JSON. The model never sees the SQL and can’t connect to the database itself.
The function’s name, type annotation and docstring also describe the tool to Ollama. When the script passes tools=[get_order_total], the Ollama library converts that information into a JSON schema. It sends the schema to the model, not the Python source code.
messages is the conversation so far. The system message tells the model how to behave, and the user message contains the question. The first chat() call sends those messages along with the tool schema
That call doesn’t execute the get_order_total() tool. If the model decides it needs the tool, it returns a request in response.message.tool_calls. For this question, the request is equivalent to:
The script appends response.message to the history because the next model call needs to see its own tool request. It then checks that a tool was requested and that its name is exactly get_order_total.
This line is where the tool actually runs:
**arguments turns {“order_id”: 1001} into the normal Python call get_order_total(order_id=1001). The result is added to the conversation with the tool role. tool_name tells the model which requested function produced it.
The second chat() call receives the complete history: the original question, the model’s tool request and the JSON result returned by Python. The model now has all the information it needs and can write the final sentence.
Running the agent
Just run it like you would any other regular Python script, like this
The first run may pause while Ollama loads the model into memory. On my test run, the program printed:
The final sentence can vary. Local language models generate text rather than selecting a fixed response, but the value should remain 96.95 because Python calculated it. For example, when I ran it a second time, I got a slightly different output.
Testing the failure paths
What happens if we change the question to an order that doesn’t exist:
This was my output.
The function returns structured error data. The model should explain that the order wasn’t found instead of inventing a total.
Now to ask something the tool can’t establish:
My response was:
A model may still answer from general knowledge or guess. The system message helps, but it isn’t a hard security boundary. If an answer must come from verified data, your program needs to check that an appropriate tool was called and decide what to do when it wasn’t. Still, the answer we got was pretty good in my opinion.
See the schema the model receives
The convenience of passing a Python function directly can hide an important detail. Ollama isn’t sending your source code to the model. The SDK inspects the function and produces a JSON schema similar to this:
The model sees this alongside the conversation. Its task is to decide whether the function is relevant and, if so, produce arguments matching the schema. That’s why adding a good docstring to your function is important, as the model can make good use of it.
Schema generation isn’t validation. A model can still send a string where an integer was requested, add a field that doesn’t exist or request a function that wasn’t advertised. We’ll learn how to deal with some of these issues in future parts.
Debugging the output if the model gets it wrong
When an agent gives a wrong answer, start with the tool trace. Three different failures may look similar to the user.
-
If no tool_calls were returned, the model decided it could answer without the function. Tighten the system message, improve the tool description or use a model with stronger tool-calling behaviour.
-
Double-check what you sent as an argument to Python by examining the output of the print call.function.arguments, as this script does. The database can’t return order 1001 when the model asked for 1010.
-
If the Python result was correct but the final answer was wrong, the failure happened while the model interpreted the tool output. Keep results short and structured. For example, {“total_gbp”: 96.95} is harder to misread than a paragraph containing several numbers. If all else fails, you may need a stronger model.
Using a different model
The script reads the OLLAMA_MODEL environment variable, making it easy to switch models if needed. Use Ollama to pull another tool-capable model, then set the variable for one PowerShell session. For example,
A larger model needs more memory and disk space and will usually respond more slowly on the same hardware. Don’t assume that a fluent final sentence means better tool use. Try missing order IDs, irrelevant questions and ambiguous wording, then compare the requested function and arguments.
Summary
Starting with a definition of what an AI agent really is, this article showed you how to build a simple agent using Python, Ollama and SQLite, running locally without a cloud account or API key.
Using a fictional shop’s order data, it walked through how a language model requests a tool, how Python checks and executes that request, and how the model turns the result into an answer.
Along the way, you learned how tool schemas work, and how to diagnose issues when the model gets things wrong.
This deliberately simple example keeps the mechanics visible and provides a starting point for agents that use multiple tools across several steps.
That’s the job of the next article.