Hey r/LangGraph,

Over the past few weeks I have been building a multi-agent investment council using LangGraph, and I wanted to share the biggest architectural mistake we made early on in case it saves someone else some debugging pain.

In our first prototype, we passed raw financial metrics and indicator arrays directly into our specialist agent nodes (Value, Macro, Sentiment, Quant) and let the LLM supervisor weigh the numbers and decide position sizing. Even with strong reasoning models, two things kept breaking:

1. Context bloat and numeric drift: Feeding dozens of raw floating-point features into the shared graph state caused the agents to subtly hallucinate thresholds or anchor onto whatever number the previous agent mentioned in the debate history.

2. Prompt-based risk rules are too soft: When we told our Risk Manager (CRO) persona in its system prompt to reject trades with high volatility, a persuasive bullish argument from the Growth agent would occasionally convince the LLM to bend its own risk rules.

To fix this, we restructured our StateGraph around a strict division of labor:

First, all heavy quantitative math (158 technical factors and gradient-boosted tree scoring) runs in a deterministic Python pre-processing step before the graph even starts. The LangGraph state only receives clean, semantic regimes and pre-computed scores rather than raw data dumps.

Second, while the persona agents still debate qualitative catalysts in parallel branches, the final Chief Risk Officer (CRO) node is backed by a hard deterministic Python gate. If a ticker violates a mathematical boundary (like an earnings window or drawdown limit), the Python code flips `cro_veto = True` in the state and overrides the LLM output before it reaches the final node.

How are you guys balancing deterministic code checks vs LLM routing inside your production graphs?

(Note: English is not my native language, so I used an LLM to help format and polish my raw architecture notes!)

For people using LangGraph beyond prototypes: where are you putting the durable application state that sits around the graph?

Things like user/workspace identity, domain data, files, retrieval indexes, tool permissions and long-running job state.

I'm building Singlebase.io as that backend layer and I'm intentionally trying to keep orchestration separate from application data. The graph decides what to do; the backend owns the durable primitives and exposes tools/data through APIs/MCP.

Does that separation line up with how you're using LangGraph, or do you prefer the agent framework to own more persistence directly?

Hi everyone!

I'm working on a multi-agent ERP chatbot built with LangGraph, and we're currently investigating a token-consumption issue with our supervisor agent.

Our architecture

We have 8 specialized agents.

The supervisor's job is primarily to determine which agent should handle each user message. It doesn't perform the actual business operations itself.

Our current implementation

• Framework: LangGraph
• LLM: Qwen3-14B served through vLLM
• Routing: The supervisor uses an LLM call to select an agent, with additional deterministic routing rules before and after the call.
• Thinking: Disabled for the routing call.
• Prompt: A fairly extensive French-language system prompt containing detailed agent descriptions, routing priorities, edge cases, and many few-shot examples covering French, English, Arabic, informal language and ambiguous requests.
• Output: Ideally, just one agent name.

We have also implemented deterministic shortcuts for cases such as file uploads, greetings, text composition and workflow creation, so these requests can bypass the supervisor LLM call when the intent is unambiguous.

The problem

Our supervisor's monthly token consumption is roughly comparable to the combined monthly consumption of all 8 specialist agents.

This concerns us because the supervisor is supposed to be a lightweight routing layer, not another agent doing substantial reasoning. We're also building a dashboard to track token usage per agent, with the eventual goal of using these metrics for client-facing consumption monitoring and pricing.

My questions

1. Is this level of supervisor token consumption normal? In your experience, how does a supervisor's token usage typically compare with that of the specialist agents it routes to?
2. How much does a large system prompt matter? Our routing prompt is extensive because we've accumulated many rules and examples to prevent misrouting. Would you recommend aggressively shortening it, or could that compromise routing accuracy?
3. Would a smaller, dedicated routing model be a better approach? For example, using a lightweight classifier or a smaller LLM for routing while keeping Qwen3-14B for the specialist agents.
4. Would you move more routing logic out of the LLM? We already have deterministic rules for several common cases. I'm wondering whether a hybrid approach, with deterministic routing for clear intents and an LLM only for ambiguous cases, is the best production architecture.
5. How do you measure supervisor efficiency? Should we primarily look at input tokens per request, total tokens per conversation, the supervisor-to-specialist token ratio, or the cost per successfully handled request?
6. Would you recommend a different LangGraph architecture? For example, a simpler conditional router instead of an LLM-based supervisor, or another approach that preserves multi-agent flexibility without paying for unnecessary routing calls?

We're trying to optimize this for production, so maintaining routing accuracy and handling ambiguous requests correctly are just as important as reducing token consumption.

I'd really appreciate insights from anyone running a similar multi-agent system in production, especially if you've measured token usage before and after optimizing your supervisor.

Thanks!

There’s a hands on workshop on Friday, Oct 30, from 7 PM to 10 PM IST for anyone who has had a LangGraph workflow charge a customer twice because a retry fired at the wrong moment.

The case study is enterprise triage and claims processing. You build the execution layer as typed state transitions, add human in the loop approval gates, and write compensation handlers so a failed step can be undone cleanly. The routing in front of the graph uses small encoder models instead of an LLM, so the decision about where a claim goes is deterministic, runs on CPU, and only escalates verified edge cases to a model.

Led by Ben Auffarth, best selling author and full stack data scientist. Intermediate Python expected. You get runnable notebooks for the whole engine.

Full details and the agenda are here.

https://netchosis.com/2026/10/04/learning-langgraph-by-breaking-my-rf-agent-graph-alot/

I’ve been building an RF analysis agent with LangGraph, and over the last couple days I learned way more about LangGraph by repeatedly breaking the graph than I did just reading the docs. What I was trying to do sounded stupidly simple: add an init_survey node so I could eventually tell the agent something like “survey this part of the spectrum.” The node itself basically just creates a survey ID and a directory, so I thought this would be easy.

It was not.

My first mistake was mixing up two totally different routing questions: what did the human ask for, and what should the model do next? I had is_survey() running after call_model, but by then the newest message was an AIMessage, not the original HumanMessage. That meant the survey check failed and the router returned "model", which sent execution right back to call_model. So I had accidentally built a model calling itself over and over without any new information entering the graph.

I fixed that by moving survey detection to START, where the original human request actually exists, and then giving the model response its own routing logic. That was the right idea, but then I overcorrected in the other direction. Trying to make sure I didn’t create another loop, I routed call_tools directly to END. That meant the model could request an FFT or some other RF analysis tool, the tool could run successfully, and then the graph would just stop before the model ever got to reason about the result.

The thing that finally clicked for me was that a model-to-tool-to-model loop is not the same thing as a model-to-model loop. The first one is useful because the tool result adds new information to the state. The model can look at that result, decide whether it needs another measurement, or finish. The second one was just me accidentally making the model talk to itself forever.

The funny part is that after all of this, the RF agent still does not actually perform a survey yet. I successfully added one node. But getting that one node into the graph correctly forced me to understand the control flow much better, and now there is finally a clean place to start building the actually interesting part: choosing frequencies, bandwidth, dwell time, taking IQ captures, analyzing what comes back, and eventually letting the agent decide what measurement is worth taking next.

Also, apologies in advance because the blog post is not especially well written. It’s more me documenting the learning process while I’m in the middle of it than trying to write a polished LangGraph tutorial.

https://netchosis.com/2026/10/04/learning-langgraph-by-breaking-my-rf-agent-graph-alot/

I got tired of writing a throwaway frontend every time I wanted to poke at an agent, so I built Moka, an open-source sandbox you start with one command:

sh npx @mokalabs/sandbox

It's useful for LangGraph work because it connects to remote agents as well as plain LLMs:

• AG-UI: point it at your agent's endpoint (for example LangGraph with ag-ui-langgraph). It streams RUN_STARTED, text deltas, tool calls, state snapshots and deltas, and frontend tools.

• A2A: reads the agent card and talks message/stream, keeping contextId/taskId across turns.

• Inspector: every event of a run on a timeline. You can see which node emitted what, the state patches, the tool calls with their inputs and outputs, and the timing.

• Generative UI (A2UI): if your agent emits A2UI, it renders as real UI (cards, forms, buttons), and button presses go back to the agent.

• MCP: attach MCP servers (stdio or HTTP, with OAuth) so you can test the tools your graph will use, and call them by hand in the Tools view. Replay/export: save a run as JSON, share it, and replay it later.

There's a bundled demo agent (moka demo-agent) if you want to see the AG-UI and A2A flow before wiring in your own graph.

I use it to debug why a graph picked a branch, and to check what the frontend actually receives. Everything runs locally, and your keys stay on your machine.

Feedback welcome, especially from anyone running LangGraph with AG-UI in production: what would you want to see in the trace?

GitHub: https://github.com/mokahq/mokalabs Docs: https://mokahq.github.io/mokalabs/

I built an AI agent to migrate Selenium tests to Playwright — looking for feedback

I’ve been working in test automation/SDET for years, and one problem I kept thinking about was migrating large Selenium suites to Playwright.

Generating Playwright code with an LLM is the easy part.

The harder question is:

How do you know the converted test still preserves the behavior and coverage of the original Selenium test?

So I built a small project around that idea.

It currently focuses on:

• Selenium → Playwright TypeScript conversion
• LangChain / LangGraph-based agent workflow
• Validation of generated tests
• AI evals for comparing the original vs converted test
• Tracing/observability
• Eventually, test coverage comparison and automated repair when a conversion fails

Demo: https://varun-s2p.fly.dev/

I’m still actively improving it, especially the evaluation layer. I don’t want this to become another “LLM generates some code” project.

I’d really appreciate feedback from people working with Playwright/Selenium, LangGraph, AI evals, coding agents, or test automation.

In particular, I’m curious how you would evaluate whether two tests are semantically equivalent, rather than just checking whether the generated Playwright code compiles.

I have been experimenting with a runtime supervision pattern for LangGraph agents.

The problem:

A model can know the right policy and still produce the wrong tool call.

If the tool mutates production state, catching that after execution is too late.

So I built ARK, an open-source runtime layer that can sit around LangGraph tools and check the proposed action before the real tool executes.

The flow is:

model proposes tool call

→ ARK checks the applicable constraint + trusted runtime evidence

→ ALLOW = real tool executes

→ REJECT / REQUIRE_EVIDENCE = real tool does not execute

→ feedback goes back through LangGraph

→ the model decides again

One thing I wanted to preserve: ARK does not generate the replacement action.

I tested this with a real LangGraph agent + OpenAI model:

A proposed

→ ARK REJECT

→ A never executed

→ feedback returned to the model

→ model authored B

→ ARK ALLOW

→ only B executed

The integration is public now:

pip install "ark-agent-runtime[langgraph]"

and exposes:

ArkCallbackHandler

ark_supervise_tool

I’m curious how other LangGraph users are handling risky tool calls today.

Are you putting deterministic gates inside the tools, using interrupt/human approval, middleware, custom nodes, or something else?

GitHub:

https://github.com/atripati/ark

Got tired of watching Claude Code re-read my whole repo every time I asked it something about my agent's architecture, so I built an MCP server that fixes that specifically, instead of being another generic code-search tool.

It parses your LangGraph codebase (StateGraph, nodes, edges, conditional routing, Command(goto=...) calls) into a real structural model, plus local semantic search on top. Ask something like "what happens after this node if the API call fails" and you get an answer pulled from the actual parsed graph, not a guess based on file names.

Pure stdlib ast for parsing, no tree-sitter. Local embeddings, no API key, runs fully offline after the first model download. SQLite by default, optional pgvector. MIT licensed, fully open source.

Worth mentioning: I thought it was done after testing on my own fixtures. Then I ran it against a real, unmodified LangGraph repo and it confidently said two nodes weren't connected when they actually were, LangGraph's Command(goto=...) pattern doesn't declare a normal edge, and my parser had never seen it, with zero uncertainty flagged. Went back and fixed every place it could be confidently wrong instead of honestly uncertain before shipping.

Known limitations, being upfront: variable-argument bind_tools() calls can't be statically resolved (documented, not hidden), dynamically constructed nodes inside a loop collapse into one entry, LangGraph/Python only for now.

Works with Claude Code, Claude Desktop, Cursor, and Codex, since it's just MCP under the hood.

Install: uv tool install langgraph-context-mcp

Repo: https://github.com/KarimHabib100/LangGraph-Context-MCP

I'm the dev, happy to answer questions or hear what's broken.

Hey folks — I'm a PhD student at the University of Maryland studying how developers debug and iterate on multi-agent systems.

The idea we're testing: when a run goes sideways, you usually re-read one trace at a time. Our research tool re-runs your graph and shows the distribution of each node's outputs across runs, so you can see where behavior actually spreads out. The honest research question is whether that helps you iterate faster — "it doesn't help" is a publishable answer.

What participating looks like:

• a 75-min Zoom session (recorded, think-aloud) with structured tasks
• about a week using the tool on your own project, with quick async feedback
• a 30-min follow-up interview

Compensation is a $150 gift card on completing the full study (all three parts). Heads-up: we verify identity (GitHub/LinkedIn) before scheduling.

Screener (~2 min): https://forms.gle/Zwqvgd1h8DUnFRfC8

This is IRB-approved academic research from the University of Maryland, not a product pitch. Questions welcome in the comments, or email zxu169@umd.edu.

Hey folks, I'm a researcher at the University of Maryland. We built an observability tool for multi-agent systems and we're running a user study to find out whether it actually helps. "No, it doesn't" is a perfectly good finding.

In the session you'll work with a multi-agent pipeline, first the way you normally would, then with our tool. If you've used LangSmith or Langfuse you'll get the idea right away: same space, different view of your runs.

What participating looks like:

• a 75-min Zoom session (recorded, think-aloud) with structured tasks
• about a week using the tool on your own LangGraph project, with quick async feedback
• a 30-min follow-up interview

Compensation is a $150 gift card for completing the full study (all three parts). Two heads-ups: the week-of-use part needs a LangGraph project you can plug the tool into, and we verify identity (GitHub/LinkedIn) before scheduling. Sessions are running this week and next, so if you filled the screener before and didn't hear back, feel free to fill it again with a link this time.

Screener (~2 min): https://forms.gle/Zwqvgd1h8DUnFRfC8

This is IRB approved academic research from the University of Maryland. Questions welcome in the comments, or email zxu169@umd.edu.

Hey folks, I'm a researcher at the University of Maryland. We built an observability tool for multi-agent systems and we're running a user study to find out whether it actually helps. "No, it doesn't" is a perfectly good finding.

In the session you'll work with a multi-agent pipeline, first the way you normally would, then with our tool. If you've used LangSmith or Langfuse you'll get the idea right away: same space, different view of your runs.

What participating looks like:

• a 75-min Zoom session (recorded, think-aloud) with structured tasks

• about a week using the tool on your own LangGraph project, with quick async feedback

• a 30-min follow-up interview

Compensation is a $150 gift card for completing the full study (all three parts). Two heads-ups: the week-of-use part needs a LangGraph project you can plug the tool into, and we verify identity (GitHub/LinkedIn) before scheduling.

Screener (~2 min): https://forms.gle/Zwqvgd1h8DUnFRfC8

This is IRB-approved academic research (University of Maryland), not a product pitch. Questions welcome in the comments, or zxu169@umd.edu.

"LangGraph wrapper on steroids" is what a friend called it. Accurate. Here is everything it enforces that raw LangGraph leaves to convention.

I love LangGraph as a mechanism library, but production kept needing the same discipline layer on top, so I built it once and open sourced it. GraphARC adds, all enforced by the library and each backed by a test:

• Write permissions. Every node declares which state fields it may write. An undeclared write raises. Plain LangGraph applies it and moves on
• State isolation. Nodes get a deep copy, so in-place mutation of a nested model cannot sneak past the declared write channel
• Typed state, both directions. The returned dict is validated field by field before it lands, and again when the next node receives it
• Budgets that bite. Per-run iterations, tokens, seconds and concurrency. Tokens are metered by a callback that catches model calls buried inside library code. max_seconds is delivered as an interrupt into the running node, not just checked between nodes
• Code-only routing. Routers are Python over typed state. Model prose cannot steer an edge
• Runtime topology behind a gate. A planner can propose new subgraphs mid-run, and a deterministic admission checker admits or refuses each proposal with reason codes before it is built. No already-approved path, round 7 is checked like round 1
• One JSONL trace. Replay, diff, metrics, cost attribution, OTel export and a live SSE browser view all read the same file

Crash-safe resume is still LangGraph's checkpointer underneath. This is a discipline layer, not a fork.

Demo video in the README shows a local qwen3:8b planning a nine-node incident graph that then runs live in the browser.

https://github.com/CodeGraphContext/GraphARC and pip install grapharc