A standard LLM is a stateless input-output transformation: a message goes in, text comes out. Between turns there is no persistent state, no access to the outside world, and no capability to take actions beyond generating words. It is powerful but passive.

An AI agent wraps that LLM with tools, memory, and a loop. The LLM becomes the "brain" — it decides what to do. Tools are the "hands" — they actually do it. The agent pursues a goal across multiple steps, using the result of each action to inform the next. Real-world example: Devin reads a GitHub ticket, writes code across 15 files, runs the test suite, and iterates until all tests pass — without a human in the loop for each file.

Agency is not binary. It exists on a spectrum from a pure LLM that never touches the outside world, to a fully autonomous system that operates for hours without human input. Understanding where on this spectrum your system sits is the first design decision in building any agent — it determines safety requirements, reliability challenges, and appropriate use cases.

Every agent — regardless of framework or task domain — is built from the same four primitives. These are not optional enhancements; they are the minimal set of components required for an LLM to pursue a multi-step goal in the world.

Designing an agent requires explicitly specifying what it can see (perception space) and what it can do (action space). These two boundaries define capability and determine risk. An unrestricted write action space with irreversible operations is dangerous; a read-only agent is safe but limited.

The agent loop is the fundamental runtime of any multi-step agent. It is deceptively simple: observe the current state, ask the LLM what to do, execute the chosen action, update the context, and repeat. Everything else — ReAct, tool calling, memory retrieval, planning — is a variation on this core loop.

One important consequence: every loop iteration adds tokens to the context window. Long tasks can exhaust the context limit. A production agent must decide what to keep verbatim, what to summarise, and what to offload to long-term memory. This is one of the primary engineering challenges in building reliable agents.

The concept of an autonomous goal-seeking agent is decades old in AI research. What changed between 2022 and 2024 is the convergence of three enabling factors that finally made production agents practical.

LLMs have three fundamental limitations that tools directly address. Knowledge cutoff: training data has a fixed date — models cannot tell you today's stock price or last night's sports result. Computation: LLMs are unreliable at precise arithmetic, code execution, and structured data queries. Side effects: a language model can describe writing an email but cannot actually send one. Tools bridge each of these gaps, turning a model that only speaks into one that acts.

Before structured function calling, using tools required prompting the model to output JSON and then parsing it — a fragile approach that broke on any formatting variation. OpenAI's function calling API (June 2023) changed this: the model now outputs a structured tool_call object guaranteed by the API, not a string that needs parsing. Anthropic's tool use API follows the same pattern with minor schema differences.

The round-trip has exactly six steps: define tools → model requests a tool call → developer executes the function → developer returns the result → model reasons over the result → model produces the final answer. The developer drives steps 3 and 4; the model does everything else.

# Anthropic Tool Use — complete working example
import anthropic, json

client = anthropic.Anthropic()

tools = [{
    "name": "get_weather",
    "description": "Get current weather for a city. Returns temp and conditions.",
    "input_schema": {
        "type": "object",
        "properties": {
            "city": {"type": "string", "description": "City name e.g. 'Tokyo'"},
            "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
        },
        "required": ["city"]
    }
}]

def get_weather(city: str, unit: str = "celsius") -> dict:
    return {"city": city, "temperature": 22, "condition": "sunny", "unit": unit}

def run_agent(user_message: str) -> str:
    messages = [{"role": "user", "content": user_message}]

    while True:
        response = client.messages.create(
            model="claude-sonnet-4-6", max_tokens=1024,
            tools=tools, messages=messages
        )
        if response.stop_reason == "end_turn":
            return next(b.text for b in response.content if b.type == "text")

        if response.stop_reason == "tool_use":
            messages.append({"role": "assistant", "content": response.content})
            tool_results = []
            for block in response.content:
                if block.type == "tool_use":
                    result = get_weather(**block.input)         # execute the function
                    tool_results.append({
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": json.dumps(result)
                    })
            messages.append({"role": "user", "content": tool_results})
            # loop continues — model sees tool results and responds

print(run_agent("What's the weather in Tokyo right now?"))
# → "Currently in Tokyo: 22°C and sunny."

A tool schema is a prompt. The model reads your name, description, and parameter descriptions to decide whether to call the tool, when to call it, and what arguments to pass. A vague or misleading schema leads to incorrect tool calls or failed executions — and these errors compound when tools call other tools.

name: "weather"
description: "weather tool"
parameters:
  location: string

name: "get_current_weather"
description: "Retrieve current conditions
  for a city. Returns temp, condition,
  humidity, wind. Use for current weather.
  NOT for historical data."
parameters:
  city: "Full name e.g. 'Paris, France'"
  unit: celsius|fahrenheit (optional)

Best practices: verb_noun naming (get_weather, search_web, create_file); description states what it does AND when to use it; parameters include format examples ("e.g. 'Paris, France'"); required vs optional explicitly declared; enum constraints where possible. Think of it as writing documentation for an AI colleague who will read it exactly once before making a decision.

To understand how agents really work, trace a complete multi-step execution. Task: "Find the top 3 Python packages for data visualisation and compare their GitHub stars." The agent needs to: (a) discover which packages are popular, (b) fetch star counts for each, and (c) synthesise the results. Three separate tool calls, four LLM invocations.

Modern LLM APIs support returning multiple tool calls in a single model response. When the model determines that two tool calls are independent — neither depends on the output of the other — it can request them simultaneously. The developer then executes both in parallel and returns both results in a single follow-up message. This typically reduces latency by 30–50% for tasks with multiple independent lookups.

Before MCP, every agent framework defined tools differently: LangChain tools, AutoGen tools, and custom code were all incompatible. A tool built for one framework couldn't be used in another without rewriting the wrapper. Anthropic's Model Context Protocol (released 2024) is an open standard that solves this — think of it as HTTP for tool use.

An MCP server exposes tools over a standardised JSON-RPC interface (via stdio or HTTP+SSE). Any MCP-compatible client can connect to any MCP server without modification. The ecosystem already includes servers for: filesystem, PostgreSQL, Slack, GitHub, Google Drive, Puppeteer (browser control), and dozens more.

Chain-of-thought prompting was originally a single-turn technique: "Let's think step by step" before answering dramatically improved multi-step reasoning on math and logic tasks. In agents, CoT becomes something more structural — it is the backbone of every decision step. Before acting, the model writes out its reasoning. This reasoning serves as working memory and directly constrains the next action.

Verbalised reasoning helps agents in four concrete ways: it forces commitment to a plan before executing an irreversible action; it makes the agent's reasoning auditable — you can inspect exactly why a choice was made; it enables error recovery — bad reasoning is visible and can be interrupted; and it helps the model notice contradictions before they compound across multiple steps.

Yao et al. (Princeton/Google, 2022) introduced ReAct in "ReAct: Synergising Reasoning and Acting in Language Models". The core insight: interleave reasoning traces (Thought) with tool-grounded actions (Action / Observation) step by step. Not "think then act" as two separate phases — but thinking and acting interwoven at every step.

Pure reasoning (CoT) lets models hallucinate facts with no grounding in reality — there is nothing to correct wrong assumptions. Pure acting wastes tool calls without strategy — the model fires searches randomly without a plan. ReAct solves both: each Observation updates the model's plan; each Thought grounds the next Action in accumulated evidence. The original paper showed ReAct outperforms CoT-only and Act-only on HotpotQA, FEVER, and WebShop benchmarks.

Multi-hop questions require chaining multiple lookups where each result informs the next query. ReAct handles this naturally because each Observation is added to the context before the next Thought. Task: "What is the population of the capital city of the country that hosted the 2020 Olympics?" — requires three information hops.

ReAct requires no framework — it is just the standard tool-use loop with a system prompt that instructs the model to think before acting. The key is the system prompt structure and the loop that feeds observations back to the model. The implementation below is complete and runnable with the Anthropic API.

from anthropic import Anthropic

client = Anthropic()

tools = [{
    "name": "search",
    "description": "Search the web for current information. Use for factual queries, current events, or when you need to look something up.",
    "input_schema": {
        "type": "object",
        "properties": {
            "query": {"type": "string", "description": "Search query"}
        },
        "required": ["query"]
    }
}]

def mock_search(query: str) -> str:
    results = {
        "2020 Summer Olympics host": "Held in Tokyo, Japan in 2021",
        "Tokyo population": "City: ~13.96M · Metro: ~37.4M (2024)"
    }
    for key in results:
        if key.lower() in query.lower():
            return results[key]
    return f"Search results for: {query}"

def react_agent(task: str, max_steps: int = 10) -> str:
    system = """You are a helpful agent. Think step by step before each action.
Always start with a Thought explaining your reasoning before calling a tool."""

    messages = [{"role": "user", "content": task}]

    for step in range(max_steps):
        response = client.messages.create(
            model="claude-sonnet-4-6", max_tokens=1024,
            system=system, tools=tools, messages=messages
        )
        messages.append({"role": "assistant", "content": response.content})

        if response.stop_reason == "end_turn":
            return next(b.text for b in response.content if b.type == "text")

        tool_results = []
        for block in response.content:
            if block.type == "tool_use":
                result = mock_search(block.input["query"])
                print(f"  Action: {block.name}({block.input})")
                print(f"  Observation: {result}\n")
                tool_results.append({
                    "type": "tool_result",
                    "tool_use_id": block.id,
                    "content": result
                })
        messages.append({"role": "user", "content": tool_results})

    return "Max steps reached without final answer"

answer = react_agent(
    "What is the population of the capital of the 2020 Olympics host country?"
)
print(f"\nFinal Answer: {answer}")

Standard ReAct agents repeat mistakes across attempts — there is no mechanism to learn from failure within a session. Shinn et al. (2023) introduced Reflexion ("Language Agents with Verbal Reinforcement Learning") to address this. After each failed attempt, the agent generates a verbal self-critique explaining what went wrong and what to try differently. This critique is stored in memory and prepended to the next attempt.

Reflexion adds three components to the standard loop: an Evaluator that judges whether an attempt succeeded, a Self-Reflection step that generates a verbal critique on failure, and a Memory store that accumulates critiques across attempts. The result is a form of in-session learning without any gradient updates — pure verbal reinforcement.

Yao et al. (2023) introduced Tree of Thoughts (ToT): instead of a single linear reasoning chain, maintain multiple candidate reasoning branches simultaneously. At each step, generate multiple next-thoughts, evaluate the promise of each (another LLM call), and explore the most promising — backtracking from dead ends using BFS or DFS.

Standard CoT picks one path and commits. If that path leads to a wrong conclusion there is no recovery. ToT is best for problems where early choices are high-stakes: puzzle solving, proof writing, strategic planning with multiple valid initial moves. The cost is significantly more LLM calls — often 5–20× more than ReAct. Use it only when the added cost is justified by problem complexity.

Agent memory maps directly onto human cognitive memory systems. In-context memory is working memory — everything visible to the model right now. Vector store memory is associative memory — retrieve by similarity ("what do I know about X?"). Episodic memory is autobiographical — specific events with timestamps ("what happened last session?"). Semantic/entity memory is world knowledge — structured facts ("who is Alice, what does she prefer?").

The context window is the agent's working memory. Every message, tool result, plan, and observation from the current session lives here. The LLM sees all of it simultaneously — no retrieval needed, no similarity search, no latency penalty. It is the default memory for any agent and is sufficient for most short tasks.

The fundamental limitation is the context window is finite. Models support 8K to 200K tokens depending on provider. Long multi-step tasks accumulate tokens rapidly: every tool result, every thought, every observation adds to the total. When context approaches the limit, the agent must decide what to keep, compress, or offload.

External memory lives outside the context window — in a database, vector store, or file system. The agent interacts with it via explicit tool calls: write stores important information, search retrieves relevant information at query time. External memory enables persistence across sessions, scalability beyond context limits, and cross-session learning.

The write/search interface is the minimal design. Every agent memory system needs at minimum three operations: memory_write(key, content, tags) to store, memory_search(query, n) for semantic retrieval, and memory_get(key) for exact lookup. The implementation below is a working in-memory vector store using sentence-transformers.

import json
from datetime import datetime
from sentence_transformers import SentenceTransformer
import numpy as np

class AgentMemory:
    """Simple in-memory vector store for agent memories"""

    def __init__(self):
        self.model = SentenceTransformer('all-MiniLM-L6-v2')
        self.memories = []  # list of {key, content, embedding, timestamp, tags}

    def write(self, key: str, content: str, tags: list = None) -> str:
        """Store a memory with its embedding"""
        embedding = self.model.encode(content)
        self.memories.append({
            "key": key,
            "content": content,
            "embedding": embedding,
            "timestamp": datetime.now().isoformat(),
            "tags": tags or []
        })
        return f"Stored memory: {key}"

    def search(self, query: str, n: int = 3) -> list:
        """Find n most relevant memories by cosine similarity"""
        if not self.memories: return []
        q_emb = self.model.encode(query)
        scores = [
            np.dot(q_emb, m["embedding"]) /
            (np.linalg.norm(q_emb) * np.linalg.norm(m["embedding"]))
            for m in self.memories
        ]
        top_n = sorted(zip(scores, self.memories), key=lambda x: -x[0])[:n]
        return [{"score": s, **m} for s, m in top_n]

# Usage
mem = AgentMemory()
mem.write("user_pref_1", "User prefers Python over JavaScript", tags=["preference", "code"])
mem.write("task_note_1", "User's project is a FastAPI service for invoice processing", tags=["project"])

results = mem.search("What programming language does the user prefer?")
print(results[0]["content"])  # "User prefers Python over JavaScript"

Vector store memory retrieves information by meaning, not by exact key. Each piece of stored text is converted into a dense numerical vector (embedding) by an embedding model. At retrieval time, the query is embedded and the vector database returns the stored items with the highest cosine similarity. This makes it possible to ask "What do I know about the user's technical background?" and retrieve all relevant stored facts, even if they use completely different words.

Episodic memory stores specific past events with timestamps — not just what was learned, but when it happened, in what context, and with what outcome. For agents, episodic memory enables cross-session continuity: the agent on Friday remembers the conversation from Monday without the user needing to re-explain.

Semantic memory stores structured facts about known entities — timeless information distinct from episodic "when it happened" logs. A user entity has: name, role, technical preferences, communication style, current projects. A project entity has: name, stack, status, key files, blockers. This structured profile grows as the agent learns more and eliminates the need to re-ask the same onboarding questions.

Three patterns cover the vast majority of production agent memory designs. Pattern selection depends on task length, session frequency, and personalisation requirements.

For simple tasks, ReAct's step-by-step approach is perfectly adequate — decide, act, observe, repeat. Planning becomes necessary when tasks involve irreversible actions (sending emails, committing code, deleting files), long horizons where the agent may lose track of the original goal after ten or more steps, or parallel sub-tasks where independent work streams could be executed concurrently for efficiency.

Planning also enables human oversight: when a complete plan is generated before any action is taken, a human can review and approve the plan before irreversible operations start. This is one of the most practical safety mechanisms in production agents.

Wang et al. (2023) introduced Plan-and-Solve: a two-phase architecture where a Planner LLM call generates a complete numbered plan, and an Executor loop carries out each step using tools. This separation provides a critical advantage: the full plan is explicit before any action is taken, enabling human review, dependency analysis, and progress tracking.

from anthropic import Anthropic

client = Anthropic()

def create_plan(goal: str) -> list:
    """Phase 1: Planner — generate a complete numbered plan"""
    response = client.messages.create(
        model="claude-sonnet-4-6", max_tokens=1024,
        messages=[{"role": "user", "content": f"""Create a numbered step-by-step plan for:

Goal: {goal}

Output ONLY a numbered list. Each step should be concrete and actionable. Max 7 steps."""}]
    )
    plan_text = response.content[0].text
    return [l.strip() for l in plan_text.split('\n')
            if l.strip() and l.strip()[0].isdigit()]

def execute_step(step: str, completed: list) -> str:
    """Phase 2: Executor — carry out one plan step"""
    context = "\n".join(f"- {s}" for s in completed)
    response = client.messages.create(
        model="claude-sonnet-4-6", max_tokens=1024,
        messages=[{"role": "user", "content": f"""Completed steps:
{context}

Execute this step and provide its output: {step}"""}]
    )
    return response.content[0].text

def plan_and_execute(goal: str) -> str:
    # Phase 1: generate full plan
    plan = create_plan(goal)
    print(f"Plan ({len(plan)} steps):")
    for i, step in enumerate(plan, 1):
        print(f"  {i}. {step}")

    # Phase 2: execute each step
    completed = []
    for step in plan:
        result = execute_step(step, completed)
        completed.append(f"{step} → {result[:80]}...")
        print(f"\n✓ {step}\n  {result[:200]}")

    return f"Completed {len(plan)} steps successfully"

plan_and_execute("Research and write a brief comparison of Redis vs Memcached")

Complex goals naturally form a tree of sub-goals. A top-level goal like "Build a data analysis report" decomposes into "Collect data", "Analyse data", and "Write report" — each of which decomposes further into concrete executable steps. Hierarchical planning makes this structure explicit. Independent sub-trees can run in parallel; sequential dependencies are enforced between tree levels.

Static plans assume the world matches their assumptions. In practice, steps fail: the database is down, the API changed, the file doesn't exist. An agent that cannot adapt to failure is brittle. Replanning is the mechanism for detecting when reality has diverged from the plan and generating a revised plan from the current state.

Three strategies, in order of cost: step retry — try the same step differently; partial replan — regenerate only the remaining steps given the new situation; full replan — abandon the current plan entirely and regenerate from the current state. The key is that the agent must actively recognise a failure condition rather than blindly proceeding.

Zhou et al. (2023) introduced Least-to-Most Prompting, inspired by educational scaffolding. Rather than attacking a complex question directly, the method first decomposes it into simpler sub-problems, then solves each in order — using prior solutions as context for the next. This approach excels at compositional problems where a complex answer genuinely depends on simpler intermediate results.

def least_to_most(question: str) -> str:
    """Stage 1: decompose. Stage 2: solve each subproblem in order."""

    # Stage 1: Decompose into ordered subproblems
    decompose = client.messages.create(
        model="claude-sonnet-4-6", max_tokens=512,
        messages=[{"role": "user", "content": f"""Break this question into simpler subproblems
that must be solved first, ordered from simplest to most complex.

Question: {question}

Output: A numbered list of simpler subproblems."""}]
    )
    subproblems = [l.strip() for l in decompose.content[0].text.split('\n')
                   if l.strip() and l.strip()[0].isdigit()]

    # Stage 2: Solve each subproblem, using prior answers as context
    context = f"Original question: {question}\n\nSubproblem solutions:\n"
    for sub in subproblems:
        resp = client.messages.create(
            model="claude-sonnet-4-6", max_tokens=256,
            messages=[{"role": "user", "content": f"{context}\nNow solve: {sub}"}]
        )
        context += f"\n{sub}: {resp.content[0].text}"

    # Final answer using accumulated subproblem solutions
    final = client.messages.create(
        model="claude-sonnet-4-6", max_tokens=512,
        messages=[{"role": "user", "content": f"{context}\n\nNow answer the original question."}]
    )
    return final.content[0].text

# Example: compositional maths/reasoning
answer = least_to_most(
    "If a train travels 120km in 1.5 hours and then 80km in 1 hour, what is its average speed?"
)
print(answer)

Subgoal decomposition is the general skill underlying all planning methods: given a goal, identify the minimal set of concrete sub-tasks that, when completed, guarantee the goal is achieved. The quality of decomposition determines everything downstream — bad decomposition leads to missing steps, incorrect dependencies, and wasted effort.

A single agent with all tools solves many problems — but hits four fundamental limits. Context overload: fifty tool calls in one context window approaches or exceeds any model's limit. Specialisation: a code-writing specialist with a focused system prompt and code-specific tools outperforms a generalist at the same task. Parallelism: three independent research threads can run simultaneously in three agents for 3× throughput. Verification: a separate critic agent reviewing the author agent's output catches errors that self-review misses.

Four structural patterns cover the vast majority of multi-agent system designs. Each makes different trade-offs between simplicity, flexibility, and parallelism.

The Supervisor/Worker pattern is the dominant architecture in production multi-agent systems. The Supervisor is an LLM whose sole job is orchestration — it understands the overall goal, decides which specialist to invoke and with what task, and synthesises results. It does not itself call tools. Worker agents are specialised: each has a focused system prompt, a specific tool set, and a narrow domain of responsibility.

from langgraph.graph import StateGraph, END
from langchain_anthropic import ChatAnthropic
from typing import TypedDict, Annotated
import operator

class AgentState(TypedDict):
    goal: str
    messages: Annotated[list, operator.add]
    next_agent: str
    final_output: str

llm = ChatAnthropic(model="claude-sonnet-4-6")

def supervisor(state: AgentState) -> AgentState:
    """Decides which agent to call next"""
    prompt = f"""You are an orchestrator managing a team of agents.

Goal: {state['goal']}
Progress: {state['messages'][-3:] if state['messages'] else 'None'}

Available agents: RESEARCHER, CODER, WRITER, FINISH
Which agent should act next? Respond with ONLY the agent name."""

    response = llm.invoke(prompt)
    return {**state, "next_agent": response.content.strip()}

def researcher(state: AgentState) -> AgentState:
    result = f"[Research results for: {state['goal']}]"
    return {**state, "messages": [f"Researcher: {result}"]}

def coder(state: AgentState) -> AgentState:
    result = f"[Code for: {state['goal']}]"
    return {**state, "messages": [f"Coder: {result}"]}

def writer(state: AgentState) -> AgentState:
    result = f"[Final document for: {state['goal']}]"
    return {**state, "messages": [f"Writer: {result}"], "final_output": result}

# Build the graph
graph = StateGraph(AgentState)
for name, fn in [("supervisor", supervisor), ("researcher", researcher),
                   ("coder", coder), ("writer", writer)]:
    graph.add_node(name, fn)

graph.set_entry_point("supervisor")
graph.add_conditional_edges("supervisor", lambda s: s["next_agent"], {
    "RESEARCHER": "researcher",
    "CODER": "coder",
    "WRITER": "writer",
    "FINISH": END
})
for node in ["researcher", "coder", "writer"]:
    graph.add_edge(node, "supervisor")  # workers always return to supervisor

app = graph.compile()
result = app.invoke({"goal": "Create a Python web scraper for HN jobs", "messages": []})

A handoff is the transfer of execution from one agent to another with relevant context. What gets transferred determines whether the receiving agent can proceed effectively: too little context and the agent re-does already-completed work; too much context and the receiving agent's context window overflows.

The minimal handoff payload should include: the current task description, relevant completed-step outputs, constraints and requirements, and optionally a summary of conversation history. The handoff type determines urgency and routing: specialisation (this requires coding — transfer to coder), escalation (this requires human approval — pause and notify), error (I failed — transfer to error-recovery agent), and completion (sub-task done — return to supervisor).

LangGraph (LangChain, 2024) is a graph-based framework for stateful multi-agent systems. Its core abstraction is a StateGraph: a directed graph where nodes are functions (agents or tools), edges are transitions, and a shared typed State dictionary persists across all nodes. Conditional edges route execution based on the current state — the LLM's output determines which node runs next.

LangGraph's key advantages over plain Python loops are built-in persistence (checkpoint state to a database — resume after failure, enable human-in-the-loop approvals), streaming (intermediate steps stream to the UI in real time), and parallel execution (fork-join for simultaneous node execution).

How agents communicate determines system reliability, debuggability, and scalability. Three communication patterns cover most production systems: shared state (agents read and write a common typed dictionary — LangGraph's model), message passing (agents send structured messages to each other — AutoGen's model), and function calling (supervisor calls worker as a tool with structured input/output). Shared state is easiest to debug; message passing is most flexible; function calling is the most familiar interface for developers.

Standard LLM evaluation is straightforward: fixed input, expected output, compute a score (BLEU, accuracy, human preference). Agent evaluation is fundamentally harder across five dimensions: multiple valid paths (many different tool call sequences can reach the correct answer — which counts?); process vs outcome (did the agent succeed by doing the right thing, or by luck?); stochasticity (same task, different execution every run); long horizons (50 steps — where exactly did it go wrong?); and irreversibility (some failures cannot be undone, limiting how many evaluation runs you can afford).

Production agent evaluation requires a controlled simulation environment: tools return deterministic results from a test fixture, enabling repeatable evaluation of the agent's decision-making independently of external API variability.

No single metric captures agent quality. Production agent monitoring requires tracking at least six dimensions simultaneously — success, efficiency, recovery, safety, cost, and latency. An agent that succeeds 90% of the time but costs 10× more than necessary is not production-ready.

Not all agent actions should be fully autonomous. Actions exist on a risk spectrum: read-only actions (search, read files) carry no irreversible risk and can auto-execute; reversible writes (draft email, temp file) are low risk; irreversible actions (send email, delete file, submit form) require explicit approval; critical actions (financial transactions, public communications, security changes) always require human review.

Prompt injection is a class of attack where malicious content in the environment hijacks the agent's behaviour. Unlike a chatbot where injection only generates text, an agent can execute code, send emails, and access files — making prompt injection potentially catastrophic rather than merely embarrassing.

Indirect injection is the most dangerous variant for agents: malicious instructions embedded in a web page, retrieved document, or tool result — content the agent is supposed to process, not follow. The agent doesn't distinguish "content to read" from "instructions to follow" without explicit architectural protections.

By 2024, AI agents have moved from research demonstrations to production products used by millions of developers and consumers. The systems below represent the state of the art across different application domains — each offers a case study in a different architectural approach to the core challenges of reliability, autonomy, and safety.

Code agents are the most mature agent category. The reasons are structural: code is verifiable (it either passes the tests or it doesn't), safe to iterate (test → error → fix is a tight feedback loop with no irreversible side effects), and the tools are well-defined (shell, editor, test runner — standard interfaces that haven't changed in decades).

The key lesson from SWE-Agent is that tool design matters as much as the model. Generic tools (bash, read_file) force the agent to navigate file systems and parse raw output manually. Purpose-built ACI tools (search_code, edit_function, apply_patch) return structured results that map directly to how a developer thinks about code — dramatically reducing the reasoning burden per step.

Computer use agents are the most general form of agent: instead of purpose-built APIs, the agent perceives a screenshot of any GUI application and takes actions via simulated mouse clicks and keyboard input. No integration work is required — if a human can see and click it, the agent can too.

Three patterns cover the architecture of most production agent deployments. Choosing the right pattern depends on task duration, response time requirements, and whether tasks can run independently in the background.

Production agents can cost $0.05–$5.00 per task depending on complexity. The dominant cost driver is LLM tokens — particularly in the planning and synthesis steps. The dominant latency driver is the number of serial LLM calls. Both can be dramatically reduced through model routing (match model size to step complexity), parallel tool execution, and result caching.

The open problems in agentic AI (2024–2026) are: long-horizon reliability (tasks spanning hours or days — compounding errors over hundreds of steps), cross-agent trust (how does agent A know agent B is trustworthy, not compromised or hallucinating), persistent identity (memory that degrades gracefully over months, not sessions), and self-improving agents (agents that improve their own tools and strategies through experience rather than requiring manual retraining).