How to build an AI agent from scratch in 2026: full guide with code

import json
from openai import OpenAI

client = OpenAI()

def get_weather(city: str) -> str:
    # заглушка вместо реального API
    return f"В городе {city} сейчас +7 и облачно"

tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "Вернуть текущую погоду в городе",
        "parameters": {
            "type": "object",
            "properties": {"city": {"type": "string"}},
            "required": ["city"],
        },
    },
}]

def run_agent(user_msg: str) -> str:
    messages = [{"role": "user", "content": user_msg}]
    while True:
        resp = client.chat.completions.create(
            model="gpt-4.1-mini",
            messages=messages,
            tools=tools,
        )
        msg = resp.choices[0].message
        messages.append(msg)
        if not msg.tool_calls:
            return msg.content  # модель закончила — выходим
        for call in msg.tool_calls:
            args = json.loads(call.function.arguments)
            result = get_weather(**args)
            messages.append({
                "role": "tool",
                "tool_call_id": call.id,
                "content": result,
            })

print(run_agent("Что надеть в Берлине сегодня?"))

My practical conclusion for 2026: LangGraph won the serious production niche because it makes state and transitions explicit — you see the graph, not guess what's happening inside a 'smart' abstraction. For a quick prototype, grab a simpler SDK. Fresh releases of agent tools and wrappers are conveniently tracked in the REDDYX catalog — there you can see what actually takes off and what's hype for a week.

BUILDING AN AGENT WITH LANGGRAPH

LangGraph models an agent as a graph: nodes are steps (model call, tool call), edges are transitions between them. The same loop we wrote by hand, but declaratively and with persistence out of the box.

Basic graph with one tool

from langgraph.graph import StateGraph, END, MessagesState
from langgraph.prebuilt import ToolNode
from langchain_openai import ChatOpenAI
from langchain_core.tools import tool

@tool
def search_docs(query: str) -> str:
    """Найти информацию в базе знаний по запросу."""
    return f"Найдено 3 документа по теме '{query}'"

llm = ChatOpenAI(model="gpt-4.1-mini").bind_tools([search_docs])

def call_model(state: MessagesState):
    return {"messages": [llm.invoke(state["messages"])]}

def should_continue(state: MessagesState):
    last = state["messages"][-1]
    return "tools" if last.tool_calls else END

graph = StateGraph(MessagesState)
graph.add_node("agent", call_model)
graph.add_node("tools", ToolNode([search_docs]))
graph.set_entry_point("agent")
graph.add_conditional_edges("agent", should_continue)
graph.add_edge("tools", "agent")   # после инструмента — снова к модели

app = graph.compile()
out = app.invoke({"messages": [("user", "Как настроить вебхуки?")]})
print(out["messages"][-1].content)

Note the should_continue — this is the loop exit condition, extracted into a separate node. The tools → agent edge closes the loop. You literally see the architecture with your eyes, not in your head.

Adding memory between sessions

To make the agent remember the conversation after a restart, connect a checkpointer. One line turns a stateless agent into a stateful one:

from langgraph.checkpoint.memory import MemorySaver
# для продакшена: from langgraph.checkpoint.postgres import PostgresSaver

app = graph.compile(checkpointer=MemorySaver())
config = {"configurable": {"thread_id": "user-42"}}

app.invoke({"messages": [("user", "Меня зовут Влад")]}, config)
r = app.invoke({"messages": [("user", "Как меня зовут?")]}, config)
print(r["messages"][-1].content)  # агент помнит: "Влад"

In prod, replace MemorySaver with PostgresSaver — state goes to the database, and the agent survives deployment. thread_id isolates dialogs of different users.

WHAT BREAKS AGENTS IN PRODUCTION

A demo on a laptop and an agent in prod are two different universes. Based on community experience and my own hard-earned lessons, here are the main pitfalls:

• Infinite loops. The model gets stuck in a tool call loop. Always set a hard iteration limit (e.g., recursion_limit in LangGraph). Without it, the agent will burn through the budget in minutes.
• Context bloat. History grows, tokens grow, cost grows quadratically. Trim old messages or summarize them.
• Hallucinated arguments. The model invents non-existent tool parameters. Validate input via Pydantic before execution.
• Silent tool failures. API went down — return error text to the agent, not an exception. It often knows how to try another path.
• No tracing. Without a step-by-step log, you won't understand why the agent made a dumb decision. Set up observability from day one.

By rough community estimates, a naive agent without loop control and context trimming easily spends 3–5 times more tokens than needed. Discipline in state management is direct money savings.

TOOL DESIGN — WHERE SUCCESS IS DECIDED

Secret, which tutorials keep silent about: the quality of an agent depends 70% not on the model, but on design of tools. The model is as smart as its function descriptions are understandable to it.

• Write descriptions for the model, not for people. Clear «Return account balance in USD by user ID» beats dry «get_balance».
• One tool — one action. Don’t make a «Swiss army knife» with ten modes. The model gets confused.
• Return structured result. JSON or clear text, not a raw dump of 5000 tokens.
• Make tools idempotent, where possible. The agent may call the function twice — this should not break data.

Practice: start with 2–3 tools. An agent with five well-described functions is more reliable than with thirty vague ones. Expand only when the bottleneck is genuinely a lack of capability, not poorly written descriptions.

If you want to see which agent frameworks, MCP servers, and AI tools really take off, rather than drowning in hype — I post fresh finds from GitHub without fluff. Telegram channel REDDYX AI — new repositories every 30-60 minutes.