Advanced 6 min read Updated Sep 11, 2026

Debugging with LangGraph Studio

print() statements work fine for a linear script. They fall apart fast once your graph has conditional edges and loops, because the question you actually need answered isn't "what did this node output," it's "why did the graph take this branch instead of that one, three steps ago." LangGraph Studio exists specifically for that second question.

What Studio actually shows you

Studio is a visual IDE for a running graph. Point it at a local dev server (started with langgraph dev) or a deployed Platform app, and you get your graph's actual structure rendered as a diagram, the same nodes and edges you defined in code, now something you can click on. Start a run, and you can watch it move through the graph node by node, inspecting the full state at every single step instead of only the final output.

Time travel: the feature that actually saves you time

The most useful part of Studio isn't watching a run happen, it's what you can do after something goes wrong. Because every step is checkpointed (the same checkpointer from the memory and persistence guide), Studio lets you jump back to any prior checkpoint in a run, edit the state by hand, and resume execution from that exact point, without re-running everything that came before it.

What this replaces: the old workflow of "add a print statement, re-run the whole agent from scratch, wait, read the output, repeat" for every hypothesis you want to test. With time travel, you fix the one thing you suspect is wrong at the exact step it went wrong, and resume from there.

A typical debugging session

Say an agent keeps calling the wrong tool for a certain kind of question. In Studio, you'd run the failing case, watch the graph diagram to see exactly which node made the bad decision, open that step to see the exact state and prompt the model saw at that point, edit the state or the routing logic, and resume the run from there to check whether the fix actually worked, all without touching your terminal.

Studio and LangSmith tracing are the same underlying data

If you have LangSmith tracing enabled (covered in LangSmith 101), every run you inspect in Studio is also showing up there as a full trace, with every LLM call, token count, and latency broken out. Studio is best for interactive, in-the-moment debugging of one specific run; LangSmith is best for looking across hundreds of runs to spot patterns Studio, by design, only shows you one at a time.

That's the series

Across these nine guides you've gone from what a graph even is, through building one, persisting it, adding a human checkpoint, naming the shape it takes, streaming its output, deploying it, and now debugging it properly. That's the complete loop of actually shipping a LangGraph agent, not just prototyping one. The fastest way to make it stick is the same advice every guide in this series has landed on: build something small, real, and slightly annoying, and let the parts you actually need reveal themselves.

You've completed LangGraph 101. Explore the other guide series - Claude 101, LangChain 101, LangSmith 101, and n8n 101 - or see what APA Mastery has on next below.
Share this guide

Was this guide helpful?

Thanks for the feedback!

Want more hands-on AI builds like this?

APA Mastery runs live, practical sessions on working with modern AI tools - not just theory.

See What's On →
← PreviousDeploying LangGraph