Say your support team handles 400 tickets a day. Two people read each one, pick a category, paste in a reply from a shared doc, and escalate the messy ones. You want an agent to do that first pass: read the ticket, tag it, draft a response, and push anything ambiguous to a human.
The obvious approach is a prompt chain. Run the text through three or four LLM calls and call it done. That survives until someone asks for a retry when the model returns garbage, or wants the agent to remember that the same customer wrote in yesterday, or wants a manager to approve refund drafts before they go out. Prompt chains model none of that well.
LangGraph does, because it treats the workflow as a graph instead of a prompt. Nodes do the work. Edges decide what runs next. A shared state object travels through every step, and the runtime can pause the graph, save it, and resume it hours later in a different process. What follows is a build of a ticket triage agent starting from an empty file.
Sketch the graph before you write any code
Four pieces of work happen, and each one becomes a node:
- Classify reads the ticket and returns a category plus a confidence score.
- Draft writes a reply from the ticket text and a matched help-center article.
- Escalate packages the ticket for a human when confidence is low or the topic is billing.
- Review checks the draft against a short policy list before it goes anywhere.
The edges matter more than the nodes. Classify always runs first. A conditional edge then sends the ticket to draft or escalate. Draft flows into review, and review either approves the reply or loops back to draft one more time. That loop is the part a chain cannot express cleanly, and it is the reason the graph is worth drawing on a napkin before you open an editor.
Step 1: Define the state your nodes share
Everything in LangGraph hangs off the state object. In Python that is usually a TypedDict, and every node receives the whole state and returns a partial update with only the keys it changed.
For triage you want something like: a messages list, a category string, a confidence float, a draft string, an attempts integer, and an approved boolean. Two details bite people early. Fields that accumulate, like the message history, need a reducer so repeated writes do not clobber each other, and the built-in add_messages helper covers that case. Keep the rest flat. Nested dicts look tidy in a diagram and become miserable to debug at 2 a.m. when the wrong key is empty.
Step 2: Write nodes that fail loudly
A node is a plain function. It takes state, does one job, and returns a dict of the keys it touched. No framework magic, which is exactly why the graph stays readable as it grows.
The classifier node
Call the model with a structured output schema: category is one of five strings, confidence is a number between 0 and 1. Validate before the value reaches state, because a classifier that silently returns “bdilling” with a confidence of 3 is worse than one that raises an exception. Tooling such as PydanticAI puts that schema at the center of the design if you want the validation to be more than an afterthought.
The drafting node
Look up the top help-center article for the category, drop the first 800 characters into the prompt, and generate two or three sentences. Increment the attempt counter in state so the review loop has a natural stopping point instead of running forever.
The escalation node
No model call at all. Write the ticket to your human queue with the classifier’s reasoning attached and set a status flag. It is the cheapest node in the graph and frequently the one that saves the most money.
Step 3: Connect everything with a conditional edge
Conditional edges are functions that read state and return the name of the next node. For triage: if confidence sits below 0.7, or the category is billing, return “escalate”. Otherwise return “draft”. Keep that threshold in one module-level constant, because you will tune it weekly for the first month.
Two habits prevent most of the errors here. The function returns a string, not a node object, and every possible return value needs a matching edge in the graph. Miss one and you get a runtime error at the least convenient moment, usually in front of someone important.
Step 4: Wire up checkpoints so the agent remembers
Compiling the graph with a checkpointer changes what the agent can do. Pass a thread_id on invoke, and LangGraph saves state after every node completes. The same customer writes in twice, you reuse the thread_id, and the agent already knows the category, the previous draft, and the escalation history. For step-by-step development an in-memory saver is fine. For anything real, use the SQLite or Postgres saver, which also means a crashed worker resumes the ticket instead of dropping it.
If you want the deeper version of how these primitives fit together, the walkthrough of state, control, and memory in LangGraph goes well past this tutorial.
Checkpoints still only cover a single thread. Cross-conversation memory, where the agent recalls that a customer churned six months ago and has just come back, is a separate problem, and frameworks like Letta are built around that specific gap.
Step 5: Pause for a human
Refund drafts should never go out unread. LangGraph’s interrupt mechanism halts the graph before a node executes, hands control back to your application, and waits. A reviewer approves the draft in your internal tool, you resume the same thread, and execution picks up exactly where it stopped, with state intact. Because the checkpoint already exists on disk, the API process can even restart in between without losing the ticket. This single feature is what moves an agent from a demo into something a support lead will actually sign off on.
Step 6: Give it real tools
Triage eventually needs an order lookup and a customer history check. Tool calling in LangGraph is a node that binds tools to the model, a ToolNode that executes them, and an edge back to the model so it can read the result and continue. The graph side takes twenty minutes. The forty OAuth flows behind those tools take three weeks, which is why something like Composio’s managed tool integrations is worth a look before you start writing connectors.
Step 7: Watch it run, then watch the bill
Stream events rather than tokens while developing. You get node-by-node output: what the classifier returned, which edge fired, how long drafting took, whether review passed on the first attempt. Attach a tracing tool and you also get the prompt text and per-call cost. Put a hard step budget on the review loop too, because a model that keeps failing policy review will cheerfully spin until someone notices the spend.
Where this design starts to strain
At a few thousand tickets a day, the graph above is comfortable. Past that, three things tighten. Latency stacks when the review loop runs twice. Token costs climb because the help-center article gets resent on every pass. The classifier drifts whenever your product names change. Two fixes carry most of the weight: cache the article lookup, and log every low-confidence classification for a weekly prompt review rather than a monthly one.
Not every agent deserves a graph, either. If your workflow is a straight line with no branch and no pause, something lighter like Agno will get you to production with far less ceremony. LangGraph earns its complexity when you need loops, durable checkpoints, and a human standing in the middle of the flow. Ticket triage needs all three, and six months from now when you add the fifth node, the diagram will still make sense to whoever inherits it.