How to Build an AI Agent in Python (2026): Loop, Tools, Safety

Quick answer

An AI agent is a language model that can call tools in a loop until a task is done. In Python that means three pieces: a model that decides what to do next, a set of tools (ordinary Python functions) it is allowed to call, and a loop that runs the tool, feeds the result back and stops when the model gives a final answer or a step limit is reached.

• You can build one in about 30 lines of plain Python. The example below uses a fake model, so it runs anywhere: no API key, nothing to install.
• Swapping in a real model is a small change. OpenAI, Anthropic and Google Gemini all support tool calling (OpenAI and Google call it "function calling", Anthropic calls it "tool use"). The loop stays the same.
• You don't need a framework to start. LangGraph, the OpenAI Agents SDK, CrewAI and LlamaIndex are useful later, once you know which problem they solve for you.
• Safety is part of the design, not an extra. Limit the steps, allow-list the tools, and never give an agent a tool that runs arbitrary shell commands on your machine.

What an AI agent actually is

A chatbot takes a message and returns a message. An agent takes a goal and keeps working on it. The difference is the loop:

1. Send the model the conversation so far plus a description of the tools it may use.
2. The model replies with either a final answer or a request to call a tool with specific arguments.
3. Your code checks the request, runs the tool and appends the result to the conversation.
4. Repeat until the model answers or you hit a limit.

The model never runs anything itself. It only produces text, usually structured JSON, that says something like "call get_weather with city = "Paris"". Your program decides whether to do it. That is the most important idea in agent safety: the model proposes, your code decides.

Anthropic's widely cited article "Building effective agents" (Erik Schluntz and Barry Zhang, December 2024) draws a useful line here. Workflows are LLM calls wired together through code paths you wrote in advance; agents let the model direct its own steps and tool use. Workflows are more predictable, while agents suit open-ended tasks where you cannot know the number of steps up front.

A minimal agent in about 30 lines

The code below is a complete agent. The model is fake: a small function that pretends to be an LLM by reading the question and replying in JSON. That means you can run it with any Python 3 installation. Everything else is what you would use with a real model.

import json, re

def add(a, b):
    return a + b

TOOLS = {"add": add}  # the allow-list: the only things the agent can do

def fake_model(messages):
    """Pretends to be an LLM. Replies with JSON: a tool call or an answer."""
    last = messages[-1]
    if last["role"] == "tool":
        return json.dumps({"answer": f"The sum is {last['content']}."})
    nums = [int(n) for n in re.findall(r"-?\d+", last["content"])]
    if len(nums) >= 2:
        return json.dumps({"tool": "add", "args": {"a": nums[0], "b": nums[1]}})
    return json.dumps({"answer": "Give me two numbers to add."})

def run_agent(question, max_steps=5):
    messages = [{"role": "user", "content": question}]
    for step in range(max_steps):
        reply = json.loads(fake_model(messages))
        if "answer" in reply:
            return reply["answer"]
        name, args = reply["tool"], reply["args"]
        try:
            result = TOOLS[name](**args) if name in TOOLS else f"unknown tool {name}"
        except Exception as e:
            result = f"tool error: {e}"
        messages.append({"role": "assistant", "content": json.dumps(reply)})
        messages.append({"role": "tool", "content": str(result)})
    return "Stopped: step limit reached."

print(run_agent("What is 19 + 23?"))
print(run_agent("Hello"))

Running it prints:

The sum is 42.
Give me two numbers to add.

What each part does:

• messages is the agent's short-term memory: a list of dictionaries, each with a role and content. Real model APIs use the same idea.
• TOOLS is an allow-list. The agent can only call functions you put in this dictionary; an unknown name produces an error message instead of a crash or something worse.
• fake_model returns JSON with either tool and args, or answer. Asking for a fixed JSON shape is what makes the reply readable by your code.
• max_steps guarantees the loop ends. A confused model can otherwise call tools forever, and with a real API you pay for every step.
• try/except turns tool failures into text the model can read and react to, instead of crashing the whole run.

Try it: add a multiply tool, or set max_steps=1 and watch the agent stop early.

Swapping in a real model

To make it a real agent, you replace fake_model with a call to a model API. The three biggest providers all support this pattern, and their official documentation describes the same round trip:

• OpenAI calls it function calling (also tool calling). You send tool definitions with your request, the model may return a tool call, you run it and send back the tool's output, and the model then answers or asks for more tools. OpenAI's current docs centre on the Responses API, with Chat Completions examples as well.
• Anthropic (Claude) calls it tool use. Each tool has a name, a description and an input_schema written in JSON Schema. When Claude wants a tool, the response has stop_reason set to "tool_use" and contains tool_use blocks; you reply with tool_result blocks that reference the call's id.
• Google Gemini calls it function calling. You provide function declarations (a subset of the OpenAPI schema format), the model returns a functionCall, and you send back a functionResponse. Google's Python SDK can also run the loop for you ("automatic function calling") when you pass Python functions directly.

What changes in your code:

1. Tools get a schema. Besides the dictionary of functions, you send each tool's name, a plain-English description and its parameter types. Good descriptions matter more than clever prompts, because the model picks tools based on them.
2. The reply comes from the provider's response object instead of from your own JSON string.
3. Tool results go back with an id, so the model knows which call each result answers.

The loop, allow-list, step limit and error handling stay the same, which is why it pays to build the fake version first.

We are deliberately not pasting SDK code here. Method and model names change often, and each provider's quickstart is more current than any guide. Read the official tool-use page for the provider you choose, install its official Python package, and keep your API key in an environment variable, never in your code or in a Git repository.

Agent frameworks, honestly compared

Frameworks save time on things you will eventually need: persistence, tracing, retries, hand-offs between agents. They also add abstractions to learn and debug. Anthropic's article recommends starting with direct API calls and adding a framework only when you understand what it does underneath.

Our recommendation: build the loop yourself, ship one small agent, and adopt a framework when you catch yourself re-inventing persistence or tracing.

Costs and safety basics

Costs

Every step in the loop is a paid model call, and in most setups each call includes the conversation so far. A ten-step run therefore costs more than ten separate questions, because the input grows at every step. Practical controls:

• Set a step limit. Five to ten steps is plenty for most beginner agents.
• Keep tool outputs short: return the three relevant rows, not the whole table.
• Develop with a smaller, cheaper model, and check your provider's current pricing page before running anything in a loop. We do not quote prices because they change often.

Safety

• Allow-list tools. The agent can only do what your TOOLS dictionary permits. Start with read-only tools.
• Never give an agent a tool that runs arbitrary shell commands or arbitrary Python (eval, exec, subprocess with model-written input) on your own machine. If you later need code execution, run it in a disposable sandbox or container with no access to your files or credentials.
• Validate arguments before running a tool: types, ranges, allowed file paths.
• Ask a human before anything irreversible, such as sending email, deleting files or spending money.
• Treat tool output as untrusted. A web page or document the agent reads can contain instructions aimed at the model. This is called prompt injection, and the OWASP Top 10 for LLM Applications lists it alongside "excessive agency": giving a model more tools, permissions or autonomy than the task needs.
• Keep secrets out of the conversation. API keys belong in environment variables, not in prompts or tool results.

A learning path

1. Python basics: variables, loops, functions, dictionaries and try/except. Our free Python Foundations course covers all of it in the browser.
2. Intermediate Python: classes, dataclasses, decorators and generators in Python Intermediate.
3. Agents: the AI Agents course builds on the code in this guide over 25 lessons: the agent loop, messages, JSON output, tools and schemas, step limits, memory, planning, error handling, guardrails, evals, multi-agent setups and a capstone project.
4. Depth: Chip Huyen's AI Engineering: Building Applications with Foundation Models (O'Reilly, December 2024) has a chapter on RAG and agents that covers tools, planning, memory, failure modes and evaluation. See AI Engineering on Amazon (paid link)

Prefer video? Check that any course was updated recently, because agent tooling moves fast. Browse courses on Udemy (paid link)

Common mistakes

1. Starting with a framework. You end up debugging abstractions instead of learning the loop.
2. No step limit. An agent that loops forever is a bill, not a feature.
3. Vague tool descriptions. If a person could not tell when to use a tool from its description, neither can the model.
4. Giving the agent too much power. Shell access, write access to your real files or your personal email account are not beginner tools.
5. Crashing on tool errors. Return the error as text so the model can retry or explain.
6. No evals. Keep a short list of test questions with expected outcomes and rerun it after every prompt or tool change. "It worked once" is not testing.
7. Hard-coding API keys. Use environment variables and never commit keys to Git.

Next step

Run the 30-line agent above and add a second tool. Then continue with the AI Agents course, which turns this loop into a full project one lesson at a time. If loops or dictionaries still feel shaky, do Python Foundations first.