Skip to main content
Cloud & AI Hub
Browse
Glossary AI Directory Playgrounds Models Prompts Explainers Strategy Matrix Benchmark Decoder
AI Fundamentals

Aliases: Agentic AI, LLM agent

AI Agent

An LLM system that plans, calls tools, observes results, and iterates in a loop to complete tasks rather than answering once.

Last reviewed: July 25, 2026

What is an AI agent?

An agent is an LLM running in a loop: it receives a goal, decides which tool to call (search, code execution, database query, API), observes the result, and repeats until done. The difference from a chatbot is autonomy over multiple steps — the model, not hardcoded logic, decides what happens next.

Workflow vs agent — the distinction that matters

Most production “agents” are actually workflows: LLM calls chained in developer-defined steps (classify → retrieve → draft → check). True agents let the model steer dynamically. Workflows are predictable, debuggable, and cheaper; agents handle open-ended tasks where you can’t enumerate steps. Start with a workflow; graduate to an agent only when the task genuinely requires dynamic planning. This is the most repeated — and most ignored — advice in the field.

What changed by 2026

Reasoning models made single-agent loops far more reliable, collapsing many elaborate multi-agent frameworks into “one good model + good tools.” Tool connectivity standardized around MCP. Retrieval moved from pipeline RAG toward agentic search — the model calls retrieval tools just-in-time. Memory and context management (“context engineering”) became the core engineering discipline.

Cost reality

Agents multiply everything: a 20-step loop is 20+ LLM calls, each re-sending a growing context window. A task a chatbot answers for 0.01cancostanagent0.01 can cost an agent 1–5. Error rates compound too — 95% per-step reliability is ~36% failure over 20 steps. Budget caps, step limits, and checkpoints are production requirements, not options.

What people get wrong

  • Reaching for multi-agent frameworks first. Most tasks need one model with 3–5 well-designed tools.
  • Vague tool definitions. Agents are only as good as their tools’ names, descriptions, and error messages — treat tool design like API design for a junior engineer.
  • No offline evals. Agent behavior varies run-to-run; without a task suite you can’t tell if changes help.

Try it in code

An agent is a while-loop with a budget. This is the skeleton under every framework:

MAX_STEPS = 15
MAX_COST = 2.00      # dollars - agents need budgets, not vibes

def agent(goal, tools):
    messages = [{"role": "user", "content": goal}]
    cost = 0.0
    for step in range(MAX_STEPS):
        response = llm(messages, tools=tools)
        cost += response.usage_cost
        if cost > MAX_COST:
            return "stopped: budget exceeded", messages    # checkpoint, don't burn
        if response.stop_reason != "tool_use":
            return response.text, messages                 # done
        call = response.tool_call
        result = execute(call.name, call.arguments)        # your code, validated
        messages.append(response.to_message())
        messages.append({"role": "tool_result", "id": call.id, "content": result})
    return "stopped: step limit", messages

Step limits, cost caps, and returning the full trajectory (for observability) are not optional in production.

Advertisement (In-Content)

Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.