AI Agents and Agentic Systems – ReAct, Tool Use and Multi-Agent Frameworks

The shift from LLMs as text generators to LLMs as autonomous agents is the defining architectural trend in applied AI in 2025-2026. A purely generative LLM can answer questions about the world as it was at training time, but it cannot book a meeting, query a live database, run a Python script, browse the current web, or take any action in the external world. Agents extend LLMs with these capabilities by embedding them in a plan-act-observe loop where each step is grounded in real tool outputs rather than parametric memory. For data scientists, the practical implications are significant: agents can automate data collection, execute and iterate on analysis code, query databases, generate visualisations, and synthesise reports with far less human orchestration than traditional data pipelines. This guide covers the complete agent architecture — the ReAct pattern, tool use and function calling, memory systems, multi-agent frameworks (LangGraph, CrewAI, AutoGen), reliability patterns, and the evaluation discipline that makes agents trustworthy in production.

ReAct — Reasoning and Acting in a Loop

The ReAct pattern (Yao et al., 2022) is the simplest and most robust agent architecture: at each step, the LLM receives the task description and the full history of previous thoughts, actions, and observations, and generates a new Thought-Action pair. The Thought is free-form natural language reasoning; the Action is a structured tool call. The tool executor runs the action and returns an Observation, which is appended to the history. This loop continues until the LLM generates a final answer or a stop condition is reached.

The power of ReAct relative to pure chain-of-thought is grounding: rather than reasoning entirely from parametric knowledge (which may be outdated or incorrect), the agent can retrieve current information via search, verify claims via database queries, and test hypotheses via code execution. ReAct has been shown to reduce hallucination significantly on knowledge-intensive tasks because every factual claim can be grounded in a tool observation rather than generated from memory. The connection to our prompt engineering guide is direct: ReAct prompts are few-shot prompts with thought-action-observation examples, and the quality of these examples (their diversity, correctness, and alignment with the target tasks) is the primary determinant of agent reliability. The generative AI guide covers the RAG retrieval component that ReAct agents commonly use for document-grounded question answering.

The agent loop in code is straightforward — the complexity is in the prompting, tool design, and error handling:

tools = [web_search, run_python, query_database, read_file]
messages = [{"role": "system", "content": REACT_SYSTEM_PROMPT},
            {"role": "user",   "content": task}]
for step in range(max_steps):
    response = llm.chat(messages, tools=tools)
    if response.tool_calls:
        for call in response.tool_calls:
            result = execute_tool(call.name, call.arguments)
            messages.append({"role": "tool", "content": result})
    else:
        return response.content   # final answer

Memory Systems — Short-Term, Long-Term and Episodic

Agent memory is not monolithic — it has multiple layers with different lifetimes and access patterns. Short-term (in-context) memory is the agent’s conversation history within the current session: every thought, action, and observation appended to the messages array. In-context memory is limited by the LLM’s context window (8K to 2M tokens depending on the model) and is lost at the end of the session. For agents processing long documents or running many steps, the context window fills up and earlier context is either truncated or summarised. External memory stores information beyond the context window: a vector database for semantic retrieval, a key-value store (Redis) for structured entity memory, or a SQL database for structured long-term facts. The agent retrieves relevant memories at each step by querying the vector store with the current task context — the same RAG pattern used in retrieval-augmented generation. Episodic memory stores summaries of past task executions, enabling the agent to learn from previous successes and failures — a simplified form of the reinforcement learning experience replay buffer.

The memory architecture has direct implications for agent reliability and cost. An agent that always starts from empty context (stateless) is predictable and easy to test but cannot accumulate knowledge across sessions. An agent with persistent external memory can improve over time but is more complex to debug and can carry forward incorrect beliefs from earlier sessions. For data science agents that automate recurring analysis workflows, the optimal architecture is typically stateless agents with a structured external memory of domain facts (schema documentation, column descriptions, business rule definitions) that is maintained by humans and retrieved by the agent as needed — connecting to the knowledge graph and data documentation infrastructure that well-run data organisations maintain.

Multi-Agent Systems and Production Reliability

Multi-agent systems assign specialised roles to different LLM instances and coordinate their collaboration to tackle tasks beyond any single agent’s capability. The canonical architecture: an orchestrator (planner) agent decomposes the high-level task into sub-tasks and assigns them to specialist agents; specialist agents (researcher, coder, analyst, critic) execute their sub-tasks and return results; the orchestrator synthesises results, resolves conflicts, and decides whether the task is complete. LangGraph implements this as a directed graph where nodes are agents and edges are conditional transitions based on agent outputs — enabling branching, looping, and parallel execution of sub-tasks.

Production reliability requires treating agents as software systems, not just prompts. Key reliability patterns: (1) Schema-validated tool calls — define JSON schemas for all tool inputs and validate the LLM’s generated arguments before execution, returning descriptive error messages (not stack traces) when validation fails; (2) Deterministic fallbacks — when the agent fails after N retries, fall back to a simpler deterministic approach (a rule-based system, a direct database query) rather than returning an error to the user; (3) Observation size limits — truncate large tool observations (a 10,000-row query result) before adding them to context, summarising with a separate LLM call if needed; (4) Evaluation-driven development — maintain an eval harness of representative tasks and run it after every agent prompt or tool change, as the emergent nature of agent behaviour means changes in one component can unexpectedly affect others. The connection to our ML monitoring guide is direct: production agents require the same systematic monitoring — latency tracking, error rate alerting, output quality sampling — as any other ML system.

✦ SUMMARIZE THIS ARTICLE WITH AI

ChatGPT Perplexity Claude Grok

Prompt engineering — ReAct prompts, few-shot examples, instruction structuring — is in our Prompt Engineering guide. Generative AI and RAG that agents use for knowledge retrieval are in our Generative AI guide. Vector databases for agent external memory and RAG retrieval are in our Vector Databases guide. LLM fine-tuning to improve base model instruction following for agents is in our LLM Fine-Tuning guide. ML monitoring for production agent observability is in our ML Monitoring guide. Knowledge graphs for structured agent memory and domain knowledge are in our Knowledge Graphs guide.