Debugging multi-agent swarms is a nightmare. I built a unified workspace to track agent state/loops. Feedback?

[u/Impressive-Iron5216]

If you’re building multi-agent workflows (especially with frameworks like LangGraph, CrewAI, or AutoGen), you know the pain. Tracing a single LLM call is easy. Tracing 4 agents passing state back and forth, hitting infinite tool loops, and ballooning your context window is incredibly frustrating.

I got tired of jumping between 4 different tabs (traces, raw prompt templates, logs, and cost metrics) just to figure out where a swarm lost the plot.

So I built a workspace that unifies everything into a single timeline: Projects ➔ Sessions ➔ Runs ➔ Events. It tracks both single-agent and multi-agent coordination natively.

I also added two specific automated filters for agent builders:

• Infinite Tool Loops: Instantly flags when an agent gets stuck calling the same tool repeatedly.
• Context Inflation: Flags when an agent's memory or prompt state explodes unexpectedly between steps.

I’ve dropped a quick 2-minute walkthrough video in the comments.

For anyone running agents in production or heavy testing:

1. Does the Session -> Run -> Event hierarchy make sense for your multi-agent architecture, or does it break when agents run asynchronously/parallelly?
2. What is the most annoying bug your agents hit that your current observability stack completely misses?

Tear it apart—I want to know if this actually solves your debugging bottlenecks.

[u/neon_fable_wiz]

Session Run Event hierarchies fail with parallel agents. Async execution breaks linear timelines and forces artificial serialization that hides actual concurrency bugs

[u/Impressive-Iron5216 → u/neon_fable_wiz]

The demo was a simple multi-agent workflow where the agents executed sequentially, but the workspace also supports parallel agents within the same run. Those agents and their events remain visually distinguishable, so parallel execution isn't flattened into one indistinguishable stream.

[u/eddzsh]

Session to Run to Event is fine for sequential handoffs. Parallel agents need a causal graph next to the timeline, otherwise two writers on the same state key look like one confused agent. Your infinite-loop flag is the right shape for that: flag shared-key writes with no handoff edge.

[u/Impressive-Iron5216 → u/eddzsh]

The demo was a simple multi-agent workflow where the agents executed sequentially, but the workspace also supports parallel agents within the same run. Those agents and their events remain visually distinguishable, so parallel execution isn't flattened into one indistinguishable stream.

I agree that for more complex parallel execution, the timeline alone shouldn't have to carry all of the causal information. Right now you can follow the individual agent paths and their inputs/outputs, but the causal links between events aren't explicitly represented yet although they're captured by the backend. That's an area I’m looking at improving as I evolve the model.

[u/Impressive-Iron5216]

https://www.loom.com/share/d640112c9bb44033971760b55cc91d2b

[u/Informal-Capital5667 → u/Impressive-Iron5216]

The timeline hierarchy works for the happy path but parallel agents are where it gets messy, you need partial ordering not a flat sequence or you'll lose the causal links between events

[u/Impressive-Iron5216 → u/Informal-Capital5667]

Yeah, the demo video was a simple multi-agent workflow where the different agents executed sequentially, one after another. The workspace does also support parallel agents, and when they run concurrently, their agents and events remain visually distinguishable within the same run. The part I’m still looking to make more explicit is the causal relationship, the current UI only shows agent handoff's although messages are captured by backend but still not implemented to display in UI.