Advanced Data Structures & Algorithms

Java Backend Modernization

Beginner's Guide to Data Structures

Agentic AI Systems

Data Engineering & Spark Mastery

Low-Level Design Interview Prep

Microservices Interview Roadmap

Design Patterns Interview Roadmap

Distributed Systems Interview Roadmap

Mastering Python Development

System Design Interview Prep

Distributed Systems Refresher

AI Engineering Launchpad

Architecture Patterns for Scalable Systems

RAG & Vector Search Mastery

Production DevOps & Reliability

Enterprise Patterns Playbook

Master Coding Interviews

Coding Techniques Interview Roadmap

Data Structures Interview Roadmap

Architecture Patterns Interview Roadmap

software-engineering-principles

Migrate your Spring Boot services from thread-pool exhaustion to JDK 21 virtual threads — the practical Spring developer guide

Adapting to Virtual Threads for Spring Developers

how-it-works-internals-explained

From WAL and MVCC to fsync and isolation levels — the internals behind every ACID guarantee in PostgreSQL, MySQL, Oracle, and SQL Server.

ACID Properties Explained: How SQL Databases Guarantee Atomicity, Consistency, Isolation, and Durability

How modern NoSQL databases achieve atomicity and isolation without a single machine

ACID Transactions in Distributed Databases: DynamoDB, Cosmos DB, and Spanner Compared

llm-engineering

Is an LLM a brain in a jar? To make it truly useful, we need to give it access to the world. This guide explains RAG and Agents.

Advanced AI: Agents, RAG, and the Future of Intelligence

Production AI needs explicit routing, memory, execution, and evaluation layers rather than one loop.

AI Architecture Patterns: Routers, Planner-Worker Loops, Memory Layers, and Evaluation Guardrails

datastructures-and-algorithms

Master shortest paths, dependency resolution, and cycle detection with robust Java solutions.

Advanced Graph Algorithms: Dijkstra, Topological Sort, and Disjoint Set Union (DSU)

An LLM can talk, but an AI Agent can *act*. We explain how Agents use the ReAct framework to brow...

AI Agents Explained: When LLMs Start Using Tools

A production-first guide to picking the right vector index for recall, latency, memory, and update patterns.

ANN Index Types Explained: When to Choose Flat, HNSW, IVF, or IVF-PQ

apache-spark-engineering

Process petabytes with Python: understand Spark's execution model, DataFrame transformations, partitioning strategy, and real-time streaming.

Apache Spark for Data Engineers: RDDs, DataFrames, and Structured Streaming

ACID guarantees consistency. BASE guarantees availability. We explain the trade-offs between SQL...

BASE Theorem Explained: How it Stands Against ACID

machine-learning-fundamentals

From the query-key-value formulation to multi-head attention — the mechanism that made transformers dominate AI

Attention Mechanism Explained: How Transformers Learn to Focus

system-design-interview-prep

They all sit in front of your servers. But do you need Nginx, HAProxy, or Kong? We clarify the roles of each component.

API Gateway vs. Load Balancer vs. Reverse Proxy: What's the Difference?

architecture-patterns-for-production-systems

Mobile apps need less data than Desktop dashboards. Why serve them the same JSON? The Backend for Frontend (BFF) pattern solves this.

Backend for Frontend (BFF): Tailoring APIs for UI

BFS explores graphs level by level using a queue — the key to shortest paths and level-order problems.

BFS — Breadth-First Search: Level-by-Level Graph Exploration

Backtracking is a brute-force algorithmic technique that solves problems by trying to build a sol...

Exploring Backtracking Techniques in Data Structures

big-data-engineering

Choose ingestion, serving, and ownership patterns deliberately when data platforms start to scale.

Big Data Architecture Patterns: Lambda, Kappa, CDC, Medallion, and Data Mesh

Why traditional databases fail at scale, what the 5 Vs really mean, and a practical map of the big data ecosystem from ingestion to insights.

Big Data 101: The 5 Vs, Ecosystem, and Why Scale Breaks Everything

Not all Binary Trees are created equal. We explain Full, Complete, Perfect, and Balanced Binary T...

Exploring Different Types of Binary Trees

Master Big O notation: measure algorithm efficiency from O(1) to O(n²) with growth diagrams, worked examples, and the interview mental model.

Big O Notation Explained: Time Complexity, Space Complexity, and Why They Matter in Interviews

Binary search has five distinct patterns — classic, leftmost, rightmost, rotated arrays, and 2D matrices.

Binary Search Patterns: Five Variants Every Senior Engineer Knows

agentic-ai-langchain-and-langgraph

LangChain's AgentExecutor handles simple loops — but stateful branching, long-running tasks, and human-in-the-loop require LangGraph's graph model.

From LangChain to LangGraph: When Agents Need State Machines

Learn LangGraph from scratch: StateGraph, typed state, nodes, edges, and your first LLM-agnostic stateful agent.

LangGraph 101: Building Your First Stateful Agent

Build ReAct agents in LangGraph: prebuilt create_react_agent vs custom StateGraph loop, with a coding assistant example.

The ReAct Agent Pattern in LangGraph: Think, Act, Observe, Repeat

Wire real capabilities into LangGraph agents: @tool decorator, ToolNode, bind_tools, parallel execution, and error handling.

LangGraph Tool Calling: ToolNode, Parallel Tools, and Custom Tools

## Scenario context

LangChain's `AgentExecutor` is a solid starting point — but it has five hard limits (no branching, no pause/resume, no parallelism, no human-in-the-loop, no crash recovery). LangGraph replaces the implicit loop with an explicit graph, unlocking every one of those capabilities. This post explains the mental model, compares both approaches in code, and helps you decide when to upgrade.

---

You built a LangChain agen…

This walkthrough focuses on **When a Working Agent Hits a Wall**.

Before making a design choice, clarify:

- It queries a knowledge base, calls a few tools, and returns useful answers.
- Then the product requirements arrive.
- "We need it to ask for user approval before it sends the email." You patch it with a flag.

**Concepts in play:** llm-agents-and-langgraph, graph-traversal-algorithms, sorting-and-searching-algorithms, database-indexing

## Stage 1 — Five Places Where AgentExecutor Runs Out of Road

- AgentExecutor implements a ReAct loop: reason, act (pick a tool), observe (read the output), repeat.
- That loop covers a large fraction of real-world agent tasks — but five patterns break it reliably.
- None of these is a bug in LangChain.
- AgentExecutor was designed as a general-purpose, easy-to-use agent loop.

*Applies **llm-agents-and-langgraph** to the decision above.*

**Observable outcome:** AgentExecutor was designed as a general-purpose, easy-to-use agent loop.

## Stage 2 — The State Machine Mental Model: From Recipes to Flowcharts

- The key mental shift is this: LangChain chain = a recipe.
- Execute step 1, then step 2, then step 3.
- Perfect for linear transformations.
- LangGraph StateGraph = a flowchart.

*Applies **graph-traversal-algorithms** to the decision above.*

**Observable outcome:** LangGraph StateGraph = a flowchart.

## Stage 3 — The Same Task, Two Ways: Research + Draft an Email

- The LangChain AgentExecutor Version This is clean and gets the job done.
- The LLM will call search web , read the results, then decide to call send email .
- But notice: there is no point in this code where you can intercept the agent before it sends the email.
- Adding an approval step means restructuring the entire calling code.

*Applies **sorting-and-searching-algorithms** to the decision above.*

```python
from langchain_openai import ChatOpenAI
from langchain.agents import AgentExecutor, create_react_agent
from langchain_core.tools import tool
from langchain import hub

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

@tool
def search_web(query: str) -> str:
    """Search the web for information on a topic."""
    # Replace with a real search integration (Tavily, Serper, etc.)
    return f"[Search results for: {query}] — Key facts retrieved."

@tool
def send_email(recipient: str, subject: str, body: str) -> str:
    """Send an email. USE THIS ONLY AFTER RESEARCH IS COMPLETE."""
    # In reality: sends the email. Here: simulates it.
    return f"Email sent to {recipient} with subject '{subject}'."

tools = [search_web, send_email]
prompt = hub.pull("hwchase17/react")  # standard ReAct prompt

agent = create_react_agent(llm, tools, prompt)
executor = AgentExecutor(agent=agent, tools=tools, verbose=True)

# This works — but you cannot pause for approval before send_email runs,
# cannot branch to a fallback if search_web returns empty,
# and cannot recover if the process crashes mid-run.
result = executor.invoke({
    "input": "Research climate change impacts and draft an email to the team."
})
print(result["output"])
```

```python
import operator
from typing import Annotated
from typing_extensions import TypedDict
from langchain_openai import ChatOpenAI
from langchain_core.messages import HumanMessage
from langgraph.graph import StateGraph, END
from langgraph.checkpoint.memory import MemorySaver

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

# ── 1. Typed state schema ────────────────────────────────────────────────────
class EmailAgentState(TypedDict):
    topic: str
    research_results: str
    draft: str
    human_feedback: str
    approved: bool
    retry_count: Annotated[int, operator.add]

# ── 2. Nodes — each is a plain Python function ──────────────────────────────
def research_node(state: EmailAgentState) -> dict:
    """Fetch research on the topic. Falls back gracefully if results are thin."""
    response = llm.invoke([
        HumanMessage(content=f"Summarize key facts about: {state['topic']}")
    ])
    return {"research_results": response.content}

def draft_node(state: EmailAgentState) -> dict:
    """Draft the email body using research results."""
    context = state["research_results"]
    feedback = state.get("human_feedback", "")
    prompt = f"Write a professional team email about {state['topic']}.\nResearch: {context}"
    if feedback:
        prompt += f"\nPrevious feedback to incorporate: {feedback}"
    response = llm.invoke([HumanMessage(content=prompt)])
    return {"draft": response.content, "approved": False}

def human_approval_node(state: EmailAgentState) -> dict:
    """
    In production: suspend here and wait for a real human API call.
    For this demo: auto-approve after the first retry to avoid an infinite loop.
    """
    if state["retry_count"] > 0:
        # Simulate approval after one retry
        return {"approved": True, "human_feedback": ""}
    # Simulate a rejection on first pass with feedback
    return {
        "approved": False,
        "human_feedback": "Please make the tone more concise.",
        "retry_count": 1,   # operator.add accumulates this
    }

def send_email_node(state: EmailAgentState) -> dict:
    """Send the approved draft — only reachable after human_approval_node approves."""
    print(f"\n✅ Email sent!\n\n{state['draft']}")
    return {}

# ── 3. Routing functions ─────────────────────────────────────────────────────
def route_after_approval(state: EmailAgentState) -> str:
    """Branch on approval flag — either send or loop back to drafting."""
    return "send_email_node" if state["approved"] else "draft_node"

# ── 4. Build the graph ───────────────────────────────────────────────────────
builder = StateGraph(EmailAgentState)

builder.add_node("research_node",       research_node)
builder.add_node("draft_node",          draft_node)
builder.add_node("human_approval_node", human_approval_node)
builder.add_node("send_email_node",     send_email_node)

builder.set_entry_point("research_node")
builder.add_edge("research_node",       "draft_node")
builder.add_edge("draft_node",          "human_approval_node")
builder.add_conditional_edges(
    "human_approval_node",
    route_after_approval,
    {"send_email_node": "send_email_node", "draft_node": "draft_node"},
)
builder.add_edge("send_email_node", END)

# ── 5. Compile with a checkpointer for crash recovery ───────────────────────
checkpointer = MemorySaver()
graph = builder.compile(checkpointer=checkpointer)

# ── 6. Run it ────────────────────────────────────────────────────────────────
config = {"configurable": {"thread_id": "email-run-001"}}
result = graph.invoke(
    {"topic": "climate change team update", "retry_count": 0,
     "research_results": "", "draft": "", "human_feedback": "", "approved": False},
    config=config,
)
```

**Observable outcome:** Adding an approval step means restructuring the entire calling code.

## Stage 4 — Real-World Applications: Where the Graph Model Earns Its Complexity

- The recipe-vs-flowchart analogy holds in practice.
- Consider three production patterns that LangGraph handles and AgentExecutor cannot: Document approval pipelines — A legal review agent drafts a clause, routes it through compliance review, routes approved clauses to the…
- route back for revision" decision is a conditional edge reading a review status field in state.
- Multi-source research with fallback — A researcher first queries an internal database node.

*Applies **database-indexing** to the decision above.*

**Observable outcome:** Multi-source research with fallback — A researcher first queries an internal database node.

## Stage 5 — LangGraph: The Open-Source Project and Its Architecture

- LangGraph is an open-source Python library from LangChain, Inc., released under the MIT license.
- Read them in order for the full progression, or jump directly to the capability you need.

*Applies **llm-agents-and-langgraph** to the decision above.*

**Observable outcome:** Read them in order for the full progression, or jump directly to the capability you need.

## End-to-end outcome

It queries a knowledge base, calls a few tools, and returns useful answers.

## Alternatives considered

### Visualizing the Contrast: Linear Loop vs. Branching Graph

The diagrams below show the same "research and draft an email" task implemented in each model.

### LangChain's core abstraction is the **Runnable** — a composable unit with `invoke`, `stream`, and `batch` methods. Chains are built by piping Runnables together: `prompt | llm | parser`. This is expressive and concise for sequential pipelines.

LangGraph's core abstraction is the StateGraph — a directed graph where nodes are Python functions and edges encode the routing logic.

### The Internals: Superstep Execution and State Merging

When you call StateGraph.compile() , LangGraph validates the graph (checks for disconnected nodes, unreachable END , missing entry points) and produces a Pregel-style executor.

### Performance Considerations: When Graph Overhead Is Worth It

LangGraph adds measurable overhead compared to a direct LCEL chain: For the typical agent (state = text + a few flags), serialization adds under a millisecond per superstep.

### Decision Guide: Which Tool for Which Task?

The trigger: the moment your agent needs to decide where to go next based on what it just learned , you have outgrown a pipeline and need a graph.


## Failure and degraded modes

### Trade-offs and Failure Modes: When LangGraph Adds Overhead and When It Doesn't

- **Detection:** A common misconception: "LangGraph replaces LangChain." It does not.
- **User or operator impact:** A common misconception: "LangGraph replaces LangChain." It does not.



## Scenario context

LangGraph adds state, branching, and loops to LLM chains — build stateful agents with graphs, nodes, and typed state.

---

You built a LangChain chain that answers questions. Then you tried to make it ask a follow-up. The chain had no idea what it just said.




This is the **stateless chain problem** — and it trips up almost every developer who moves beyond basic LangChain tutorials. Here is what the failure looks…

This walkthrough focuses on **The Stateless Chain Problem: Why Your Agent Forgets Everything**.

Before making a design choice, clarify:

- You built a LangChain chain that answers questions.
- Then you tried to make it ask a follow-up.
- The chain had no idea what it just said.

**Concepts in play:** llm-agents-and-langgraph, graph-traversal-algorithms, sorting-and-searching-algorithms, event-driven-architecture

## Stage 1 — LangGraph's Mental Model: Graphs, State, Nodes, and Edges

- Before writing any code, you need three clear ideas in your head.
- LangGraph is built from exactly these three concepts — nothing more.
- State is a Python dictionary typed with TypedDict .
- Every node in the graph can read it and write partial updates to it.

*Applies **llm-agents-and-langgraph** to the decision above.*

**Observable outcome:** Every node in the graph can read it and write partial updates to it.

## Stage 2 — Building Blocks: TypedDict State, Nodes, and How Edges Connect Them

- Let's make everything above concrete with runnable code.
- Here is the minimum viable LangGraph agent — a two-node graph that greets a user and then summarizes the greeting.
- Step 1 — Define your state schema with TypedDict The Annotated[list[str], operator.add] syntax is the first thing that surprises most developers.
- When a node returns {"messages": ["Hello!"]} , LangGraph does not replace the entire messages list — it appends to it.

*Applies **graph-traversal-algorithms** to the decision above.*

```python
from typing import Annotated
from typing_extensions import TypedDict
import operator

class AgentState(TypedDict):
    messages: Annotated[list[str], operator.add]
    # operator.add means "append new values; never overwrite the whole list"
```

```python
def greet_node(state: AgentState) -> dict:
    """Add a greeting to the message list."""
    return {"messages": ["Hi! How can I help you today?"]}

def summarize_node(state: AgentState) -> dict:
    """Summarize everything that has been said so far."""
    history = " | ".join(state["messages"])
    return {"messages": [f"[Summary]: {history}"]}
```

**Observable outcome:** When a node returns {"messages": ["Hello!"]} , LangGraph does not replace the entire messages list — it appends to it.

## Stage 3 — Deep Dive: How LangGraph Compiles and Executes Your Graph

- The Internals: Pregel-Style Execution Under the Hood When you call StateGraph.compile() , LangGraph validates the graph structure (checks for disconnected nodes, missing entry points, unreachable END ) and produces an e…
- At each superstep, LangGraph identifies the currently active nodes, runs them, collects their partial state updates, and merges those updates into the shared state dict before advancing to the next step.
- The merge strategy for each field is controlled by its annotated reducer — operator.add for append, or overwrite-by-default for unannotated fields.
- LangGraph also serializes the full state after each superstep.

*Applies **sorting-and-searching-algorithms** to the decision above.*

```python
from langgraph.checkpoint.memory import MemorySaver

checkpointer = MemorySaver()
graph = builder.compile(checkpointer=checkpointer)

# Each run gets a thread_id — state is persisted per thread
config = {"configurable": {"thread_id": "user-session-42"}}
result = graph.invoke({"messages": []}, config=config)
```

```python
for step in graph.stream({"messages": []}):
    node_name = list(step.keys())[0]
    print(f"✅ Node '{node_name}' completed: {step[node_name]}")
```

**Observable outcome:** LangGraph also serializes the full state after each superstep.

## Stage 4 — Your First Agent: A Research Assistant That Can Search

- Now let's build the worked example.
- The agent takes a user question, decides whether it needs to search the web before answering, runs a search if needed, and synthesizes the final response.
- Here is the graph structure: The router LLM inspects the question and sets a needs search flag.
- If true, the search node runs and injects results into state.

*Applies **event-driven-architecture** to the decision above.*

```mermaid
graph TD
    A([ User Question]) --> B[router_node Decide: search needed?]
    B -->|needs_search = true| C[search_node Fetch results]
    B -->|needs_search = false| D[answer_node Synthesize answer]
    C --> D
    D --> E([END])

    style A fill:#e3f2fd,stroke:#1976D2,color:#000
    style E fill:#e8f5e9,stroke:#388E3C,color:#000
    style B fill:#fff8e1,stroke:#F57F17,color:#000
    style C fill:#f3e5f5,stroke:#7B1FA2,color:#000
    style D fill:#e8f5e9,stroke:#2E7D32,color:#000
```

```python
import operator
from typing import Annotated
from typing_extensions import TypedDict
from langchain_openai import ChatOpenAI
from langchain_core.messages import HumanMessage, AIMessage, BaseMessage
from langgraph.graph import StateGraph, END

# --- 1. State schema ---
class ResearchState(TypedDict):
    messages: Annotated[list[BaseMessage], operator.add]
    search_results: str
    needs_search: bool

# --- 2. LLM (swap freely — see the LLM-agnostic section below) ---
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

# --- 3. Node: decide whether to search ---
def router_node(state: ResearchState) -> dict:
    question = state["messages"][-1].content
    prompt = (
        f"Does answering this question require current web information?\n"
        f"Question: {question}\n"
        f"Reply with only: YES or NO"
    )
    response = llm.invoke([HumanMessage(content=prompt)])
    return {"needs_search": "YES" in response.content.upper()}

# --- 4. Node: run the search ---
def search_node(state: ResearchState) -> dict:
    question = state["messages"][-1].content
    # Replace this stub with TavilySearch, Serper, or Bing API in production
    results = f"[Search stub] Top results for: '{question}' — relevant facts retrieved."
    return {"search_results": results}

# --- 5. Node: synthesize the answer ---
def answer_node(state: ResearchState) -> dict:
    context_messages = list(state["messages"])
    if state.get("search_results"):
        context_messages.append(
            HumanMessage(content=f"Use this context to answer: {state['search_results']}")
        )
    context_messages.append(HumanMessage(content="Now answer the original question."))
    response = llm.invoke(context_messages)
    return {"messages": [AIMessage(content=response.content)]}

# --- 6. Routing function ---
def route_search(state: ResearchState) -> str:
    return "search_node" if state.get("needs_search") else "answer_node"

# --- 7. Build and compile the graph ---
builder = StateGraph(ResearchState)

builder.add_node("router_node", router_node)
builder.add_node("search_node", search_node)
builder.add_node("answer_node", answer_node)

builder.set_entry_point("router_node")
builder.add_conditional_edges("router_node", route_search, {
    "search_node": "search_node",
    "answer_node": "answer_node",
})
builder.add_edge("search_node", "answer_node")
builder.add_edge("answer_node", END)

graph = builder.compile()

# --- 8. Run it ---
result = graph.invoke({
    "messages": [HumanMessage(content="What is the current price of Bitcoin?")],
    "search_results": "",
    "needs_search": False,
})
print(result["messages"][-1].content)
```

**Observable outcome:** If true, the search node runs and injects results into state.

## Stage 5 — Real-World Applications: Where Stateful Graphs Show Up in Production

- LangGraph is not a toy framework.
- Stateful graphs power several real production patterns: Customer support routing — A support bot classifies incoming messages: simple FAQs route directly to an answer node; complex issues enter a multi-turn diagnostic l…
- State tracks the conversation history, the issue category, and an escalation flag across every turn without external session storage.
- Code generation with self-repair — An agent generates code, runs a linter node, reads the linter output from state, and conditionally loops back to the LLM to fix errors.

*Applies **llm-agents-and-langgraph** to the decision above.*

**Observable outcome:** Code generation with self-repair — An agent generates code, runs a linter node, reads the linter output from state, and conditionally loops back to the LLM to fix errors.

## Stage 6 — Practical Example: Making the Graph LLM-Agnostic

- One of LangGraph's cleanest design decisions is that nodes are plain Python functions with no opinion about which LLM you use.
- Swapping providers requires changing exactly one line — the llm assignment at the top.
- This scenario was chosen because it is the most common "day 2" question new LangGraph users ask — and showing it is a one-liner is the best answer.
- As you read through the three provider options, watch how every other line (the research node , the StateGraph , the compile() call) stays identical across all three — that invariance is LangGraph's LLM-agnostic promise…

*Applies **graph-traversal-algorithms** to the decision above.*

```python
# Option 1: OpenAI — best default for production
from langchain_openai import ChatOpenAI
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

# Option 2: Anthropic Claude — great for long-context reasoning
from langchain_anthropic import ChatAnthropic
llm = ChatAnthropic(model="claude-3-haiku-20240307", temperature=0)

# Option 3: Ollama — fully local, zero API cost, great for development
from langchain_ollama import ChatOllama
llm = ChatOllama(model="llama3.2", temperature=0)

# The graph, nodes, state schema, and edges are IDENTICAL for all three.
```

```python
def make_router_node(llm):
    """Factory that binds a specific LLM into the router node."""
    def router_node(state: ResearchState) -> dict:
        question = state["messages"][-1].content
        prompt = f"Does answering this require web search?\nQuestion: {question}\nReply YES or NO"
        response = llm.invoke([HumanMessage(content=prompt)])
        return {"needs_search": "YES" in response.content.upper()}
    return router_node

# At graph build time, pick your LLM and inject it:
builder.add_node("router_node", make_router_node(llm))
```

**Observable outcome:** As you read through the three provider options, watch how every other line (the research node , the StateGraph , the compile() call) stays identical across all three — that invariance is LangGraph's LLM-agnostic promise…

## End-to-end outcome

After working through the stages, you should be able to explain:

- Building your first stateful agent surfaces several lessons that are not obvious from the documentation: 1.
- Compile once, invoke many times.

## Alternatives considered

### Decision Guide: StateGraph vs LCEL Chain vs LangChain AgentExecutor

The key signal is decision-making inside the loop .


## Failure and degraded modes

### Trade-offs and Failure Modes: When LangGraph Helps and When It Adds Complexity

- **Detection:** LangGraph solves real problems, but adding it to every project introduces overhead that is not always justified.
- **User or operator impact:** LangGraph solves real problems, but adding it to every project introduces overhead that is not always justified.



## Scenario context

ReAct = Think + Act + Observe, looped as a LangGraph graph — prebuilt or custom.

 B[" Agent Node (LLM call with bind_tools)"]
    B --> C{should_continue}
    C -- "tool_calls present in last AIMessage" --> D[" ToolNode (execute tool functions)"]
    D -- "append ToolMessages to state" --> B
    C -- "no tool_calls (final answer)" --> E([ END])

    style A fill:#4CAF50,color:#fff,stroke:none
    style E fill:#F44336,color:#fff,stroke:none
    style B fill:#2196F3,color:#fff,stroke:#1565C0
    style D fill:#FF9800,color:#fff,stroke:#E65100
    style C fill:#9C27B0,color:#fff,stroke:#6A1B9A
```

**Observable outcome:** What makes this a loop and not a chain is the back-edge from tools → agent .

## Stage 4 — Real-World Applications: Where ReAct Agents Are Deployed Today

- ReAct is not a research curiosity.
- It is the backbone of a wide class of production deployments: Coding assistants with test harnesses (GitHub Copilot Workspace, Devin-style agents): Write code → run linter → fix → run tests → fix → commit.
- The loop terminates when all checks pass or an iteration limit is reached.
- This is exactly the pattern this post's coding assistant example implements.

*Applies **event-driven-architecture** to the decision above.*

**Observable outcome:** This is exactly the pattern this post's coding assistant example implements.

## Stage 5 — Practical Example: Coding Assistant That Iterates Until Tests Pass

- This example implements the opening scenario end-to-end: a coding assistant that writes a Python function, runs the test suite, inspects failures, and iterates until all tests are green — or gives up after 8 attempts.
- The coding-assistant scenario was chosen because it is the clearest possible demonstration of the ReAct loop's core value: the agent cannot solve the task in one shot because it needs to observe real test output before…
- As you read through the execution trace, watch the should continue edge — every iteration where the result is "tools" is one full Think→Act→Observe cycle, and the loop only exits to END when the LLM decides there is not…
- What the loop looks like across 3+ turns: The agent used 5 turns, observed real test output, diagnosed a recursion failure, and applied a targeted fix — none of which is possible in a single shot.

*Applies **llm-agents-and-langgraph** to the decision above.*

```python
import os
import subprocess
from typing import Annotated
from typing_extensions import TypedDict

from langchain_core.messages import SystemMessage, AIMessage
from langchain_core.tools import tool
from langchain_openai import ChatOpenAI
from langgraph.graph import StateGraph, END
from langgraph.graph.message import add_messages
from langgraph.prebuilt import ToolNode

# ── State ──────────────────────────────────────────────────────────────────
class CodingAgentState(TypedDict):
    messages: Annotated[list, add_messages]
    iterations: int

# ── Tools ──────────────────────────────────────────────────────────────────
@tool
def write_python_file(filename: str, code: str) -> str:
    """Write Python source code to a file. Returns confirmation."""
    with open(filename, "w") as f:
        f.write(code)
    return f"Written {len(code)} chars to '{filename}'."

@tool
def run_pytest(test_file: str) -> str:
    """Run pytest on the given test file. Returns stdout + stderr."""
    result = subprocess.run(
        ["pytest", test_file, "-v", "--tb=short", "--no-header"],
        capture_output=True, text=True, timeout=30
    )
    output = result.stdout + result.stderr
    return output[:4000]  # Guard against extremely verbose output

tools = [write_python_file, run_pytest]

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

SYSTEM = SystemMessage(content="""You are an expert Python engineer.
When given a coding task:
1. Write the implementation file using write_python_file.
2. Run the test file using run_pytest.
3. If any tests fail, read the error output carefully, fix the code, and run tests again.
4. Repeat until ALL tests pass, then report "All tests pass." as your final answer.
Do not stop until tests pass or you are truly stuck.""")

MAX_ITERATIONS = 8

def agent_node(state: CodingAgentState):
    if state.get("iterations", 0) >= MAX_ITERATIONS:
        return {
            "messages": [AIMessage(content=f"Stopped after {MAX_ITERATIONS} iterations.")],
            "iterations": state.get("iterations", 0),
        }
    messages = [SYSTEM] + state["messages"]
    response = llm_with_tools.invoke(messages)
    return {
        "messages": [response],
        "iterations": state.get("iterations", 0) + 1,
    }

def should_continue(state: CodingAgentState) -> str:
    last = state["messages"][-1]
    if state.get("iterations", 0) >= MAX_ITERATIONS:
        return END
    if hasattr(last, "tool_calls") and last.tool_calls:
        return "tools"
    return END

tool_node = ToolNode(tools, handle_tool_errors=True)

# ── Graph ──────────────────────────────────────────────────────────────────
workflow = StateGraph(CodingAgentState)
workflow.add_node("agent", agent_node)
workflow.add_node("tools", tool_node)
workflow.set_entry_point("agent")
workflow.add_conditional_edges("agent", should_continue)
workflow.add_edge("tools", "agent")

coding_agent = workflow.compile()

# ── Run ────────────────────────────────────────────────────────────────────
if __name__ == "__main__":
    result = coding_agent.invoke({
        "messages": [(
            "user",
            "Implement a fibonacci function in fib.py. "
            "Tests are in test_fib.py. Make all tests pass."
        )],
        "iterations": 0,
    })

    for msg in result["messages"]:
        role = type(msg).__name__
        content = getattr(msg, "content", "") or ""
        if content:
            print(f"[{role}] {content[:200]}")
    print(f"\nCompleted in {result['iterations']} iteration(s).")
```

```
[Turn 1] Agent thinks: "I'll write the fibonacci implementation first."
         Calls: write_python_file("fib.py", "def fib(n):\n    if n <= 1: return n\n    ...")
[Tool]   "Written 89 chars to 'fib.py'."

[Turn 2] Agent thinks: "Now run the tests."
         Calls: run_pytest("test_fib.py")
[Tool]   "FAILED test_fib.py::test_large_input - RecursionError: maximum recursion depth exceeded"

[Turn 3] Agent thinks: "I need an iterative implementation for large inputs."
         Calls: write_python_file("fib.py", "def fib(n):\n    a, b = 0, 1\n    for _ in range(n): a, b = b, a+b\n    return a")
[Tool]   "Written 74 chars to 'fib.py'."

[Turn 4] Agent thinks: "Retry the tests."
         Calls: run_pytest("test_fib.py")
[Tool]   "PASSED: 5 tests in 0.04s"

[Turn 5] Agent produces final answer: "All tests pass. The fibonacci function uses an iterative
         approach and handles inputs up to fib(1000) without recursion errors."
```

**Observable outcome:** What the loop looks like across 3+ turns: The agent used 5 turns, observed real test output, diagnosed a recursion failure, and applied a targeted fix — none of which is possible in a single shot.

## Stage 6 — LangGraph Prebuilt Agents: create_react_agent, create_tool_calling_executor

- LangGraph ships two prebuilt agent constructors.
- Understanding both helps you choose the right level of abstraction.
- create react agent (current standard) create react agent is LLM-agnostic : any model that supports tool calling via .bind tools() works identically.
- This includes ChatOpenAI , ChatAnthropic , ChatOllama , and ChatGroq .

*Applies **graph-traversal-algorithms** to the decision above.*

```python
from langgraph.prebuilt import create_react_agent
from langchain_anthropic import ChatAnthropic  # swap provider freely

# Works identically with ChatOpenAI, ChatAnthropic, ChatOllama, ChatGroq
agent = create_react_agent(
    model=ChatAnthropic(model="claude-3-5-sonnet-20241022"),
    tools=tools,
    # System prompt injected before messages on every call, not stored in state
    state_modifier=SYSTEM,
)
```

```python
from IPython.display import Image
Image(agent.get_graph().draw_mermaid_png())
```

**Observable outcome:** This includes ChatOpenAI , ChatAnthropic , ChatOllama , and ChatGroq .

## End-to-end outcome

After working through the stages, you should be able to explain:

- The system prompt does not belong in state.
- A common mistake is appending the system prompt as the first message in MessagesState .

## Alternatives considered

### LangGraph gives you two paths to a working ReAct agent. The right choice depends on how much you need to customize the loop.

LangGraph gives you two paths to a working ReAct agent.

### Path 1: The Prebuilt Shortcut with `create_react_agent`

create react agent handles everything: it binds your tools to the LLM, creates the agent node, creates the ToolNode , wires the conditional edge, and compiles the graph.

### Path 2: Building the Loop Manually as a StateGraph

The key difference from create react agent is the should continue function — you own it.

### Decision Guide: create_react_agent vs Custom Loop vs Plan-and-Execute

Decision Guide: create_react_agent vs Custom Loop vs Plan-and-Execute


## Failure and degraded modes

### The Single-Shot Failure: Why One LLM Call Isn't Enough for Complex Tasks

- **Detection:** Your agent is supposed to write a function, run the tests, fix the failures, and repeat until green.
- **User or operator impact:** Your agent is supposed to write a function, run the tests, fix the failures, and repeat until green.

### Performance vs. Cost

- **Detection:** ReAct loops are significantly more expensive than single-shot calls.
- **User or operator impact:** ReAct loops are significantly more expensive than single-shot calls.

### Infinite Loop Failure Mode

- **Detection:** The most dangerous failure mode is an agent that loops without making progress.
- **User or operator impact:** The most dangerous failure mode is an agent that loops without making progress.

### Hallucinated Tool Calls

- **Detection:** The LLM may emit a tool call that references a function that does not exist in your tools list, or passes arguments with the wrong type.
- **User or operator impact:** The LLM may emit a tool call that references a function that does not exist in your tools list, or passes arguments with the wrong type.

### Token Explosion in Long Conversations

- **Detection:** Deep loops on complex tasks can exhaust the context window.
- **User or operator impact:** Deep loops on complex tasks can exhaust the context window.

## Scenario context

Wire @tool, ToolNode, and bind_tools into LangGraph for agents that call APIs at runtime.

Your agent confidently tells you the current stock price of NVIDIA. It's from its training data — six months out of date. The model doesn't know what it doesn't know. It has no concept of "today." Every fact it gives you was frozen at training cutoff, and it will recite that frozen snapshot with the same unwavering confidence…

This walkthrough focuses on **The Stale Knowledge Problem: Why LLMs Need Runtime Tools**.

Before making a design choice, clarify:

- Your agent confidently tells you the current stock price of NVIDIA.
- It's from its training data — six months out of date.
- The model doesn't know what it doesn't know.

**Concepts in play:** llm-agents-and-langgraph, graph-traversal-algorithms, low-level-design-systems, sorting-and-searching-algorithms

## Stage 1 — Tool Fundamentals: @tool, Schemas, and the bind_tools() Pattern

- Before wiring tools into a graph, you need to understand what a "tool" is from LangGraph's perspective: a Python callable decorated with @tool that carries enough metadata for an LLM to decide when and how to call it.
- Defining a Tool with @tool The @tool decorator from langchain core.tools does three things.
- It wraps your function, uses the docstring as the tool description (what the model reads to decide whether to call it), and derives the JSON schema for the function's arguments from Python type hints.
- The docstring is not decoration — it's the model's only window into what this tool does.

*Applies **llm-agents-and-langgraph** to the decision above.*

```python
from langchain_core.tools import tool

@tool
def get_stock_price(ticker: str) -> str:
    """
    Fetch the current stock price for a given ticker symbol.
    Returns a formatted string with the latest price.
    """
    # In production, call a real market data API here
    prices = {"NVDA": "118.42", "AAPL": "213.07", "TSLA": "172.30"}
    price = prices.get(ticker.upper(), "unknown")
    return f"{ticker.upper()} is currently trading at ${price}"
```

```python
from pydantic import BaseModel, Field
from langchain_core.tools import tool

class WebSearchInput(BaseModel):
    query: str = Field(description="The search query string")
    max_results: int = Field(default=5, description="Maximum number of results to return")

@tool("web_search", args_schema=WebSearchInput)
def web_search(query: str, max_results: int = 5) -> str:
    """Search the web for current information on a topic."""
    # In production: call Tavily, SerpAPI, or Brave Search here
    return f"Top {max_results} results for '{query}': [result1, result2, ...]"
```

**Observable outcome:** The docstring is not decoration — it's the model's only window into what this tool does.

## Stage 2 — Wiring Tools into LangGraph: ToolNode, Conditional Routing, and the Tool Loop

- With tools defined and bound to the LLM, the next step is wiring them into the graph.
- This requires three components: a state , an agent node , a ToolNode , and conditional routing between them.
- State and the Agent Node The graph state holds the conversation as a list of messages.
- The agent node calls the LLM with the current state and appends the model's response.

*Applies **graph-traversal-algorithms** to the decision above.*

```python
from typing import Annotated
from typing_extensions import TypedDict
from langgraph.graph import StateGraph, END
from langgraph.graph.message import add_messages
from langgraph.prebuilt import ToolNode, tools_condition

class AgentState(TypedDict):
    messages: Annotated[list, add_messages]

def agent_node(state: AgentState):
    """Call the LLM with the current message history."""
    response = llm_openai.invoke(state["messages"])
    return {"messages": [response]}
```

```python
tool_node = ToolNode(tools)  # Pass the same list you used in bind_tools()
```

**Observable outcome:** The agent node calls the LLM with the current state and appends the model's response.

## Stage 3 — Deep Dive: How LangGraph Executes Tool Calls

- The Internals When the LLM with bound tools generates a response that includes tool calls, it returns an AIMessage with a tool calls field.
- Each entry in this list is a dict with three keys: id (a unique call identifier), name (the tool function name), and args (a dict of parsed arguments).
- ToolNode iterates this list and dispatches each call to the matching function by name.
- It uses the tool registry it was initialized with — the same tools list passed to ToolNode(tools) .

*Applies **low-level-design-systems** to the decision above.*

```python
# Example AIMessage.tool_calls structure:
[
    {
        "id": "call_abc123",
        "name": "get_stock_price",
        "args": {"ticker": "NVDA"}
    },
    {
        "id": "call_def456",
        "name": "web_search",
        "args": {"query": "NVIDIA Q4 2025 earnings", "max_results": 3}
    }
]
```

**Observable outcome:** It uses the tool registry it was initialized with — the same tools list passed to ToolNode(tools) .

## Stage 4 — The Tool Calling Loop: Graph Diagram

- The core pattern is a tight loop between an agent node and a tool executor, gated by a conditional router: The agent loop: the LLM reasons → calls tools if needed → receives results → reasons again.
- The cycle exits when the model produces a direct answer.
- Every iteration of the loop passes the full message history to the LLM, so the model always has context on what tools it called and what results they returned.
- This is how multi-step reasoning works: the agent sees its own prior actions and builds on them.

*Applies **sorting-and-searching-algorithms** to the decision above.*

```mermaid
flowchart TD
    A([User Input]) --> B[Agent Node LLM + bind_tools]
    B --> C{tools_condition}
    C -- has tool_calls --> D[ToolNode Execute tools]
    C -- no tool_calls --> E([Final Response])
    D --> B
    style A fill:#e8f4f8,stroke:#2196f3
    style E fill:#e8f5e9,stroke:#4caf50
    style C fill:#fff3e0,stroke:#ff9800
    style D fill:#fce4ec,stroke:#e91e63
```

**Observable outcome:** This is how multi-step reasoning works: the agent sees its own prior actions and builds on them.

## Stage 5 — Real-World Applications: How Production Agents Use Tool Calling

- Financial Research Assistants A hedge fund assistant needs to answer: "Should we increase our NVIDIA position given today's macro environment?" A bare LLM would hallucinate a confident answer based on stale training dat…
- With tools, the agent calls get stock price , get earnings data , and web search in parallel, receives live data, then synthesizes a grounded analysis.
- Input: "Evaluate NVIDIA given today's market." Process: Parallel tool calls → stock price + recent news + analyst ratings fetched live Output: Structured memo citing today's actual data, not training-cutoff prices.
- Customer Support Bots with CRM Access A support agent needs to check an order's shipping status.

*Applies **llm-agents-and-langgraph** to the decision above.*

**Observable outcome:** Customer Support Bots with CRM Access A support agent needs to check an order's shipping status.

## Stage 6 — Practical Example: Market Research Agent with Parallel Tool Calls

- This example demonstrates the full tool-calling loop: tool definition, LLM binding, ToolNode wiring, and parallel execution in a single runnable agent.
- The market research scenario was chosen because it requires live data from multiple independent sources simultaneously — exactly the case where LangGraph's parallel ToolNode execution pays off over a sequential loop.
- As you read through the code, watch for step 2 in the execution trace: the LLM emits two tool calls in a single AIMessage , which ToolNode executes concurrently — that is the parallel tool calling pattern in action.
- Here is the complete market research agent with three tools — web search , get stock price , and summarize findings — with parallel execution and graceful error handling.

*Applies **graph-traversal-algorithms** to the decision above.*

```python
from typing import Annotated
from typing_extensions import TypedDict
from langchain_core.tools import tool
from langchain_core.messages import HumanMessage
from langchain_openai import ChatOpenAI
from langgraph.graph import StateGraph, END
from langgraph.graph.message import add_messages
from langgraph.prebuilt import ToolNode, tools_condition

# ── Tool definitions ────────────────────────────────────────────────
@tool
def web_search(query: str) -> str:
    """Search the web for recent news and analysis on a topic."""
    # Replace with Tavily or SerpAPI in production
    return f"[Search results for '{query}']: Market analysts expect strong Q1. Supply constraints easing."

@tool
def get_stock_price(ticker: str) -> str:
    """Get the current stock price for a publicly traded company by ticker symbol."""
    mock_prices = {"NVDA": "118.42", "AAPL": "213.07", "MSFT": "415.30"}
    price = mock_prices.get(ticker.upper(), "Price unavailable")
    return f"{ticker.upper()}: ${price}"

@tool
def summarize_findings(raw_data: str) -> str:
    """Condense multiple data points into a brief investment summary."""
    return f"Summary: Based on provided data — {raw_data[:80]}... — outlook is cautiously positive."

tools = [web_search, get_stock_price, summarize_findings]

# ── LLM with bound tools ─────────────────────────────────────────────
llm = ChatOpenAI(model="gpt-4o", temperature=0).bind_tools(tools)

# ── State ─────────────────────────────────────────────────────────────
class ResearchState(TypedDict):
    messages: Annotated[list, add_messages]

# ── Agent node ────────────────────────────────────────────────────────
def agent_node(state: ResearchState):
    response = llm.invoke(state["messages"])
    return {"messages": [response]}

# ── Graph assembly ────────────────────────────────────────────────────
tool_node = ToolNode(tools)

builder = StateGraph(ResearchState)
builder.add_node("agent", agent_node)
builder.add_node("tools", tool_node)
builder.set_entry_point("agent")
builder.add_conditional_edges("agent", tools_condition)
builder.add_edge("tools", "agent")
graph = builder.compile()

# ── Run ───────────────────────────────────────────────────────────────
result = graph.invoke(
    {"messages": [HumanMessage(
        content="Research NVIDIA (NVDA): get the current price and recent news. Then summarize."
    )]},
    config={"recursion_limit": 10}
)

for msg in result["messages"]:
    print(f"[{msg.__class__.__name__}] {msg.content[:120]}")
```

**Observable outcome:** Here is the complete market research agent with three tools — web search , get stock price , and summarize findings — with parallel execution and graceful error handling.

## End-to-end outcome

After working through the stages, you should be able to explain:

- Docstrings are the model's tool selection logic.
- A vague docstring like "Get price" will lead the model to call the wrong tool or skip it entirely.

## Alternatives considered

### Decision Guide: ToolNode vs Custom Tool Execution vs LangChain AgentExecutor

Decision Guide: ToolNode vs Custom Tool Execution vs LangChain AgentExecutor


## Failure and degraded modes

### Hallucinated Tool Calls

- **Detection:** LLMs occasionally invent tool call arguments that violate the schema, or call a tool with plausible-sounding but wrong input (e.g., passing "NVIDIA" instead of "NVDA" to a ticker lookup).
- **User or operator impact:** LLMs occasionally invent tool call arguments that violate the schema, or call a tool with plausible-sounding but wrong input (e.g., passing "NVIDIA" instead of "NVDA" to a ticker lookup).

### API Failures and Transient Errors

- **Detection:** If get stock price raises an exception, the default ToolNode wraps it in an error message and feeds it back to the agent.
- **User or operator impact:** If get stock price raises an exception, the default ToolNode wraps it in an error message and feeds it back to the agent.

### Infinite Tool Loops

- **Detection:** An agent can get stuck in a loop: call tool → get result → call tool again in the next step indefinitely.
- **User or operator impact:** An agent can get stuck in a loop: call tool → get result → call tool again in the next step indefinitely.

### Latency Creep at Scale

- **Detection:** Every tool call adds a network round trip.
- **User or operator impact:** Every tool call adds a network round trip.



Step 1

Build stateful multi-agent systems and custom tool nodes using LangGraph.

Stateful Graph Agents