Part 5: LangGraph in 10 Minutes: How State Graphs Make Agents Smarter

Part 5 in the series : if you’re new, start with Part 4: From RAG to Agents

Photo by Thomas Couillard on Unsplash

In the last post, we said an AI agent is a system that can decide what to do next and then go do it.

Simple enough in theory. But here’s the real question: how does it keep track of where it is?

If you ask an agent to book a meeting, check the weather, summarise three emails, and then draft a reply, how does it remember what it’s already done? How does it know what comes next? What happens if one step fails?

Without a structure to hold all of that, an agent is just guessing.

That structure is what LangGraph provides.

LangGraph gives your agent a map, so it always knows where it’s been, where it is & where it’s going next.

The problem with “just calling an LLM”

Imagine you are directing a play. You could walk up to each actor before every scene & whisper what to do next. That works for two scenes. For twenty? You will lose track. Actors will repeat scenes. Some will skip ahead. The play falls apart.

That is what happens when you build an agent by just chaining LLM calls together without any structure. Each call forgets the one before. There is no memory of what happened. No way to loop back if something went wrong.

LangGraph solves this by giving you three things: nodes, edges & state.

The three ideas that make LangGraph click

1. State : the agent’s memory of what’s happening

State is a snapshot of everything the agent knows right now.

Think of it as a sticky note the agent carries through every step. It holds things like:

• What was the original question?
• What emails did I already read?
• What did the user last say?
• Have I already sent that reply?

Every time the agent does something, it updates the sticky note. The next step reads from it. Nothing gets forgotten between steps.

In code terms, state is usually just a Python dictionary or a typed object. Nothing fancy.

state = {
    "user_question": "What did my landlord say about rent?",
    "emails_found": [],
    "draft_reply": None,
    "task_complete": False
}

Every node reads from this. Every node writes to this.

2. Nodes : the steps your agent takes

A node is one unit of work.

It could be:

• Searching your emails
• Summarising a document
• Calling an external API
• Asking the user a clarifying question
• Deciding which tool to use next

Each node is a function. It takes the current state, does its job, and returns an updated state.

def search_emails(state):
    results = vector_db.search(state["user_question"])
    state["emails_found"] = results
    return state

That’s it. One job. One node.

3. Edges : the decisions between steps

Edges connect nodes. They answer the question: “After this step, what happens next?”

Some edges are fixed: After “search emails” → always go to “summarise emails”

Some edges are conditional: After “check calendar” → if slot found, go to “draft reply” / if no slot, go to “ask user”

That conditional branching is where agents get smart. The agent isn’t just running a script from top to bottom. It’s making real decisions based on what it found.

def should_draft_or_ask(state):
    if state["emails_found"]:
        return "draft_reply"
    else:
        return "ask_user_for_more_info"

Put it together: the Gmail agent in LangGraph

Let us map our Gmail example onto this.

[START]
    ↓
[search_emails]        ← node: searches your inbox by meaning
    ↓
[summarise_results]    ← node: reads what was found, creates a summary
    ↓
[decide_next_step]     ← conditional edge: reply needed? or just answer?
    ↓              ↓
[draft_reply]    [return_answer]
    ↓
[ask_user_to_confirm]  ← node: "Want me to send this?"
    ↓
[END]

Every box is a node. Every arrow is an edge. The whole thing is the graph. And running through every box, updated at each step, is the state. This is LangGraph.

Why does this matter for agents?

Without LangGraph (or something like it) agents tend to:

• Repeat the same step over and over
• Forget what they already did
• Get stuck in infinite loops
• Have no way to recover from a bad result

With LangGraph:

Problem How LangGraph handles it Agent forgets what it did State carries the full history agent loops forever you define clear end conditions one step fails conditional edges route to a fallback agent needs to ask the user A node pauses & waits for input

That last one is called human-in-the-loop, we will look at it properly in a future post. It is one of LangGraph’s most powerful features.

The mental model to keep

A LangGraph agent is like a flowchart that thinks. A regular flowchart is fixed. Same path every time. A LangGraph agent reads what happened, decides which path makes sense & takes it. The graph is the plan. The state is the memory. The nodes are the actions.

Together, they let an agent handle tasks that are not perfectly predictable, which is most of the real world.

What’s coming next

Now that you know how an agent stays oriented using LangGraph, the next question is: what tools does it actually use to do things?

Next post: Google’s Agent Development Kit (ADK) what it gives you out of the box & why it matters.

Previously in this series:

Part 1: How AI “Gets” What You Mean | Part 2: Where Do All Those “Meanings” Live? (Vector DB) | Part 3: Chatting With Your Gmail: How RAG Puts It All Together | Part 4: From RAG to Agents : when AI stops just answering and starts doing