Quick answer: LangGraph is an open-source framework from the LangChain team for building agents as graphs. You define nodes (steps, usually a model or tool call), edges (what runs next), and a shared state object that flows through the graph. Because you control the edges, you can build loops, branches, retries, and human-approval steps that a flat "one shot" agent call cannot express cleanly.
If you have built an agent by calling a model in a while loop and thought "this is getting hard to reason about," LangGraph is the answer to that feeling. It gives structure to control flow without hiding it from you.
Why a graph?
Most simple agents are a loop: ask the model, run the tool it wants, feed the result back, repeat. That works until the logic gets real. What if step three fails and you want to retry twice, then fall back? What if a human needs to approve before the agent spends money? What if two paths should run and then merge?
You can cram all of that into one loop with a pile of if-statements, but it becomes hard to read and harder to change. A graph makes the control flow explicit. Each decision is an edge, each unit of work is a node, and you can look at the graph and understand exactly what happens when.
The core concepts
LangGraph has three ideas you need. Everything else builds on them.
| Concept | What it is | Analogy |
|---|---|---|
| State | A shared object passed through the whole graph | The document every step reads and edits |
| Node | A function that reads state and returns an update | A step in a workflow |
| Edge | The rule for which node runs next | The arrow between boxes on a flowchart |
State is the memory of the run. It is typically a typed object (in Python, often a TypedDict) holding things like the message history, intermediate results, and any flags your logic checks. Nodes read from it and return partial updates that get merged back in.
Nodes are where work happens. A node might call the model, call a tool, transform data, or make a decision. A node takes the current state and returns a change to it.
Edges connect nodes. A normal edge always goes from A to B. A conditional edge looks at the state and picks the next node, which is how you get branching and loops. An edge that points back to an earlier node is a cycle, and cycles are exactly what let an agent keep working until it is done.
A minimal example, conceptually
Here is the shape of a tiny LangGraph agent in pseudocode. The real API has specific class and method names that evolve between versions, so treat this as the idea, not a copy-paste snippet, and check the current LangGraph docs for exact signatures.
# Conceptual shape, not exact API. Check the LangGraph docs.
# 1. Define the shared state
class State(TypedDict):
messages: list
done: bool
# 2. Define nodes: each takes state, returns an update
def call_model(state):
reply = model.invoke(state["messages"])
return {"messages": state["messages"] + [reply]}
def run_tool(state):
result = do_tool_call(state["messages"][-1])
return {"messages": state["messages"] + [result]}
# 3. Build the graph: nodes + edges
graph.add_node("model", call_model)
graph.add_node("tool", run_tool)
# 4. Conditional edge: after the model, tool or finish?
graph.add_conditional_edges(
"model",
lambda state: "tool" if needs_tool(state) else END,
)
graph.add_edge("tool", "model") # loop back after the tool
app = graph.compile()
Read the edges out loud: after the model runs, if it asked for a tool, go to the tool node, otherwise end. After the tool runs, go back to the model. That loop is the whole agent, and you can see it in four lines.
When LangGraph fits, and when it does not
LangGraph is worth the extra scaffolding when control flow is the hard part of your problem.
Good fits:
- Multi-step workflows where later steps depend on earlier decisions.
- Anything with a human-in-the-loop approval or edit.
- Retries, fallbacks, and error branches you want to see explicitly.
- Long-running or resumable agents where you persist state between steps.
Probably overkill:
- A single question-and-answer call with one tool. A plain loop is fine, and our what is an AI agent post shows how little you actually need for the simple case.
- A quick prototype where you are still figuring out the task.
If you are weighing LangGraph against CrewAI, AutoGen, Mastra, or a DIY loop, we compared them side by side in the best AI agent frameworks roundup.
Giving a node web access
A LangGraph agent is only as useful as the tools its nodes can call, and the most common gap is live web data. The model's training data is frozen and incomplete, so any question about current facts, recent docs, or a specific page needs a fetch or a search.
The clean way to add that is a node that calls a web API and writes the result into state. Fetch turns any URL into readable markdown:
curl https://link.sc/v1/fetch \
-H "Authorization: Bearer lsc_..." \
-d url="https://example.com/changelog" \
-d format="markdown"
And search returns full page content for open-ended questions, so the next model node has real text to reason over instead of snippets:
curl https://link.sc/v1/search \
-H "Authorization: Bearer lsc_..." \
-d query="python 3.14 release notes"
In graph terms, you add a fetch or search node, point an edge to it whenever the model asks for the web, and edge back to the model with the results merged into state. You avoid running headless browsers and proxies yourself; the API handles rendering, blocking, and parsing. The link.sc docs have ready-to-use tool definitions, and there is an MCP server at mcp.link.sc if you prefer that route.
The takeaway
LangGraph is a way to draw your agent as a flowchart and then run it. Nodes do work, edges decide what happens next, and state carries the run. That structure pays off exactly when the logic is complex enough that a plain loop turns into spaghetti.
Start simple. If your control flow is trivial, you may not need a graph at all. When it stops being trivial, LangGraph is a clean place to land, and giving its nodes a real web tool is what turns a well-structured agent into a useful one.
Building a LangGraph agent that needs live web data? Add a fetch and search node with link.sc and skip the browser plumbing.