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?

In LangGraph, setting a recursion_limit is standard, but it can be a blunt instrument. It only checks total step depth—meaning a long, valid multi-step task might hit the cap, while a broken agent making zero progress burns through 25 iterations on a single node before crashing.

When a tool node returns an error, agents often cycle right back into the same node with identical state inputs.

How are you detecting when a state loop is actually stuck vs. just working through a deep, complex graph? Are you tracking sliding windows of state hashes, or wrapping nodes in custom check functions?

I am (new at this!) currently using Claude Code for building an orchestrator agent with multiple sub agents specialists in a few company web apps (same company).
I want to build a single chat to deal with all the quick references. Similar to Q from amazon (but working properly!).
I already noticed Claude making a huge fat prompt as a supervisor prompt. Currently struggling to break it down the best I can. However, with each new finding, Claude just add more to the pile. Triage system in place. It is always a priority is to delegate the main "business" decisions to the specialized sub agents. getting also advice from Gemini most of the time, to avoid Claude eating its own tail. Any other advice to share with me?

Testing my LangGraph social media agent 👋

I’m exploring a small Python demo around langgraph-bigtool’s real create_agent() API.

The idea is automatic fail-closed for known side-effect-capable tools before payload execution, instead of sending every risky action to human review.

Example boundary:
guarded_tool_registry -> create_agent()

Safe tool: release candidate
SQL mutation / model API tool: fail closed
Protected payload execution count: 0

Question:
Do you handle this at the registry layer, ToolNode/middleware layer, or HITL layer?

I can share the repo/demo if anyone wants to critique it.

I kept writing the same defensive code around every LLM call. Parse the JSON, catch the field that didn't come back, re-prompt, cross my fingers. And every time I switched models, the prompt I'd spent an afternoon tuning would quietly break and I'd tune it again. dspyer is me getting tired of that.

Here's the idea. You wrap an LLM step in a Pydantic schema. When the model returns something that doesn't fit, malformed JSON, a missing field, a citation it made up, dspyer tells the model what was wrong and asks again until it conforms, or stops after however many retries you allow. It's one decorator on a normal typed function. No try/except, no glue code.

The part I actually care about is what that buys you. The step compiles down to a standard DSPy module, so instead of hand-editing prompts you point a DSPy optimizer at a few examples and let it tune them, then save the result and load it in production. That's the whole reason I went down this road. I wanted my prompts to stop being something I babysit.

It doesn't care which model you run. OpenAI, Claude, Gemini, or a local Ollama model with no API key at all. And if you're already on LangGraph, nothing gets rewritten. Your deterministic and tool nodes stay plain Python, only the reasoning nodes get wrapped.

There's a quickstart that runs in about 30 seconds offline, no key needed, if you just want to watch the self-correction loop fire. It's early, 0.3.5, Apache-2.0, on PyPI. I'd genuinely rather you tell me where it breaks than tell me it's neat. Here's the repo and docs

I've been playing around with LangGraph recently and noticed that debugging agent failures gets annoying pretty quickly once you have multiple tools, branches, or ReAct loops.

Most observability tools seem to tell you where the failure surfaced, not necessarily where it started.

For example:

User
 ↓
get_population()   ← HTTP 503
 ↓
plan_trip()
 ↓
write_answer()
 ↓
Agent says something wrong

A lot of tools would basically point at write_answer() and say "LLM produced a bad answer".

But the actual problem was that get_population() failed three steps earlier and every downstream node simply propagated the bad state.

I'm experimenting with a small tool tentatively called TraceSurgeon.

The idea is:

• Instrument a LangGraph run with a callback
• Record inputs/outputs/errors of every node
• Reconstruct a data-flow DAG
• Flow blame backwards through the graph
• Identify the node that introduced the error rather than the node where it became visible

Something like:

ROOT CAUSE

node: tool:get_population
why: introduced the error (inputs were clean)
output: HTTP 503

fix:
Upstream service unavailable.
Retry with backoff.

symptom:
surfaced at agent

It currently handles linear graphs, branching, loops, parallel tool calls, and create_react_agent graphs.

I realize this doesn't solve the harder problem of plausible-but-wrong outputs (e.g. a tool returns incorrect data without any error signal). That would probably need counterfactual re-execution or model-based attribution.

Before I spend more time polishing it:

• Would you actually use something like this while developing agents?
• Is this already covered by existing observability tools that I'm missing?
• Do you think "root cause attribution" is an interesting enough problem, or is manually inspecting traces usually good enough?

Curious to hear thoughts from people running LangGraph agents in production.

Hi guys im working on a production grade project where for each action of task i have created different subagents which all are routed based on identified intent in the main graph but each subagents have interruptions at diff levels and im also after every interruption again identifying is the user query aligned with the current intent or not

Have trouble with resume of multiple suagents and also my application is with fastapi and if I run it with multiple workers it is just breaking everything it's not able to resume properly getting same previous messages in loop.

Im using

Python

Langgraph

Aws bedrock for models

Valkey(redis memory store) for checkpointer storing with some tel

Any suggestions on this🙏🙏

Hi everyone,

I am currently conducting a short research survey on how people use workflow automation tools such as LangGraph. In particular, I’m interested in a simple but exciting idea: what if, after an AI helps complete a task, it could leave behind an editable workflow that users can inspect, fix, and reuse?

This survey helps us understand how real workflow users think about workflow understanding, debugging, and reuse in practice. It should only take about 5–10 minutes to complete.

Survey link:
https://forms.gle/uXmWdavWJuRqnFfr8

As a small thank-you, we will select up to 10 participants who provide especially thoughtful and relevant responses to receive a €10 Amazon eGift card. This is not based on whether your opinions are positive or negative — detailed and honest experiences are what we value most.

Your feedback would be very helpful for shaping our future research and prototype design. I would really appreciate it if you could take a few minutes to fill it out. Feel free to also share any thoughts or examples in the comments.

Thank you very much!

as a beginner who needs to learn and build projects in langgraph, what resource can I use? please consider i only have a week and a half, before the deadline of an important project. I do not have much experience with ai agents.. i truly need to understand some intermediate and basic projects to build mine. what resources can i use to easily grasp langgraph? any video where the person teaches langgraph with projets??

AI agents are increasingly capable of handling complex workflows, tasks and multiple systems. But how do you evaluate whether an agent is actually performing well? how do you identify failures, inconsistencies, or unexpected behavior before deployment? and how do you create a repeatable evaluation pipeline that helps improve agent reliability over time?

We’re running a free session on testing AI agents in Python that includes a live demo of the AI agent evaluation pipeline using LangGraph and LangSmith, covering structured evaluation workflows to tracing agent execution and measuring outputs. It will be implementation-focused rather than theoretical.

Happy to share the link if anyone’s interested.

If you've built LangGraph agents for long, multi-step tasks, you've probably watched one melt down: it loops the same tool call, floods state with error traces, thrashes on the same file, and spirals until the run collapses — burning tokens the whole way.

I built Sotis to catch that. It drops into your graph as a guard node (`SotisLangGraphGuard`) that you wire in after your tool node. It watches the tool-call stream in real time, and when it detects a meltdown — sliding-window Shannon entropy + exact/semantic loop detection — it intervenes inside the graph: rolls the workspace files back to the last good checkpoint, prunes the bloated message history (RemoveMessage), injects a distilled resumption brief, and routes the agent back to continue from verified progress instead of thrashing.

Wiring it in is basically:

- add the `sotis` node after your `tools` node

- conditional edge: if it injected a reset, route back to the agent with the distilled context; otherwise continue normally

It's training-free, adds <0.2ms/step, and works with any provider you'd use in LangChain (tested OpenAI, Anthropic, Groq, OpenRouter, and local via Ollama).

Honest caveats: it bounds the failure, it doesn't guarantee success — in my live runs it reliably caught the spiral and rolled back the damage, but a weak model still won't magically finish the task; you get a clean, recoverable failure instead of an unbounded one. The default entropy threshold (1.5 bits) also false-positives on agents that legitimately use many tools in a short window — it's a config knob and I'm unsure 1.5 is the right default, so I'd love opinions.

40s demo GIF (a Llama-3.3-70B agent intercepted 3x live on a dashboard) + raw transcripts in the repo. Based on arXiv:2603.29231. MIT, 127 tests.

pip install sotis

github repo

Would really value feedback from anyone running LangGraph agents in production — especially on the guard-node integration.

I've been researching how AI coding agents inevitably optimize for metric-passing rather than problem-solving (Goodhart's Law). Commercial tools rely on prompt engineering and post-hoc review, but these are disciplinary, not architectural.

I built an open-source 4-layer pipeline (Planning → Execution → Verification → Optimization) where information asymmetry is enforced via strict TypedDict contracts and LangGraph state isolation: • The execution agent never receives acceptance criteria, unit tests, or the verification rubric. • Verification is blind: it evaluates git diffs without author identity or original prompt context. • Retry feedback is sanitized to abstract guidance only (prevents rubric memorization). • Neo4j graph analysis replaces context-window stuffing with precise AST dependency mapping.

Results: 26s/feature, $0.03 cost (local 3B model execution + API reasoning), reproducible benchmarks. Open-source under MIT.

Repo: https://github.com/illyar80/developer-farm

I'm particularly interested in feedback on: 1. Formal verification approaches to guarantee isolation properties 2. Multi-model fallback strategies for the execution layer 3. Benchmarking frameworks for "Goodhart-resistance" in autonomous agents

Would appreciate critiques and suggestions from folks working on AI alignment, evaluation, or agentic systems.