Build a Working AI Agent: A Practical Glossary

An AI agent is a program that takes a goal, decides on a sequence of actions, and executes those actions using tools until the goal is met or it gives up. That's different from a chatbot, which just responds to messages. An agent plans, calls functions, checks results, and adjusts. If you've only used ChatGPT through a browser, building your first agent is where the model stops being a text generator and starts being a component in a larger system.

The core loop

Every agent, no matter how it's marketed, runs some version of the same loop: observe, think, act, repeat. Concretely:

1. The agent receives a task ("find the cheapest flight to Lisbon next month and draft an email summary").
2. It calls the LLM with the task plus a description of available tools.
3. The model returns either a final answer or a tool call, like search_flights(destination="Lisbon", month="2025-06").
4. Your code executes that function, gets a real result, and feeds it back into the model's context.
5. The model decides what to do next: call another tool, ask for clarification, or finish.

This pattern is often called the ReAct loop (reason plus act), and it's the backbone of frameworks like LangChain's agent executors, LlamaIndex agents, and OpenAI's function-calling API. You can implement the whole thing yourself in under 100 lines of Python with just an LLM API and a while loop — the frameworks add convenience, not magic.

Tools are what make it an agent

A model with no tools can only talk. Give it functions and it can act. Tools are typically plain Python functions wrapped with a schema describing their name, parameters, and purpose, so the model knows when and how to call them. Example:

def get_weather(city: str) -> str:
    """Return current weather for a given city."""
    resp = requests.get(f"https://api.weather.example/v1/{city}")
    return resp.json()["summary"]

With OpenAI's function-calling, you pass a JSON schema alongside this function, and the model outputs a structured call like {"name": "get_weather", "arguments": {"city": "Lisbon"}} instead of freeform text. Your code parses that, runs the real function, and returns the result as a new message in the conversation. Repeat until the model has enough information to answer.

Memory and state

A single API call has no memory beyond its context window. Agents need explicit state: a running list of messages (the conversation history), and often a separate store for longer-term facts. For short tasks, a Python list of dicts representing the conversation is enough. For agents that need to remember things across sessions, you'll reach for a vector database (Chroma, Pinecone, Qdrant) to store and retrieve relevant past information via embeddings.

Don't over-engineer this early. A surprising number of "agent" projects fail not because the LLM is weak but because the state management is sloppy: duplicate messages, unbounded context growth, or losing track of which tool call belongs to which result.

A minimal working example

Here's the shape of a bare-bones agent using OpenAI's API, no framework:

messages = [{"role": "user", "content": "What's the weather in Lisbon?"}]

while True:
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=messages,
        tools=[weather_tool_schema],
    )
    msg = response.choices[0].message
    if msg.tool_calls:
        for call in msg.tool_calls:
            result = get_weather(**json.loads(call.function.arguments))
            messages.append(msg)
            messages.append({
                "role": "tool",
                "tool_call_id": call.id,
                "content": result,
            })
    else:
        print(msg.content)
        break

That's a real, functioning agent. Everything else — planning strategies, multi-agent coordination, retrieval pipelines — builds on this loop.

Where it breaks

Agents fail in predictable ways: infinite tool-call loops when the model can't tell it succeeded, hallucinated function arguments, and runaway costs from re-calling expensive tools. Guard against loops with a hard iteration cap (say, 10 steps) and log every tool call during development. Validate arguments before executing anything that touches a real system — an agent that can send emails or run shell commands needs the same input sanitation you'd apply to user-facing code, because the LLM is, in effect, an untrusted user generating that input.

Where to go next

Once the loop works, the interesting problems start: choosing between single-agent and multi-agent designs, deciding how much autonomy to grant, and testing agents reliably when their output isn't deterministic. Korra Studio's AI and Python tracks cover retrieval-augmented generation, prompt design, and tool-calling patterns in more depth if you want to keep building from here.