Tutorials teach you what to add. We ship by what we delete.

LangChain multi agent orchestration is the practice of coordinating several LLM-driven nodes (agents) inside one directed graph, usually via LangGraph. The graph holds a typed state object, each node reads and writes that state, and conditional edges route based on state. In production it is three artifacts: graph.py (nodes, edges, typed state), an eval harness on a fixed golden set, and an audit trail of every node transition. The hard part is not building the first graph; it is keeping edges, models, and handoff depth bounded so the on-call can reason about what happened at 2am.

Command(goto=...) lets any agent return a runtime-only edge. The edge is not in the static graph, which means graph.draw() misses it, a CI graph walker that reads graph.py misses it, and a PR that adds three new Command(goto=) returns looks like a no-op on the review screen. We replace it with add_conditional_edges(node, router_fn) where router_fn is a pure function over state. Every edge becomes string-searchable. The graph walker in CI becomes the source of truth on topology again. For LangChain multi agent orchestration graphs that will run in production for months, that is non-negotiable.

interrupt() pauses a node mid-execution, waits for an external resume, then continues from the interrupted point with injected state. In production this creates three problems: the node is half-executed so state is partly stale, the resume path depends on a frontend that may have shipped a breaking change since the interrupt, and your eval harness cannot replay an interrupted run because it has no concept of 'partial turn.' Our replacement is a deterministic human_review node. The graph enters it, writes awaiting_human=TRUE to the audit row, and terminates. A separate endpoint (POST /cases/{id}/resume) starts a new run with the human decision already in state. One turn per transition, always.

MessagesState plus the add_messages reducer is a list that grows forever. For a 12-turn conversation it is fine. For a case that comes back three weeks later it is a prompt full of irrelevant history. By day 30 the p95 prompt is often 15 to 20k tokens of soup. Evals on turn-1 prompts pass; evals on turn-12 prompts cannot even be constructed because no two cases have the same shape. We replace MessagesState with a CaseState(BaseModel) where history is list[Turn] = Field(max_length=12) and a compact_history() function runs before every LLM send. Prompt shape becomes a function of turn count, not wall-clock accumulation. The eval harness can now build deterministic prompts for any turn.

When the supervisor uses with_structured_output() directly, two things get coupled: routing and a single vendor's function-calling API. Swapping vendors means rewriting the supervisor. Worse, the structured output class usually has a free-text reason field, which means routing is effectively controlled by a string the eval cannot grade. Our replacement: the supervisor returns a typed RouteDecision with an enum next_node: Literal[...] and a score: float. Structured output calls stay inside the scorer nodes that need domain schemas. model_adapter.py is the only file that talks to provider SDKs. Swapping Bedrock for Vertex becomes a one-line change in pick_primary().

A shell script in scripts/langgraph_lint.sh that runs five ripgrep searches. Each expected match count is 0 in src/ (tests can use whatever). One check for Command(goto=, one for interrupt(, one for MessagesState imports, one for with_structured_output( in supervisor files, one for MemorySaver. Plus a guard that add_messages only appears on fields with a max_length. The script exits non-zero on any violation. We wire it into .github/workflows/evals.yml as a required status check on main. A PR that re-introduces any of the five patterns cannot merge. It is 40 lines of bash and it has never been the reason an engagement slipped.

No. LangGraph is the framework we use on most LangChain-stack engagements. What we remove are five specific idioms the framework offers that look elegant in tutorials and fail silently in production. The framework itself is solid: StateGraph, add_node, add_edge, add_conditional_edges, PostgresSaver, and the compile/stream APIs are genuinely useful. We just force the implementation to use the string-searchable, type-checkable subset. The five deletions narrow the API surface; they do not replace the framework.

Three to five working days on a 500 to 2,000 line LangGraph codebase. Day 1: run the grep script, write down the counts, score the repo. Day 2: replace MessagesState with a typed CaseState and wire add_messages to a bounded field. Day 3: replace every Command(goto=) with add_conditional_edges plus a pure router function. Day 4: pull with_structured_output out of supervisor nodes into a RouteDecision shape. Day 5: swap MemorySaver for PostgresSaver, wire audit_rows, land the langgraph_lint.sh CI gate. If the existing graph is a 30-edge tree of sub-agents, it takes longer because the honest fix is to split the graph into two orchestrators with a queue between them, and that is closer to two weeks.

One senior engineer has been named on your repo for the full six weeks. What stays after they leave: a graph.py with 6 to 8 named nodes and 7 to 8 edges, a state.py with a typed Pydantic CaseState, a model_adapter.py with pick_primary and pick_fallback, an eval harness under tests/eval/ replaying a frozen golden set nightly, a langgraph_lint.sh plus a graph_walker.py in CI as required status checks, a Postgres schema with audit_rows and checkpoints in the same database, and a runbook.md keyed to the alerts your on-call will actually get paged on. No vendor runtime. No platform license. Your team can tighten or loosen every number in a PR on the same afternoon they decide to.

TypedDict is checked at type-check time and ignored at runtime. A bug that writes state['handoff_budget'] = -1 runs fine until the conditional edge divides by it. A pydantic BaseModel with Field(ge=0, le=3) raises on the assignment. For LangChain multi agent orchestration graphs where state is the only thing stitching agents together, we want the type system to catch the error at the write site, not at the read site three nodes later. It costs a few microseconds per transition and saves an unknowable number of 2am debug sessions.

Every engagement we do starts with reading the client's existing code against a checklist of LangGraph idioms that have broken a previous client. The list was 11 entries long as of mid-2025; it sits at 5 now because the other 6 moved out of LangGraph into fixed framework behavior or are rare enough that they do not repeat. The five that remain repeat in every engagement. If you are reading this in 2027 and your repo has a sixth antipattern we have not listed, that is an engagement, not a docs bug.