What is an AI Agent?
Core concepts & anatomy

Definition

An AI agent is a system that perceives its environment, reasons about what to do, and takes actions — repeatedly, in a loop — until a goal is achieved or a stopping condition is met.

The key distinction from a standard LLM call is the loop. A single prompt-response exchange is not agentic. An agent runs across multiple steps, uses tools, and adapts its behaviour based on the results of prior actions.

Agent vs Assistant

The key difference is the loop and autonomy. An assistant responds to one prompt and waits. An agent takes the response, observes the result, decides what to do next, and acts again — without requiring human input at each step.

Agent vs Automation

Traditional automation executes a fixed script: if X then Y. It is fast, reliable, and auditable — but brittle. Any input outside the expected range breaks it. An AI agent reasons about what to do given the current situation. It handles ambiguity, adapts to unexpected inputs, and makes judgment calls. The trade-off is that it is slower, harder to audit, and can fail in unpredictable ways.

Why Now?

Agentic AI became practical when three capabilities matured simultaneously. Reliable tool use — LLMs can now call functions with structured arguments and handle results consistently (Claude 3+, GPT-4, Gemini 1.5+). Long context windows — 100k–1M token contexts allow agents to hold large plans, documents, and histories without lossy compression. Instruction following — modern LLMs respect complex, multi-step system prompts consistently enough to build reliable loops around. None of these individually created agents. Together, they made the loop reliable enough to ship.

Perception — Reading the Environment

Perception is how the agent reads its current situation. Everything the agent "sees" must fit in its context window: the original user goal, prior conversation history, results from previous tool calls, retrieved documents, and any structured data passed from external systems.

Reasoning — Deciding What to Do

Reasoning is the LLM's core step: given the current context, what should the agent do next? This may involve decomposing the goal into sub-tasks, selecting a tool, generating a response, or deciding the task is complete. Reasoning quality is heavily influenced by the system prompt, the model's instruction-following ability, and the reasoning pattern used.

Action — Acting on the World

Actions are the agent's interface to the world. They are executed after the reasoning step and their results are fed back into the next perception cycle. Actions range from low-risk reads to high-risk irreversible writes. Apply the minimal footprint principle: prefer reversible actions, request only the permissions needed, and escalate to human approval before irreversible actions.

Memory — Persisting State

Memory is how the agent persists and retrieves information across steps and sessions. Without memory, every agent step starts from scratch. There are four memory types, each with different scope and implementation requirements.

The Agent Loop

The loop is the core execution cycle. It repeats until the agent decides the task is done, a step limit is reached, or a human intervenes. Always set a MAX_STEPS budget. An agent stuck in a bad loop will run until it times out or depletes your token budget.

while not done:
  context  = build_context(goal, history, memory)
  response = llm(system_prompt, context)

  if response.type == "tool_call":
    result = execute_tool(response.tool, response.args)
    history.append({"tool": response.tool, "result": result})

  elif response.type == "finish":
    return response.output   # ✓ Done

  elif response.type == "error":
    history.append({"error": response.reason})
    # model will reason about the error on next turn

  step_count += 1
  if step_count >= MAX_STEPS:
    raise StepLimitExceeded

Task Agents

General-purpose agents built to complete a goal defined in natural language. The most common type in production. Given a task like "book a meeting with everyone on this list," a task agent plans the steps, calls calendar and email APIs, handles failures, and reports back.

Coding Agents

Specialised agents for software development tasks — writing, running, testing, and debugging code. They operate in sandboxed environments with access to a shell, file system, and test runner. The key design challenge is managing long-lived file state and multi-step test feedback loops — the agent must track which files exist, what tests pass, and how the codebase has evolved across many steps.

Browser Agents

Agents that control a web browser — navigating pages, filling forms, clicking buttons, and extracting information. They must handle dynamic, unpredictable web UIs that were not designed for machine interaction. Vision-based agents (screenshot grounding) work on any UI; DOM-based agents are faster but fragile to site changes.

Research Agents

Agents that gather, synthesise, and report on information from multiple sources. They typically combine web search, document retrieval, and structured reasoning to produce written outputs. The primary failure mode is hallucination — the agent cites sources incorrectly or fills gaps with invented facts. Mitigation: require citations for every factual claim and implement a verification step.

Voice Agents

Real-time agents operating over audio. The loop must complete within milliseconds to feel natural. Typically built on speech-to-text → LLM → text-to-speech pipelines, with tool calls happening asynchronously to avoid blocking the audio stream. Latency is the dominant constraint — every added tool call adds 300–800ms to the response time.

ReAct — Reason + Act

ReAct (Reason + Act) interleaves reasoning traces with tool calls. Before each action, the agent writes a Thought explaining what it is doing and why. This makes the agent's behaviour interpretable and significantly reduces hallucination by forcing the model to commit to its reasoning before acting.

Plan & Execute

A planner LLM first decomposes the goal into an ordered list of sub-tasks. An executor then runs each sub-task sequentially or in parallel. Useful when the full plan can be determined upfront and the steps are largely independent of each other.

Reflection

After completing a task, a reflection step critiques the output and decides whether to iterate. A critic agent — or the same LLM with a different system prompt — evaluates quality and either accepts the result or sends it back for revision. This pattern dramatically improves output quality on tasks where quality is hard to specify upfront but easy to recognise after the fact.

Human-in-the-Loop (HITL)

The agent pauses at defined checkpoints and asks for human approval before proceeding. Essential for high-stakes or irreversible actions. The key design question is when to interrupt — too often and the agent is just a slow chatbot; too rarely and errors compound undetected.

Pattern Comparison

Agent = LLM + Tools + Memory + Loop + Goal
Loop  = Perceive → Reason → Act → Observe → (repeat)
Stop  = Goal achieved | Step limit | Human interrupt | Error

Automation  → Fixed rules, deterministic, fast, cheap, brittle
Assistant   → Single-turn LLM, no loop, no persistent memory
Agent       → Multi-step loop, tool use, memory, goal-directed, adaptive

ReAct          → Thought + Action interleaved — best default
Plan & Execute → Upfront plan → sequential execution — good for stable tasks
Reflection     → Actor + Critic loop — best for quality-sensitive outputs
HITL           → Human approval at checkpoints — required for high-stakes actions

1. Always set MAX_STEPS
2. Minimal footprint — read before write, reversible before irreversible
3. Validate all tool outputs — assume adversarial content is possible
4. Instrument every step — latency, tokens, tool, input, output
5. Build evals before shipping