LangGraph in Production: Seven Lessons from Service Splitting to Human-in-the-Loop

Many LangGraph tutorials teach you how to build a working demo, but few explain clearly where things go wrong once that graph actually runs in production, facing real users and real bills every day. A developer shared parts 2 through 7 of the series "Agent Graph Engineering" on Reddit, all drawn from production-grade AI systems their team actually built and operated — and most of the lessons were learned from bugs, not planned in advance. The series comes with a complete runnable repository, not a patchwork of code snippets.

Why split services and agents apart

Part 2 is about service boundaries. The author lists the real costs of cramming an agent and the product into the same service: a prompt silently expires the day the billing module adds a new plan, and you never notice; a graph that needs to run in a test first requires a database and a pile of fixtures. The more practical problem is deployment — model calls are slow, web workers get blocked waiting on them, and by the time you finally want to deploy the agent separately, you find it can't be untangled.

The common thread is that these problems don't hurt early on, and by the time they do, refactoring is expensive. The author's advice is to think through where the boundaries go ahead of time, rather than waiting until blocking happens to act.

Web worker is a process or thread that handles HTTP requests, usually tied to the user request lifecycle and expected to respond quickly. Model calls often involve external APIs with latencies of seconds or even tens of seconds. If the agent shares a process with the web service, the worker gets occupied for long stretches, sharply reducing concurrency and potentially dragging down the whole service. Once the agent is split into its own service, the web worker only needs to forward requests asynchronously and stays lightweight, while the agent service can scale and deploy independently.

Contracts are more reliable than conventions

Part 3 is about cross-service collaboration. Their system has three services and two languages, and at one point a field rename ended with a customer telling them the frontend was still reading the old field. This shows that verbal and documented agreements can't hold up in a multi-language, multi-service environment — what you need is an explicit contract.

For teams building multi-service agent architectures, the lesson is direct: changing a field isn't just a matter of renaming it; the interface contract is the anchor for cross-team collaboration.

Explicit contract refers to defining data formats between services with machine-verifiable interface descriptions (such as OpenAPI, Protobuf, JSON Schema), rather than relying on documentation or verbal consensus. In multi-language, multi-service environments, contract files can serve as the basis for code generation and continuous integration checks: a field rename immediately triggers a build failure or test alert, rather than waiting for customer feedback. The core value of a contract is making cross-team assumptions explicit and automatically verified, reducing communication costs and the risk of production incidents.

Learn model calls and the flow chart together

Part 4 is the one the author most recommends to beginners. The core idea: a model call and the flow around it are easier to understand when learned together; and making the two fit tightly means the model cannot wander into branches you never planned.

This actually points to the value of frameworks like LangGraph — not making the model smarter, but making the scope of the model's actions controllable. For an open-ended assistant this may be a limitation, but for business scenarios that need determinism, it's exactly the desired effect.

Tools and guardrails: the lesson about money

Part 5 is what the author calls "the one about money." The scenario is an irreversible operation that gets re-executed because a crash caused its step to run again — so the operation ran twice. This kind of problem is hard to expose in tests, yet maps directly to real losses.

The other half of guardrails is what the model is allowed to say. The author's lesson: a guardrail that truly holds up treats the customer's own words as data (fencing) rather than scanning them for bad words. This shift in thinking is worth noting — from content filtering to data isolation.

Idempotency means that executing the same operation multiple times has the same effect on system state as executing it once. In distributed systems, crash retries and timeout resends are common; if an operation is not idempotent (such as charging a payment or sending an email), repeated execution causes financial loss or harassment. Implementing idempotency usually requires a unique request ID, a deduplication table, or a state machine. For irreversible operations, introduce an idempotency key at design time to ensure safe reruns. This is a key point that is hard to expose in tests but must be considered in production.

Subgraphs: multi-agent systems you can see

Part 6 discusses subgraphs. Splitting a graph into multiple expert nodes and having a supervisor route among them is itself a kind of multi-agent system — just not the kind where agents negotiate with each other. The author's judgment here is pragmatic: "agents can't deviate from the script" is a cost in an open-ended assistant, but in a system responsible for a refund flow, it's the whole point.

In other words, multi-agent doesn't have to pursue autonomy and negotiation; controlled orchestration is often the right choice in many business scenarios.

Human-in-the-loop: the easiest failure mode to miss

Part 7 is the most recently published and, in the author's view, the one to read first. The scenario sounds simple: a reply sits there waiting for review, the review passes, and then it silently never gets sent.

This kind of failure can't be found in tests. It isn't an exception, it isn't an error — it's just that an action that should have happened didn't. Putting humans in the loop sounds like a safety measure, but if the flow is poorly designed, the human review step itself becomes a new point of failure.

Human-in-the-Loop (HITL) refers to inserting human review or decision points into automated flows, commonly used for high-risk operations. But HITL is itself a distributed state machine: states such as pending review, approved, rejected, and sent need to be persisted and transition reliably. Common failures include no follow-up action after approval, lost state updates, and timeouts left unhandled. When designing, treat the human step as a formal service, ensuring atomicity and observability of state changes to avoid "silent failures."

What else the series covers

The author mentions several frequently asked topics will be covered later: how progress inside the graph reaches the browser, what tracing a run actually tells you and what it costs, and how to swap models or prompts without relying on luck.

The whole series comes with a repository of a complete working system (not fragments), and the author explains the entry points for different readers: those already running LangGraph in production can use it as a reference for when "something starts to hurt"; those still choosing a stack can see which choices are cheap this month and expensive next year; those learning have a whole system to read with the reasoning behind its decisions; and those doing client delivery have a foundation that won't turn into a maintenance nightmare.

For teams moving agents from demo to production, the value of this content is that it records the order in which pitfalls were hit, not an ideal architecture diagram.

One-line Summary

Hard-won lessons from production AI systems: failure modes in service splitting, contracts, guardrails, and human review.

Paragraph Summary

Based on parts 2 through 7 of the Reddit series "Agent Graph Engineering," this article summarizes real lessons from deploying agent frameworks like LangGraph in production. Core problems include: agents and the product sharing a service, leading to test dependence on a database, model calls blocking web workers, and difficulty splitting them apart; the need for explicit contracts rather than verbal agreements in multi-language, multi-service settings; irreversible operations that may execute twice on crash retries, requiring idempotent design; effective guardrails that treat customer input as data rather than scanning for bad words; and human review steps that can themselves become failure points, such as replies that are approved yet never sent. The article emphasizes that these failure modes are hard to expose in tests but map directly to real losses, and advises teams to plan boundaries and safeguards in advance.