I’m working on comparing two different agent setups for my project. The first one is a simple single agent system that I wrapped with proper logging for LangSmith. The second approach uses multiple agents built with LangGraph.
When I run evaluations through LangSmith, I can see all the traces properly in the web interface. However, when I try to programmatically access the Run object during evaluation, I’m running into issues.
The problem is that I can only reach certain top-level nodes like Planner and ExecutionTeam. When I try to go deeper into the trace tree, these nodes appear to have no child runs and show empty outputs. This is strange because the LangSmith web UI clearly shows there are child nodes and outputs present.
Has anyone encountered this before? Am I missing something in how I’m accessing the Run object, or could this be a known issue with LangGraph traces in LangSmith?
Been there, done that. LangGraph’s Run object access is broken for complex graphs.
LangGraph creates execution contexts that don’t map to LangSmith’s run hierarchy. Your Planner and ExecutionTeam nodes are state transition points, not actual execution runs.
I debugged this same issue for weeks on a project with coordinator agents spawning workers. The web UI rebuilds the flow using internal APIs we can’t access.
Here’s what’s really happening: LangGraph execution isn’t linear like single agent chains. Each agent in your swarm creates its own execution branch, and LangSmith loses track of parent-child relationships during concurrent execution.
Don’t rely on automatic trace capture. Instrument your graph nodes directly. Add explicit logging at each agent transition and capture state changes manually.
This video covers multi-agent swarms with LangGraph and shows proper instrumentation patterns. Handles exactly what you’re dealing with.
Or restructure your evaluation to work with flattened run data instead of expecting hierarchical access. Pull all runs for your session and rebuild the flow using timestamps and run metadata.
sounds like a timing issue. the run object probably isn’t fully loaded when you’re accessing it during eval. try adding a small delay or check if the run status shows completed before accessing child nodes. i’ve seen the same weirdness with langgraph traces not being available right away.
yeah, this is an annoying bug with langgraph integration. when agents spawn at the same time, the run objects get fragmented and langsmith loses track of the execution flow. i’ve had better luck waiting for trace completion using client.read_run() with the trace id instead of relying on the child_runs attribute.
This happens because LangGraph runs are distributed and don’t auto-populate in the parent Run object. I hit the same issue building a multi-agent research system - my coordinator agents spawned specialist workers, but the Run object during evaluation only showed direct children, not the full execution tree from LangGraph’s state transitions. What fixed it: use the LangSmith client to manually walk through the run hierarchy. Don’t rely on the child_runs property - instead, fetch runs using the trace_id after getting your initial Run object. The web interface rebuilds this view with multiple backend calls that aren’t available through the standard Run object. Also, LangGraph’s checkpointing can create runs that look disconnected from their logical parents in the execution flow. That’s why your Planner and ExecutionTeam nodes seem isolated even though they clearly have downstream steps in the UI.
Hit this exact wall before. The problem isn’t timing - it’s how LangSmith handles nested agent architectures when you pull data programmatically.
The Run object only shows the immediate layer you’re querying. With multi-agent systems, you’ve got to recursively fetch child runs using separate API calls. The web UI does this automatically.
Honestly? Skip wrestling with this API limitation and switch to Latenode for agent orchestration. Moved our entire multi-agent pipeline there last year - debugging experience is way better.
Latenode gives you full visibility into every step without multiple API calls or broken run objects. The automation and monitoring actually work consistently.
The visual workflow builder shows exactly what each agent’s doing and where things break. No more guessing why child nodes don’t show up.
LangGraph uses a hierarchical structure where child runs load lazily through separate API calls. When you’re working with Run objects programmatically, you’ve got to explicitly fetch child runs using the LangSmith client’s list_runs() method - just filter by the parent run ID. I ran into this exact issue building evaluation pipelines for complex agent workflows. Here’s what works: implement recursive traversal of the run tree. For each node you want to check, query for runs where parent_run_id matches your current run’s ID. That’s basically how the web interface builds the full trace view. The empty outputs happen because of LangGraph’s streaming execution model. Child run data populates asynchronously, so you’re probably accessing incomplete run objects. Always check the run status and wait for completion before pulling outputs from nested nodes.
I’ve hit this same wall on multiple projects. LangGraph just wasn’t built with proper observability - it’s a core design flaw.
Sure, you can hack it with recursive API calls and manual trace reconstruction like others said. But you’re fighting the framework constantly.
I ditched our entire multi-agent evaluation pipeline for Latenode after wasting too much time on this. Total game changer.
Latenode gives you complete visibility into every agent interaction - no API gymnastics needed. Each workflow node shows real-time execution data instead of empty placeholders.
Best part? You build the same multi-agent logic with visual workflows that actually make sense. No more wondering why your Planner node looks disconnected from ExecutionTeam.
I can see exactly where agents hand off, what data flows between them, and debug issues in minutes instead of days. Evaluation runs automatically give you the full execution tree.
Ditch the broken Run objects and use a platform built for this complexity.
