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.

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.

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