You've heard the buzz about AI agents—autonomous programs that can browse the web, write files, or answer questions by chaining together decisions. But the jump from a single prompt to a functional agent feels like a cliff. This guide bridges that gap. By the end, you'll have built a working AI agent in Python that can search the web and fetch current data, using OpenAI's GPT-4o model. No prior AI experience is needed, but you should be comfortable running a terminal and editing a Python script. We'll cover the core architecture, tool integration, memory patterns, and three mistakes that trip up most beginners.
A standard chatbot responds to one query with one answer. An AI agent is different: it can loop, pick tools, and adapt based on intermediate results. For example, if you ask a plain chatbot "What is the latest price of Apple stock?" it may respond with a training cutoff date. An agent, however, can call a stock price API, fetch the number, then format the answer. This tool-use loop is what makes agents powerful.
Agents are especially useful for tasks that require multiple steps: gathering data from different sources, transforming it, and producing a summary. Real-world applications include automated research assistants, customer support triage bots, and personal productivity tools that schedule meetings or summarize email threads. The key difference is that an agent does not guess—it executes deterministic functions when needed.
Before you start coding, consider if your use case genuinely requires an agent. If your task can be solved with a single prompt or a simple retrieval-augmented generation (RAG) pipeline, an agent might add unnecessary complexity. But if you need dynamic decision-making—like deciding whether to look up a database or ask for clarification—an agent is the right architecture.
You'll need Python 3.10 or newer, an OpenAI API key (or any LLM provider of your choice), and a code editor. We'll use openai version 1.30.0 and python-dotenv for managing secrets.
Create a new project folder, then run the following in your terminal:
pip install openai==1.30.0 python-dotenv requests
The requests library will let your agent call external APIs. You may also need beautifulsoup4 and html.parser later if you want to scrape web content, but for now we'll keep it minimal.
Create a file named .env in your project root and add one line:
OPENAI_API_KEY=sk-your-key-here
Never commit this file to version control. Use .gitignore to exclude it. For production, you would use environment variables or a secrets manager.
Write a small script that sends a simple chat completion request to confirm everything works. If you get a response, you're ready to build the agent. If you hit a rate limit or key error, double-check that your account has billing enabled and that you're using a model with tool support (the gpt-4o series works well as of May 2025).
Every AI agent has three fundamental components: a reasoning engine (the LLM), a set of tools (functions the agent can call), and a loop that decides when to use a tool and when to respond to the user. We'll build each one.
The reasoning engine receives the user's request and the conversation history. It also sees a list of available tools, described in a structured format (JSON schema). The LLM then decides whether to output a final answer or a tool call. If it chooses a tool, the agent executes the function, feeds the result back into the LLM, and repeats until the LLM decides to respond.
This pattern is called the "ReAct" loop (Reason + Act), popularized by a 2022 paper from Google. It is the backbone of most modern agent frameworks like LangChain, AutoGen, and CrewAI. But we'll implement it from scratch so you understand every moving part.
A critical nuance: the LLM is not calling the function directly. It outputs a structured object that your code parses—typically a JSON object with the function name and arguments. Your Python script then executes the actual function, like search_web(), and appends the result as a new message in the conversation. This separation keeps control in your code, not in the model's hallucinated output.
Let's create a tool that searches the web using the DuckDuckGo Instant Answer API. It's free and does not require an API key. We'll keep it focused: the function takes a query string and returns a list of top results.
Add this to your main file:
import requests
def search_web(query):
url = f"https://api.duckduckgo.com/?q={query}&format=json"
response = requests.get(url)
if response.status_code != 200:
return "Search failed. Status code: {response.status_code}"
data = response.json()
results = data.get("RelatedTopics", [])[:3]
if not results:
return "No results found."
formatted = []
for item in results:
title = item.get("Text", "No title")
url = item.get("FirstURL", "")
formatted.append(f"{title} - {url}")
return "\n\n".join(formatted)
Test this function independently. Call print(search_web("current weather in Tokyo")) to see if you get relevant snippets. Note that DuckDuckGo's free API returns limited data—many results are abstract-style. For production, you might use the SerpAPI or Bing Search API (costs apply). But for learning purposes, this is sufficient.
Now wrap this function in a tool definition that the LLM can understand. In OpenAI's API, tools are described as a list of dictionaries:
tools = [
{
"type": "function",
"function": {
"name": "search_web",
"description": "Search the web for current information. Use this for recent events or data not in the training cutoff.",
"parameters": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "The search query."
}
},
"required": ["query"]
}
}
}
]
Be precise with the description. A vague description like "search the web" may cause the LLM to misuse the tool. Include context like when it should be used—this significantly improves calling accuracy.
Now we stitch everything together. The agent loop does the following:
Here is the core loop in Python (simplified). We use the new openai.resources.chat.completions module:
from openai import OpenAI
client = OpenAI()
def run_agent(user_message, max_turns=5):
messages = [{"role": "system", "content": "You are a helpful assistant. Use tools when you need current data."}]
messages.append({"role": "user", "content": user_message})
for turn in range(max_turns):
response = client.chat.completions.create(
model="gpt-4o",
messages=messages,
tools=tools,
tool_choice="auto"
)
message = response.choices[0].message
if message.tool_calls:
for tool_call in message.tool_calls:
if tool_call.function.name == "search_web":
args = json.loads(tool_call.function.arguments)
result = search_web(args["query"])
messages.append({
"role": "tool",
"tool_call_id": tool_call.id,
"content": result
})
continue
else:
return message.content
return "Agent exceeded maximum turns without completing."
Notice the max_turns parameter. Without it, a misbehaving agent could call tools indefinitely and cost you money. Always cap turns. Also note that we import json—you can parse the arguments safely with json.loads(). Never use eval().
Right now, our agent only sees the current turn. If you want multi-turn conversations—like asking a follow-up question about a previous search—you need to store the conversation history. The simplest approach is to keep the messages list persistent across user calls. Each call appends the new user message and loops.
However, agents that accumulate many tool calls quickly exceed the context window. GPT-4o supports up to 128,000 tokens, but a single search result can be 1,000 tokens. Three searches plus conversation history eats the budget fast. Two practical solutions:
A common mistake beginners make is keeping every single tool call response verbatim. A tool response might contain a long article summary. Once the agent has incorporated that information, you can remove the raw tool result from the message list. Keep only the final natural language summary.
Another edge case: the agent may get stuck in a loop calling the same tool with the same query. Detect this by keeping a set of past tool calls (query + timestamp). If the agent repeats a call with identical arguments within a short window, force it to respond without using the tool. This prevents infinite loops and wasted API costs.
Before you unleash your agent on real tasks, test edge cases deliberately. Here are three tests that reveal the most common bugs:
Log all interactions during testing. Print the tool calls, arguments, and results. If you see the agent calling search_web with a query like "", it means your parameters are not forcing required fields. Check the JSON schema.
Common mistake: forgetting to handle JSON decode errors. The LLM might occasionally output malformed JSON for the arguments. Wrap json.loads() in a try-except block, and if it fails, ask the LLM to retry with a properly formatted tool call. This robustness is crucial for production.
Also be aware of token limits within tool calls. If a search returns a huge result, it may exceed the context window. Truncate long results—keep the first 500 characters, or ask the LLM to summarize the result before feeding it back. This keeps conversation history manageable.
Your agent is now ready. Start with simple tasks like "What is the current time in London?" (you'll need a time tool for that) or "Find the latest news on space exploration." Each new tool you add extends the agent's capabilities. Add a tool for sending an email, for opening a file, or for performing arithmetic. The architecture scales linearly.
The most important takeaway is this: an agent is only as good as its tools and the instructions for using them. Spend time refining your tool descriptions. Test every edge case. Monitor your API usage. And never assume the LLM will behave—code defensively. Build the loop, test it ruthlessly, and you'll have a genuinely useful AI agent that goes beyond chat.
Browse the latest reads across all four sections — published daily.
← Back to BestLifePulse