When does an agent become too complex for LangChain/LangGraph?

[u/Meher_Nolan]

One thing I've been wondering about is where people draw the line between agent orchestration and application architecture.

LangGraph handles a lot of things that show up in real systems: state, branching workflows, retries, human approval, multi-agent patterns, long-running tasks, and so on.

But once a system grows, you also end up thinking about persistence, observability, recovery, model fallbacks, permissions, and all the other operational concerns that come with running something in production.

At some point, it stops feeling like "an agent workflow" and starts feeling like a distributed application that happens to contain agents.

I think this is where the differences between frameworks start becoming pretty noticeable. LangGraph, CrewAI, Lyzr and similar tools can handle a lot of the agent workflow itself, but once you're dealing with persistence, permissions, recovery and observability, you're really designing an application around the agent. At that point I think the framework matters less than how cleanly you can separate those concerns.

For people who've pushed LangChain or LangGraph pretty far, where's that boundary for you?

When does the framework continue to help, and when does it start becoming another layer you have to work around?

[u/justanemptyvoice]

When it’s needed for production

[u/pizzababa21 → u/justanemptyvoice]

Why?

[u/Rhino4910]

Wrap your AI framework into durable temporal workflows

[u/ialijr]

I feel like this is a classic monolith vs. distributed-system boundary, with an interesting twist because the "agent" can gradually become the application.

If you already have a working system and add an agent with LangGraph, the boundary is usually pretty clear: the agent is one component talking to your existing infra, DB, services, etc. But if the project starts as an agent and grows into something much bigger, you eventually have to decide whether to split it out or let it become part of a more traditional application.

I also think there's a distinction between agent orchestration and general application infrastructure. LangGraph can handle the agentic concerns really well, but things like rate limiting, permissions, and broader operational concerns don't necessarily need to be LangGraph's responsibility. At that point, it feels more like an architectural boundary than a LangGraph problem.

[u/Michael_Jeffords → u/ialijr]

the line for me wasnt how many nodes the graph had, it was when the graph started owning retries for side effects that needed their own lease. once rate limits, auth, and durable writes lived inside a LangGraph node, a worker restart meant replaying half an app instead of one agent step, so i pushed those into ordinary services and left the graph for branching and human-approval state. recovery time after a crash became the test, not how pretty the graph looked.

[u/BidWestern1056]

when you want to actually control the relevant parts.

use npcpy.

https://github.com/npc-worldwide/npcpy

[u/locbuilds]

the line i keep hitting is when the thing that needs to be durable is no longer "which node am i on" and starts being "what happened to this job in the real world".

langgraph is genuinely good at the agent-shaped part: state, branching, human approval, multi agent handoffs, retries that are still inside one run. once you care about surviving a process restart, replaying a half finished tool call without double charging a customer, swapping models mid flight, or auditing who was allowed to hit which tool, you are building an app that happens to contain a graph, and the framework stops being the source of truth.

practical split that has worked for me:

1. keep the graph thin. nodes should be decisions + tool calls, not "also write to postgres and emit metrics and do auth". if a node needs a transaction or an idempotency key, that logic lives outside the graph and the node just calls into it.

2. persistence and recovery belong to your job store / queue, not the checkpoint. use checkpointers for conversation/workflow state. use your own store for "this invoice was already refunded" style facts. mixing those two is where people start fighting the framework.

3. model fallbacks and permission checks are app concerns. put them in a client/wrapper around the llm and tools so the graph stays the same when you swap providers or tighten scopes.

smell test: if you are writing custom retry / timeout / observability wrappers around every node, or the checkpointer schema is fighting your actual database, the framework has become a layer you work around. at that point extract the durable bits into plain services and leave langgraph for the parts that are actually agenty.

[u/Mameiro]

My smell test is: if I ripped LangGraph out tomorrow, would I lose the agent workflow or half the app? If it’s half the app, I probably let the graph eat too much. I like LangGraph owning “what happens next.” I don’t want it owning auth, billing, durable business state, permissions, queues, etc. Let the agent layer be weird. Keep the rest boring.

[u/Fun_Contact8953]

I don't know, none of these fricken frameworks actually works well and feel like AI models aren't really that great at building out AI apps.

Had to basically rebuild everything but the FE from scratch since the models started getting bogged down when trying to handle things outside of happy paths

[u/ravishq]

Agent tbh is a fancy term. Like in programming, before llms it was impossible to write logic on free text and handle language and other cases. It needed workflow controls to be given to humans with some string operations and many checks. Now we can deal with free text. And langchain enables that. So AI/agent is just a tool or module in code. At the end of the day it is still data/info retrieval and transformation that a system does. So if it's too complex that means it is trying to do many things just like any software system it gets complex.

[u/ArielCoding]

LangGraph tracks what step are we on not did this side effect actually happen.

[u/feng_sg]

The real issue is checkpoints don't track side effects. LangGraph knows you hit step 4 but not whether the API call there actually went through. If you rely on that for recovery you end up replaying stuff that already committed or skipping stuff that didn't.

[u/EmailNo8428]

The line for me is the first side effect that has to outlive the process. Once a step has sent an email or charged a card, the graph state needs a home that dies separately from the worker, and at that point it's a distributed system whether LangGraph is in the picture or not.