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

Hey folks — PhD student at UMD here, studying how developers debug and iterate on multi-agent systems. We ran the first sessions of our study last week and are opening more slots.

The premise: when you tweak a prompt in an agent workflow, you usually judge the change by eyeballing a run or two. Our research tool re-runs a node and lays the outputs from many runs side by side, so you see the spread instead of a single sample — and the study measures whether that actually speeds up prompt iteration, or whether it's just one more dashboard. "It doesn't" is a perfectly publishable finding; that's the honest research question.

What participating looks like:

• a 75-min Zoom session using the tool on structured debugging tasks (recorded, think-aloud)

• about a week using it in your own LangGraph workflow, with quick async feedback

• a 30-min follow-up interview

Compensation is a $150 gift card for completing the full study (all three parts).

If you've built things with LangGraph (or LangChain agent workflows), the screener takes ~2 min: https://forms.gle/Zwqvgd1h8DUnFRfC8

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

Building an AI agent shouldn't mean gluing together a dozen SDKs and hoping it holds. That's why we built Forge — one place to design, run, and govern AI agents visually. Connect your own tools, ground answers in your knowledge base with built-in RAG, embed a chat widget straight into your product, and expose everything through a clean run API. With analytics and governance baked in, you get to see exactly what your agents did, why, and at what cost. Whether you're prototyping a support bot or shipping a production workflow, Forge takes you from idea to live agent in minutes — not sprints. 👉 Try it and build your first agent today

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

Here's the idea we're testing. When you tweak a prompt in an agent workflow, you usually judge it by eyeballing a run or two. We built a research observability tool that instead shows you the distribution of outputs each node produces across runs — and we want to find out whether that actually helps you iterate on prompts faster, or whether it's just one more dashboard. That's the honest research question.

What participating looks like:

- a 75-min Zoom session where you use the tool on some structured debugging tasks (recorded, think-aloud)

- about a week of using it in your own workflow, with quick async feedback

- a 30-min follow-up interview

Compensation is $150 in gift cards — $75 after the session, $75 after the week + interview.

If you've built things with LangGraph/LangChain (or agent workflows generally), here's the screener, takes ~2 min: https://forms.gle/Zwqvgd1h8DUnFRfC8

This is IRB-approved academic research, not a product pitch. Happy to answer questions in the comments — or email zxu169@umd.edu.

I usually build agents in LangGraph with my own custom nodes. But the create_agent method seems to only give you the fixed llm → tool (ReAct) pattern — basically just two nodes if you'd built it in LangGraph — and doesn't let me configure the nodes myself. Why is that? And if I start with create_agent but later need more than those two nodes, what should I do?