AI Agents Guide

TL;DR

• An AI agent is an LLM-driven control loop that observes state, reasons about a goal, selects actions (often tool calls), and repeats until the task is done or a stop condition is met.

• Agents differ from chatbots because they act autonomously across multiple steps - they don't just respond; they plan, execute, observe results, and adapt.

• The core components are always the same: a language model, a tool registry, a state store, and an orchestration loop that decides when to think, act, or stop.

• Reliability comes from constraints, not model intelligence alone - bounded iterations, typed tool schemas, human approval gates, and observability at every step.

• Most production systems are hybrids - deterministic workflows for predictable paths, agent loops for dynamic reasoning. Pure autonomy is rarely the right default.

Why This Matters

The first wave of LLM applications was chat: ask a question, get an answer. The second wave is action: resolve a support ticket, triage an incident, refactor a codebase, reconcile expenses, or research a market segment - tasks that require multiple steps, external data, and decisions along the way.

If you're building software that needs to do things rather than just say things, you're building an agent - whether you call it that or not. Customer support bots that look up orders and issue refunds. Dev tools that read files, run tests, and open pull requests. Research assistants that search, summarize, and cross-reference sources. These all share the same underlying pattern.

Understanding agents matters because the failure modes are different from chat. A chatbot that hallucinates is annoying. An agent that hallucinates a SQL query and deletes rows is a production incident. The engineering discipline - tool design, state management, guardrails, evaluation - is what separates demos from systems people trust.

The Problem AI Agents Solve

Single-shot LLM calls fail when:

1. The task requires external data the model wasn't trained on or can't know at inference time (live APIs, private databases, current events).

2. The task decomposes into multiple steps where each step depends on the outcome of the previous one.

3. The correct action isn't known upfront - the system must explore, backtrack, or try alternatives.

4. Side effects must happen in the real world - sending emails, updating records, deploying code - not just generating text.

Prompting alone handles none of this reliably. Fine-tuning teaches behavior but doesn't give live access to tools. RAG injects knowledge but doesn't execute actions. Agents combine reasoning with tool execution in a loop, closing the gap between "the model knows what to do" and "the system actually did it."

How We Got Here

Agent systems did not appear overnight. The production pattern is a stack of older ideas with an LLM as the controller:

Diagram: Evolution of AI agents

flowchart LR
    A[Scripts / cron] --> B[RPA / macros]
    B --> C[Workflow engines]
    C --> D[Tool-calling LLMs]
    D --> E[Agent loops]
    E --> F[HITL + durable agents]

Automation moved from scripts and RPA to tool-calling LLMs, then to bounded production agent loops.

Public systems that popularized the pattern include coding agents such as GitHub Copilot and Cursor, research summaries like Anthropic — Building effective agents, and orchestration runtimes such as LangGraph. The lesson across them is consistent: the loop is simple; production is the hard part.

What Is an AI Agent?

An AI agent is a software system where a large language model serves as the decision-making core. Given a goal and current state, the agent decides what to do next - typically by generating structured output that maps to a tool call, a plan update, or a final response.

Formally, an agent implements a policy π(state) → action in a loop:

def agent_loop(goal, tools, max_steps=10):
    state = {"goal": goal, "messages": [], "observations": []}

    for step in range(max_steps):
        action = llm.decide(state, tools)

        if action.type == "final_answer":
            return action.content

        if action.type == "tool_call":
            result = tools.execute(action.name, action.args)
            state["observations"].append(result)
            state["messages"].append({"role": "tool", "content": result})
        else:
            raise ValueError(f"Unknown action: {action.type}")

    raise RuntimeError("Agent exceeded max steps without completing goal")

This is deliberately simple. Every framework - LangChain, LangGraph, AutoGen, CrewAI - adds structure around this loop: typed state, checkpointing, parallel branches, human-in-the-loop interrupts, and retry logic.

Agents are not magic. They are control systems with an LLM as the controller. Treat them like any distributed system: define interfaces, bound execution, log everything, and test failure paths.

How AI Agents Work

An agent run proceeds through four phases that repeat until termination:

1. Perception

The agent receives input: user message, system prompt, conversation history, retrieved documents, tool outputs from prior steps, and structured state (task ID, permissions, budget remaining).

2. Reasoning

The LLM processes context and decides the next move. Depending on architecture, this may be implicit (direct tool selection) or explicit (chain-of-thought before action). Reasoning models like o1 and DeepSeek-R1 externalize this as visible thinking tokens.

3. Action

The agent executes a tool call, updates internal state, or emits a final response. Tool calls should be structured (JSON schema) so your runtime can validate arguments before execution.

4. Observation

Tool results flow back into state. The loop continues until the agent produces a final answer, hits a step limit, encounters an unrecoverable error, or a human approves/rejects an action.

ReAct interleaves reasoning traces and tool actions: the model thinks about what to do, calls a tool, observes the result, and repeats until it can answer.

Figure: ReAct interleaves thought, action, and observation until the task completes.
Source: Yao et al., ReAct (arXiv:2210.03629)

Execution lifecycle

Diagram: Agent execution lifecycle

stateDiagram-v2
    [*] --> Perceive
    Perceive --> Reason
    Reason --> Act: tool / plan
    Reason --> Done: final answer
    Act --> Observe
    Observe --> Reason
    Reason --> Interrupt: gated write
    Interrupt --> Reason: human decision
    Done --> [*]

Every transition should be logged; interrupt edges need durable checkpoints before gated writes.

Interrupt edges need a durable checkpoint so approval can arrive minutes or hours later without restarting the run.

Architecture

A production agent system has distinct layers:

Diagram: Production agent architecture

flowchart TB
    UI[Interface / API] --> Orch[Orchestrator]
    Orch --> LLM[LLM policy]
    Orch --> Tools[Tool registry]
    Orch --> Mem[Memory / checkpoints]
    Orch --> Guard[Guardrails]
    Orch --> Obs[Tracing / evals]
    Tools --> Ext[APIs, DBs, browsers, MCP]

The orchestrator owns control flow; tools, memory, guardrails, and observability surround the LLM policy.

The orchestrator is the critical piece. Raw while-loops work for prototypes; production needs checkpointing (resume after crash), idempotent tool design, and explicit termination conditions.

Step-by-Step Flow

Consider an agent tasked with: "What's our Q2 revenue for the EMEA region, and how does it compare to Q1?"

1. Parse goal - Orchestrator initializes state with user query and available tools: sql_query, chart_generator, send_slack_message.

2. Plan (optional) - Agent identifies subtasks: fetch Q2 EMEA revenue, fetch Q1 EMEA revenue, compute delta, format response.

3. First tool call - Agent calls sql_query with a generated SELECT statement filtered by region and quarter.

4. Observe - Database returns {q2_revenue: 4200000}.

Result appended to state.

5. Second tool call - Agent calls sql_query for Q1 with corrected date range based on schema observation.

6. Observe - Returns {q1_revenue: 3800000}.

7. Reason - Agent computes 10.5% growth, decides no chart needed for this simple comparison.

8. Final answer - Agent synthesizes: "Q2 EMEA revenue was $4.2M, up 10.5% from Q1's $3.8M."

9. Log trace - Full step sequence stored for audit and eval.

If step 3 returned a SQL error, a well-designed agent would read the error, inspect schema via another tool, rewrite the query, and retry - not fail silently or hallucinate numbers.

Real Production Example

Here's a minimal but production-shaped ReAct agent using LangGraph:

from typing import Annotated, TypedDict
from langchain_openai import ChatOpenAI
from langchain_core.tools import tool
from langgraph.graph import StateGraph, END
from langgraph.prebuilt import ToolNode
from langgraph.graph.message import add_messages
import operator

# --- Tools ---
@tool
def search_orders(customer_id: str) -> str:
    """Look up recent orders for a customer ID."""
    orders = db.query("SELECT id, status, total FROM orders WHERE customer_id = ?", customer_id)
    return str(orders[:5])

@tool
def issue_refund(order_id: str, reason: str) -> str:
    """Issue a refund for an order. Requires order_id and reason."""
    if not auth.can_refund(current_user, order_id):
        return "ERROR: Insufficient permissions"
    refund_id = payments.refund(order_id, reason=reason)
    return f"Refund {refund_id} issued for order {order_id}"

tools = [search_orders, issue_refund]
tool_node = ToolNode(tools)

# --- State ---
class AgentState(TypedDict):
    messages: Annotated[list, add_messages]
    step_count: Annotated[int, operator.add]

# --- Nodes ---
llm = ChatOpenAI(model="gpt-4o", temperature=0).bind_tools(tools)

def agent_node(state: AgentState):
    response = llm.invoke(state["messages"])
    return {"messages": [response], "step_count": 1}

def should_continue(state: AgentState) -> str:
    last = state["messages"][-1]
    if state.get("step_count", 0) >= 8:
        return "end"
    if last.tool_calls:
        return "tools"
    return "end"

# --- Graph ---
graph = StateGraph(AgentState)
graph.add_node("agent", agent_node)
graph.add_node("tools", tool_node)
graph.set_entry_point("agent")
graph.add_conditional_edges("agent", should_continue, {"tools": "tools", "end": END})
graph.add_edge("tools", "agent")

agent = graph.compile()

result = agent.invoke({
    "messages": [
        {"role": "system", "content": "You are a support agent. Verify order status before issuing refunds."},
        {"role": "user", "content": "Customer C-8842 says order O-991 was charged twice. Help them."},
    ],
    "step_count": 0,
})

Key production details in this example: typed tools with docstrings (used for schema generation), permission checks inside tools (not trusting the LLM), step limits to prevent runaway loops, and a system prompt that encodes business rules.

Design Decisions

Comparisons

Agents vs chatbots

Agents vs deterministic workflows

Use a workflow when the step graph is known; use an agent when the next tool depends on intermediate observations. Most production systems mix both - see Workflows vs Agents.

Agents vs Agentic RAG

RAG retrieves knowledge. An agent may call retrieval as one tool among many. Agentic RAG is the specialized case where the loop mainly decides what and how to retrieve. Do not rename every chatbot-with-search as an agent - reserve the term for systems that plan, act, and terminate under constraints.

Decision tree: do you need an agent?

Decision tree: When to use an agent

flowchart TD
    A[Is the task multi-step with external actions?] -->|No| B[Single LLM call / chatbot]
    A -->|Yes| C[Is the happy path fully enumerable?]
    C -->|Yes| D[Prefer workflow / DAG]
    C -->|No| E[Agent loop with step limits]
    E --> F{Irreversible writes?}
    F -->|Yes| G[Add HITL + durable checkpoints]
    F -->|No| H[Ship with traces + evals]
    G --> H
    D --> I{Need open-ended branch?}
    I -->|Yes| J[Hybrid: workflow + agent nodes]
    I -->|No| K[Keep deterministic]

Start with the simplest control plane that meets the task - escalate to agents, HITL, and durability only when needed.

Common Mistakes

1. Giving agents too many tools - A registry of 40 tools overwhelms the model. Curate 5–10 relevant tools per task type, or use a router agent that selects a tool subset first.

2. No step limits - Agents can loop indefinitely, burning tokens and API budget. Always set max_iterations and alert when hit.

3. Trusting LLM-generated SQL/code without sandboxing - Execute against read-only replicas, use parameterized queries, and never give write access by default.

4. Poor tool descriptions - The model chooses tools based on names and docstrings. Vague descriptions cause wrong tool selection more often than model capability limits.

5. No observability - Without step-level traces, debugging a failed 7-step agent run is guesswork. Log every LLM input/output and tool result.

6. Treating agents as chatbots with tools bolted on - A single tool call isn't an agent. The value is in multi-step reasoning with observation feedback.

Where It Breaks Down

• Long-horizon tasks - Agents lose coherence over 15+ steps. Decompose into sub-agents or use Plan-and-Execute architectures (Agent Architectures).

• Ambiguous goals - "Make the codebase better" has no termination condition. Agents need concrete, verifiable objectives.

• Adversarial inputs - Prompt injection via tool outputs (e.g., a webpage telling the agent to ignore instructions) is a real attack surface. Sanitize external content.

• Non-deterministic cost - A simple question might take 1 step or 8. Budget caps and model routing are essential for predictable billing.

• Evaluation difficulty - End-to-end agent quality is hard to measure with single metrics.

You need task-specific success criteria and step-level checks.

When NOT to Use AI Agents

Skip a full agent loop when:

1. A single LLM call or template is enough - FAQ answers, classification, short summarization.
2. The path is fully known - fixed ETL, deterministic approvals, or a Temporal/workflow DAG with no open-ended branching.
3. You cannot bound side effects - no RBAC, no sandbox, no audit log, no HITL for writes.
4. Latency budgets are sub-second - multi-step agents commonly take 10–60s; stream status or redesign.
5. You lack an eval suite - without task success metrics, autonomy is guessing.

In those cases prefer tool calling inside a thin API, a workflow, or retrieval-only RAG.

Running in Production

Best Practice

✅ Best Practices - Bound steps and tools, gate irreversible writes, trace every transition, and evaluate task success on a fixed suite before widening autonomy.

Important

Never give an agent write access to production systems without human approval gates until you've measured task success rate above 95% on a representative eval set - and even then, keep audit trails.

Related Guides

• Models: GPT-5, Claude Fable, Claude Opus, Claude Sonnet, Claude Haiku — foundation models commonly used as agent brains.

• Companies: OpenAI, Anthropic — primary model providers for production agent stacks.

• Orchestration: LangGraph, LangChain, Cursor, LlamaIndex, CrewAI, AutoGen, OpenAI Agents SDK, PydanticAI - compare in Best AI Agent Frameworks.

• Tool protocols: Model Context Protocol (MCP) - standard for connecting agents to external data and tools.

• Memory & durability: Agent memory, LangGraph checkpointers, Temporal for long-running workflows - see Durable Execution.

• Observability: LangSmith, Langfuse, Braintrust, Arize - trace agent runs, evaluate quality, detect regressions. See Agent Evaluation.

• Head-to-heads: LangGraph vs CrewAI · OpenAI Agents SDK vs LangGraph

• Tool Calling: The mechanism agents use to invoke external capabilities.

• Agent Evaluation: Task success, trajectories, tool-call accuracy, and production eval.

• Human-in-the-Loop: Approval gates before irreversible actions.

• Durable Execution: Checkpointing and resume for long-running agents.

• Multi-Agent Handoffs: Delegation to specialist agents.

• Agent Architectures: ReAct, Plan-and-Execute, Reflexion.

• Agent Memory: Short-term and long-term state patterns.

• Workflows vs Agents: When autonomy helps vs hurts.

• Guardrails: Programmatic safety constraints.

• Agentic RAG: Agents that decide retrieval strategy.

If you understood this topic, read next:

Diagram: Recommended learning path

flowchart LR
    A[Agents] --> B[HITL]
    B --> C[Durable]
    C --> D[Handoffs]
    D --> E[Memory]
    E --> F[Multi-agent]

Prerequisites: Large Language Models · Tool Calling · Prompt Engineering

Next topics: Human-in-the-Loop · Durable Execution · Multi-Agent Handoffs · Agent Architectures

Estimated time: 50 min · Difficulty: Intermediate

Interview Questions

1. What defines an AI agent vs a chatbot or a workflow?

   • Expected: multi-step observe → reason → act loop with external side effects; contrast with single-turn chat and deterministic DAGs (Workflows vs Agents).

2. What belongs in the tool registry for a production agent?

   • Expected: narrow typed tools (3–7 per task), timeouts, RBAC, idempotency for writes—not a flat list of 40 generic functions (Tool Calling).

3. How do you prevent runaway agent loops?

   • Expected: hard max_iterations, cost caps, circuit breakers on repeated tool failures, structured termination conditions.

4. When would you add human-in-the-loop?

   • Expected: irreversible or externally visible writes (refunds, sends, deploys); pair with durable checkpoints (Human-in-the-Loop, Durable Execution).

5. How do you evaluate agent quality in production?

   • Expected: task-level success on a representative eval set, step-level traces, edit/reject rates on HITL gates—not single-turn BLEU.

6. What is the difference between agent memory and RAG?

   • Expected: memory stores agent experience and session state; RAG retrieves external documents—often combined (Agent Memory, Agentic RAG).

7. When should you split into multiple agents?

   • Expected: only when clear specialist roles and separate tool policies improve evals; otherwise single agent + router (Multi-Agent Systems).

8. Name two failure modes of agents in production.

   • Expected: wrong tool selection, unbounded loops, prompt injection via tool outputs, non-idempotent retries, or cost blowups—tie to mitigations in this guide.

Key Takeaways

• An AI agent is an orchestration pattern: observe → reason → act under explicit stop conditions.
• Side effects change the risk model - wrong actions matter more than wrong answers.
• Bound steps, tools, and permissions before chasing smarter models.
• HITL and durable execution are how production systems earn autonomy.
• Prefer workflows for known paths; reserve agents for open-ended branching.
• Trace every step and evaluate task success - demos without evals do not become products.
• Framework choice matters less than control-plane discipline; start from Best AI Agent Frameworks when comparing stacks.

FAQs

What is the difference between an AI agent and a chatbot?

A chatbot responds to messages in a single turn (or multi-turn conversation without external actions). An agent autonomously executes a loop of reasoning and tool calls until a goal is achieved. If your system calls APIs, queries databases, or modifies state, it's an agent.

Do I need a framework to build agents?

No. A while-loop with an LLM and tool executor is a valid agent. Frameworks like LangGraph add checkpointing, parallelism, and human-in-the-loop - valuable in production but not required to start.

How many tools should an agent have?

Start with 3–5 tools focused on one task domain. Research shows tool selection accuracy degrades as registry size grows. Use dynamic tool loading or a router if you need more.

What's a reasonable step limit?

8–15 steps for most tasks. Customer support flows rarely need more than 10. Research tasks may need 20 with sub-agent delegation. Always enforce a hard cap.

Can I use open-source models for agents?

Yes. Llama 3, Mistral, and Qwen support tool calling. Smaller models struggle with complex multi-step reasoning - use them for simple tool selection, capable models for planning.

How do agents relate to RAG?

RAG retrieves knowledge; agents take actions. They're complementary - an agent might call a RAG retrieval tool as one step in a larger workflow. See Agentic RAG for the combined pattern.

What is human-in-the-loop for agents?

Pausing the agent loop before irreversible actions (refunds, deployments, emails) for human approval. LangGraph supports interrupt nodes natively. Use this for any write action until trust is established.

How do I test agents?

Create task scenarios with expected outcomes. Assert: correct final answer, correct tools called (in reasonable order), no forbidden tools used, and termination within step limit. Run in CI on every change.

Why do agents sometimes ignore tool results?

Context window pressure, ambiguous tool output format, or conflicting system instructions. Structure tool outputs consistently (JSON with clear fields), and instruct the agent to read observations before proceeding.

Are agents safe for customer-facing use?

With guardrails, yes - but treat write actions as privileged operations. Read-only agents (search, summarize, answer) are lower risk. Progressive autonomy: start read-only, add writes with approval, automate only after eval validation.

What's the difference between agentic AI and AI agents?

Agentic AI describes the paradigm - systems that act autonomously. AI agents are the concrete implementation. The terms are often used interchangeably; Agentic AI covers the broader shift in how we build AI software.

How do I reduce agent latency?

Parallel tool calls where independent, use faster models for intermediate steps, cache frequent lookups, stream status updates, and pre-fetch likely-needed data based on intent classification.

References

• ReAct: Synergizing Reasoning and Acting (Yao et al., 2022)
• LangChain Agents Documentation
• OpenAI Agents Guide

Further Reading

• Anthropic Tool Use Documentation
• LangGraph Documentation
• Microsoft AutoGen