LangGraphinPractice:BuildingAgentsWithMemoryandTools

An ad-hoc agent loop - "call the model, execute whatever tool it picked, repeat" - has no explicit model of the possible states the system can be in. Debugging it means reading through a transcript and guessing why the model decided what it decided. There's no way to say "this step must always run after that one" or "if this tool fails, go here instead" without more prompt engineering.

LangGraph makes the control flow a first-class, inspectable graph: nodes are units of work (an LLM call, a tool call, a piece of business logic), edges define what can follow what, and the graph's state is an explicit, typed object that flows through every node. That's the difference between an agent you can reason about and one you can only observe.

The graph's state schema is the most important design decision in the whole system - it's the shared memory every node reads from and writes to. Keep it typed and minimal: the conversation so far, the task's working data, and any decisions already made. Resist the urge to dump everything into state "just in case"; a bloated state object makes every node harder to reason about and every prompt built from it more expensive.

For longer-running or resumable agents, LangGraph's checkpointing persists state between steps, so a workflow can pause - waiting on a tool, a human, or an external event - and resume exactly where it left off, rather than replaying the whole conversation from scratch.

Treat every tool call as something that can fail, because in production it will - a timeout, a malformed response, a permissions error. A tool-calling node should catch these explicitly and route to a recovery path in the graph (retry with backoff, fall back to a different tool, or surface the failure to a human), rather than letting an unhandled exception crash the whole run or, worse, letting the model silently hallucinate a plausible-looking result.

This is where the graph model earns its keep: the retry and fallback logic is a visible part of the graph's structure, not buried inside a giant prompt trying to instruct the model to "handle errors gracefully."

Not every decision an agent makes should execute automatically - sending an email to a customer, approving a refund, or merging code are exactly the actions where a wrong call is expensive. LangGraph lets you insert an explicit interrupt node: the graph pauses, state is checkpointed, and the workflow waits for human approval (or edits) before continuing on the same state it paused with.

Deciding where these checkpoints go is a product decision as much as a technical one - the goal is to place them at the few steps where being wrong is costly, not at every step, which would just turn the agent back into a human doing all the work with extra latency.

Test nodes independently first - a tool-calling node with a mocked tool response, a decision node with a fixed state input - the same way you'd unit test any function, before testing the graph end to end. For the full graph, build a small suite of realistic scenarios (including ones designed to trigger the failure and recovery paths) and assert on the final state and the path taken through the graph, not just the final text output.

LangGraph's execution trace - which nodes ran, in what order, with what state at each step - is the debugging tool that ad-hoc agent loops don't give you. When something goes wrong in production, that trace is usually enough to pinpoint which node made the bad decision.