LangGraph: When to Use It for AI Agents (and When Not To)

LangGraph: When to Use It for AI Agents (and When Not To)

LangGraph is a library for building AI agents as a stateful graph: steps (nodes) read and update a shared state, and rules (edges) decide which step comes next. If you are asking when to use LangGraph for AI agents, the short answer is when the process branches, loops, pauses for human approval, and has to resume exactly where it stopped. If the process is a short, predictable sequence, a simple workflow, either plain code or an automation tool, is usually enough and easier to maintain.

Key takeaways

• A stateful graph has three parts: the state (the data that travels through the flow), the nodes (the steps) and the edges (the path rules, fixed or conditional).
• Persistence lets you pause, resume and audit a run, which matters when a human approval can take hours or days.
• Real human approval is a pause in the flow with the state saved, not just a notification sent to someone.
• A simple workflow is enough when the path is linear, short, has no long waits and has no decisions that depend on what happened earlier.
• Choose based on the problem in your process, not on the tool: start simple, measure where the flow breaks, and only then adopt the graph.

What is a stateful graph, without the jargon?

Picture a customer support process drawn on a whiteboard: boxes for the steps and arrows for the possible paths. In a stateful graph, that drawing becomes code. Each box is a function that receives the current state, does something (calls a model, queries a system, validates a field) and returns what changed. Each arrow says where to go next, sometimes always to the same place, sometimes depending on what is in the state.

The state is the central piece. Instead of each step receiving only the output of the previous one, all steps work on a shared record: the customer's message, the data collected so far, the draft reply, how many attempts were made, whether approval was given. This makes it explicit what the agent knows at any moment, and it helps answer the question every manager eventually asks: why did the agent do that?

The official LangGraph documentation describes this model with nodes, edges and conditional edges, and it allows cycles, meaning a return to an earlier step. Exact function and module names change between versions, so always confirm them in the documentation for the version you plan to use.

When is a simple workflow enough?

Anthropic, in its article on building effective agents, recommends starting with the simplest solution and adding complexity only when the need is demonstrated. The same article separates workflows (paths defined in code) from agents (the model decides the steps dynamically) and warns that frameworks can add layers that hide prompts and responses, making debugging harder.

In practice, a simple workflow is usually enough when:

• the steps are always the same, in the same order (for example, receive the message, classify it, reply);
• the flow ends in a few seconds, without waiting for anyone;
• if something fails, repeating everything from the start is cheap and safe;
• there are no loops of the try, check, fix, try again kind;
• an automation tool such as n8n already covers the integrations, and you only need one model call in the middle.

If that describes your case, read the article on n8n error handling and retries, which covers how to keep a deterministic flow stable without introducing an agent framework.

When does the graph start to pay off?

The graph starts to justify its learning cost when the flow stops being a straight line. Use the list below as a checklist: the more items are true for your process, the more likely the graph is the right tool.

• There are real branches: the next step depends on what was found in the previous one, and there are several possible paths.
• There are loops: the agent has to try, check the result and try again, with a clear limit on attempts.
• There are long waits: the flow has to stop for hours or days while waiting for a person, a customer or an external system.
• There is human approval at specific points, and the person can approve, reject or edit before the flow continues.
• There is a need to resume after a failure without redoing expensive steps or repeating actions that have external effects.
• There is a need for auditing: knowing what the agent knew and decided at each step.
• There are several parts of the work with distinct responsibilities, but still under one shared state.

On that last point, be careful: splitting work across several agents is not a goal in itself. The article on multi-agent systems and when a single agent is enough helps you test whether the split solves a real problem before you complicate the architecture.

A loop also needs a brake. Every cycle in the graph needs a limit on steps, time and spend, otherwise the agent can keep trying indefinitely. The article on AI agent infinite loops and step limits explains how to set those limits.

How do human approval points work?

The most common mistake is treating human approval as a notification: the agent performs the action and tells someone. That is information, not approval. Real approval means the flow stops before the action, saves everything it knows, waits for an answer and only then continues.

According to the LangGraph documentation, this is done with an interrupt mechanism: the node pauses execution, the state is saved by a checkpointer, and the flow is resumed later with the person's decision, identifying the run by a conversation identifier (a thread). For this to work, the graph must be compiled with a persistence mechanism. Without one, there is nowhere to keep the state during the pause.

A useful approval point has four elements:

• what will be done, described in plain language (send this proposal, refund this amount, change this record);
• the data that supports the action, so the person does not decide blind;
• the available options: approve, reject with a reason, or edit before continuing;
• a deadline and an owner, with a rule for what happens if nobody responds.

Which actions require such a point is a business decision, not a technical one. Irreversible actions, actions that move money, change customer data or commit the company to something are natural candidates. When the decision directly affects a person, also check the right to review automated decisions under LGPD.

What does persistence store, and what care does it require?

Persistence means the flow state is written at points during the run (checkpoints) to a storage you choose. The benefits are concrete: resuming after a crash, pausing for an indefinite time, inspecting what happened and, according to the documentation, even going back to an earlier point and re-running from there.

But persisting also creates obligations. Three deserve attention from the start:

• Personal data in the state: if the state carries names, phone numbers, addresses or conversation content, it becomes a data store under LGPD. Keep only what is necessary, define for how long, control who has access and check where the storage is located. If providers outside Brazil are involved, read the article on international data transfer under LGPD when using AI providers.
• Repeated effects: on resume, the node that was paused may run again from its beginning (confirm this behavior in the version you use). If that node sends a message or creates an order before the pause, the result can be duplicated. Separate the decision from the action, put the action after the approval, and use idempotency keys when the target system supports them, as described in Stripe's documentation on idempotent requests.
• Version changes: a flow paused today may be resumed after the graph has been changed. Decide in advance how to treat old runs: finish them on the previous version, migrate them or discard them.

Observability and persistence are different things. Checkpoints exist to resume the flow, while logs and traces exist to understand its behavior. For that second part, the OpenTelemetry observability primer explains the concepts of traces, metrics and logs that you will also want to have.

Illustrative scenario: a proposal with approval before sending

This is an illustrative scenario, unrelated to any real company. A services company receives quote requests on WhatsApp. The agent has to collect information, check an internal reference table, assemble a draft proposal and send it, but no proposal can go out without review by someone on the sales team.

As a graph, the flow would look like this:

• Collection node: the agent asks for what is missing and updates the state. If information is still missing, it asks again, with a limit on attempts.
• Lookup node: it fetches reference values from internal systems and records the source of each data point in the state.
• Draft node: it generates the proposal and the assumptions used.
• Approval point: the flow pauses. The salesperson sees the draft and the supporting data, and chooses to approve, edit or reject with a reason.
• Send node: it only runs after approval, with an idempotency key so it never sends twice.
• Record node: it logs the decision, who made it and when.

The pause might last overnight or through a weekend. Without persistence, the process would have to hold everything in memory or rebuild the context each time. With the state saved, the resume continues exactly from the approval point. If, instead, the flow only had to reply from a fixed price table, a simple workflow would be enough. For similar processes in specific sectors, see how the same logic appears in AI for solar energy companies, with proposals and after-sales support.

How to apply the method: map, limit, pilot, hand over

The method we use for AI projects fits the graph decision well, and it helps you avoid adopting the tool before you understand the process.

• Map: draw the current process, including the real exceptions, and record a baseline (cycle time, rework, who decides what). If the drawing is a straight line, you probably do not need a graph.
• Limit: define which data the agent can see, which actions it can take alone and which require approval. The design of the approval points starts here.
• Pilot: implement a single real flow, with logs and a success metric agreed in advance. If the pilot shows the path is almost always linear, simplify.
• Hand over: deliver with documentation, access and clear criteria for deciding whether to expand, adjust or stop.

All of this separates three kinds of claims: what is in the official documentation, what comes from implementation experience, and what is still a hypothesis to be tested in your pilot. This article treats the interrupt and persistence behavior as documentation, and the recommendation to start simple as guidance from primary sources that you should validate in your own context.

What risks does the graph not solve on its own?

A graph organizes the flow, but it does not make the agent safe by itself. Three risks remain with you.

• Permissions: each node should have minimal access to tools and data. The graph does not decide that, your configuration does.
• Hostile content: text coming from customers or documents can try to manipulate the agent. See the article on prompt injection protection for AI agents for the basic defenses.
• Answer quality: a well-designed flow can still produce poor answers. Evaluate with real cases and review samples regularly.

Anthropic also publishes material on long-running agents, which deals with the challenge of keeping progress and context across multiple work sessions. It is worth reading if you plan to operate flows that stretch over time.

Frequently asked questions

Is LangGraph only for people who use LangChain? The documentation presents LangGraph as an orchestration library for stateful agents, and it is common to see it used alongside other components of the ecosystem. Before deciding, confirm in the documentation for the current version which dependencies are required and which models and providers you can use.

Do I need LangGraph to add human approval to an agent? Not necessarily. You can implement approval with your own code, a queue and a database, or with an automation tool that has a wait step. The graph helps when the pause has to preserve a complex state and the flow may have several approval points and branches.

When should I move from a simple workflow to a graph? Move when the simple workflow starts to pile up patches: workarounds for repetition, improvised status tables, difficulty resuming after failures and doubts about what the agent knew at each decision. If those symptoms do not show up, migrating only adds maintenance cost.

Who should maintain the graph after delivery? Define this at the start of the project. Someone inside the company or a partner has to be responsible for updating versions, reviewing logs, adjusting approval points and deciding when to expand. Without a clear owner, the flow ages and approvals turn into a formality.

Sources

• Anthropic: Building effective agents
• Anthropic: Effective harnesses for long-running agents
• OpenTelemetry: observability concepts
• Stripe: an example of provider-defined idempotency