🎧 Prefer to listen?

Ask three people what “graphs” means in AI and you’ll get three answers — a chart, a database, or something about LangGraph that sounds like homework. None of those is what the AI world actually means. A graph in AI is a map of your workflow: boxes for steps, arrows for the paths between them, and a shared memory that travels along the arrows.

Last week’s post traced the evolution — from prompting to graphs — and ended with a promise: part two would explain what a graph actually is, without the computer science degree. This is that post. And the reason it matters comes from a trap we covered in the AI groupthink problem: everyone says “graphs” right now, but almost nobody explains the idea before naming the framework. Let’s fix the order.

First, forget the word “graph”

The word is unfortunate. It makes people picture Excel charts or Neo4j. What AI builders mean is closer to a subway map: stations (steps your workflow passes through), lines (the possible routes between them), and junctions where the route depends on something you learn along the way.

Engineers call the stations nodes and the lines edges. Those are the only two pieces of vocabulary you genuinely need. Everything else is detail about how the train moves.

The four ingredients, in plain English

1. Nodes — one job per box

Each node does exactly one thing: summarize this email, check the calendar, draft a reply, ask the human a question. That’s it. The discipline of graphs is mostly the discipline of keeping each box small enough to test. If you can’t describe what a node does in one sentence, it’s two nodes.

2. Edges — the routes between boxes

An edge is just “after this step, go there.” Some edges are unconditional (always go to the summarizer next). Some are conditional (if the email is urgent, go left; otherwise right). Here’s the part beginners miss: you draw the edges. The AI doesn’t invent the map — it travels the map you drew, making judgment calls only at the junctions you marked.

3. State — the shared memory

This is the ingredient that makes graphs genuinely different from chained prompts. State is a single object — think of it as a clipboard every station can read from and write to. The summary node writes “email summary: X” onto the clipboard. The drafting node reads it, adds “draft: Y.” By the end of the run, the clipboard holds the full history of what happened, in order.

Why does that matter? Because in a chain of separate prompts, step four has no reliable memory of step two unless you engineer it. With shared state, every node sees everything that came before it. Crashes stop being fatal too — the clipboard persists, so the workflow can resume where it stopped instead of starting over.

4. Branching — where decisions live

Branches are conditional edges: the junctions where the route depends on what the work revealed. “Is the draft good? Yes → send. No → redraft.” The difference from an agent loop is subtle but decisive: in a loop, the AI decides what to do next, every step, forever. In a graph, the AI makes judgments at junctions you designed — and the rest of the map is deterministic plumbing. Freedom where you want it, structure where you need it.

5. Human-in-the-loop — the pause button

Serious graph frameworks add one more thing: a node type that stops and waits for a person. “Here’s the draft — approve before sending?” The workflow freezes mid-map, holds its clipboard, and resumes when you say go. If you’ve ever wanted an automation that could do 95% of the work but not send money or emails without you, that’s this feature. It’s why the labs’ own eval infrastructure now builds human checkpoints in by default.

How this differs from a chat thread

A chat thread is a conversation: one context, one timeline, everything accumulates, and the model decides what’s relevant each turn. That’s perfect for thinking and terrible for reliability — context grows until the model starts losing the middle, and nothing about the sequence is enforced.

A graph is a process: discrete steps, a controlled clipboard, enforced routes. You wouldn’t run your invoicing as a chat thread. The mental shift is from “talk to it until it’s done” to “draw the pipeline, put judgment where it belongs.”

If you use n8n, Make, or Zapier’s visual editor, none of this is abstract — branching paths, shared data between nodes, conditional routes are graph orchestration with friendlier paint. Code-level graphs (LangGraph is the name people hear most) add the pieces visual builders can’t: state that survives crashes, human approval pauses, and loops that live inside the structure rather than being the whole structure. Our earlier breakdown of one model orchestrating others is the same idea at team scale.

When you actually need one

The honest heuristic from part one still holds, sharpened:

  • One question, one answer → a prompt. Don’t draw a map for a lemonade stand.
  • A fixed sequence of steps → a chain in Zapier or Make.
  • Judgment + tools, short task → an agent loop. (How to pick a framework.)
  • Multi-step work where a wrong branch is expensive → a graph.

You also don’t need to start from zero. Our guide to building your first automation in 15 minutes is the on-ramp — most people’s first graph is a two-node branch they built without knowing the vocabulary.

The bottom line

A graph isn’t magic — it’s a subway map for AI work: small boxes with one job each, routes you drew, a clipboard that remembers everything, junctions where the model judges, and pause buttons where a human should. LangGraph is just one company’s implementation of that idea. The idea is the durable part.

Next in the series: graphs vs. plain agent loops — when the map genuinely beats the wandering, and when it’s overkill. If you want the practical foundation underneath all of this, /start-here/ routes you to the workflows worth building first.