DEV Community: Tim Alam

Multi-Agent Mess: Why Complex AI Workflows Belong on an Event-Driven Layer

Tim Alam — Wed, 24 Jun 2026 07:58:09 +0000

If you’ve spent any time building multi-agent AI systems lately, you’ve probably hit a wall very hard.

It always starts with high hopes. You want an agent to plan, another to research, a third to write, and a fourth to critique.

To keep them from running wild, you look for structure. You find frameworks like LangGraph, and they make total sense on paper. You get nodes, cycles, persistent state, memory, and human-in-the-loop interventions. You map out the perfect state machine.

Then you deploy it, and the real-world performance metrics come back.

The Hidden Bottleneck: State vs. Delivery
Here is the quiet frustration nobody warns you about when building complex agentic graphs: Orchestration frameworks are great at defining logic, but they are heavy on the wire.

When an agent needs to loop back to a previous state, update a shared context, or stream an execution step to a frontend UI, a traditional framework has to manage all that state transitions in memory or force you to configure external databases and complex WebSockets yourself.

As soon as you add human-in-the-loop approvals or multi-agent parallel processing, your clean Python or TypeScript graph starts dragging.

The system becomes tightly coupled. Your agents spend half their time waiting for the central orchestrator to process the next state transition, pass the payload, and update the stream.

The Graph is Just a Series of Events
A few months ago, we started looking at this problem from a completely different angle.

We asked: What if the features that make tools like LangGraph great—state management, cyclical loops, memory, and branching logic—didn't live inside a rigid application framework?

What if they lived natively inside a high-speed, real-time communication layer?

When you break it down, every transition in an agentic graph is just an event.

"Agent A finished researching" is an event.

"Human rejected the draft" is an event.

"Loop back to step two" is a conditional event.

If your underlying architecture is a distributed pub/sub network that natively understands state, you don't need a massive framework to act as the traffic cop.

Enter DNotifier: Building Stateful Graphs on a Live Network
This realization is exactly why we expanded DNotifier. We didn’t just want to build a fast messaging tool; we wanted to build the native infrastructure for stateful, real-time AI workflows.

Instead of writing complex, heavy framework code to manage your agent loops, you build your nodes and edges directly on top of a distributed messaging layer.

Because DNotifier natively supports persistent state, memory tracking, and streaming, you get all the heavy-duty features of an agentic graph—loops, conditional routing, human-in-the-loop pauses—without the architectural bloat.

What This Changes for AI Developers
When your agentic graph lives on an event-driven distributed architecture, the entire development experience shifts:

Zero-Friction Streaming: You don’t have to write custom adapters to stream an agent's internal thought process to the user. The moment an agent publishes its state to a channel, the UI and the next agent receive it simultaneously.

True Decoupling: Want to swap out your "Evaluator" agent from GPT-4o to a local Llama model? You don’t have to rewrite your graph definition. You just point the new agent to subscribe to the evaluation channel.

Native Human-in-the-Loop: Pausing an execution path for human approval usually requires complex state-saving logic. With an event-driven architecture, the workflow simply pauses on a conditional subscription until a "Human_Approved" event is fired from your frontend dashboard.

The Shift from Orchestration to Choreography
Frameworks like LangGraph taught the industry a valuable lesson: complex AI needs structure, cycles, and memory. They proved that linear pipelines aren't enough for true AI intelligence.

But the next step isn't making our application frameworks heavier. It's making our infrastructure smarter.

By moving the graph logic out of the code and onto a distributed, real-time communication layer, you stop fighting framework limitations. You get the cyclical control, the robust state, and the deep memory your agents need—while keeping your application incredibly fast, modular, and human-scale.

The Takeaway: Don't build a rigid cage for your agents to live in. Build a fast, stateful network, and let them cooperate naturally.

Code contrast between a framework graph and an event-driven graph:

Here is how the architecture shifts when you move from a centralized orchestration framework to a event-driven communication layer.To illustrate a classic loop (Agent $\rightarrow$ Tool $\rightarrow$ Agent), here is the side-by-side comparison of Python workflows.

The Centralized Graph Approach:
LangGraphIn LangGraph, you define a strict, centralized state schema, explicitly hardcode nodes and conditional routing logic, and compile it into a singular runtime executable.

`from typing import TypedDict, List
from langgraph.graph import StateGraph, END

1. Define the rigid global state

class WorkflowState(TypedDict):
messages: List[str]
status: str

2. Define the explicit node logic

def planner_agent(state: WorkflowState):
print("Planner is thinking...")
# Process LLM logic
return {
"messages": state["messages"] + ["Planner: Let's run a web search."],
"status": "call_tool"
}

def tool_node(state: WorkflowState):
print("Executing tool...")
# Process Tool logic
return {
"messages": state["messages"] + ["Tool: Found 3 relevant articles."],
"status": "re_evaluate"
}

3. Define the routing controller logic

def router(state: WorkflowState):
if state["status"] == "call_tool":
return "tool"
return END

4. Construct and compile the centralized graph

workflow = StateGraph(WorkflowState)
workflow.add_node("planner", planner_agent)
workflow.add_node("tool", tool_node)

workflow.set_entry_point("planner")
workflow.add_conditional_edges("planner", router)
workflow.add_edge("tool", "planner") # Loop back to planner

app = workflow.compile()

To stream this to a frontend UI, you now need to set up

custom WebSocket streaming handlers around the `app.stream()` generator.`

The Event-Driven Choreography Approach: DNotifier
With DNotifier, there is no central "graph" object or traffic cop compiler. Your agents and tools are completely decoupled microservices or functions. They maintain state continuity by emitting events over a fast, real-time messaging fabric.

`from dnotifier import DNotifierClient

Initialize the real-time communication layer

dn = DNotifierClient(api_key="dn_live_secret_key")

1. Planner Agent listens for execution requests

@dn.subscribe("agent.planner.run")
def handle_planning(event):
state = event.payload # Current state travels seamlessly via the event
print("Planner is thinking...")

state["messages"].append("Planner: Let's run a web search.")

if needs_tool_validation(state):
    # Simply publish an event. Anyone listening (Tool, UI, Logs) catches it.
    dn.publish("agent.tool.execute", payload=state)
else:
    dn.publish("workflow.complete", payload=state)

2. Tool Node acts completely independently

@dn.subscribe("agent.tool.execute")
def handle_tool(event):
state = event.payload
print("Executing tool...")

state["messages"].append("Tool: Found 3 relevant articles.")

# Loop back naturally by publishing back to the planner channel
dn.publish("agent.planner.run", payload=state)`

Try DNotifier today and get free support from AI architects from DNotifier.

No More LangGraph — Build Your Own Agentic Graph

Tim Alam — Sat, 21 Mar 2026 16:16:42 +0000

There’s always a moment that comes up in almost every serious AI project.

To be honest, at first everything feels simple.

Like you wire up a model, add a tool or two, maybe introduce a planner.
It works. It even feels elegant.

Then the system grows!

You add another agent.
Then another.
Then something needs memory.
Then something needs to interrupt a workflow halfway through.

And suddenly, what started as a clean “agent flow” turns into something harder to reason about.

That’s usually when people reach for something like LangGraph.

And to be fair — it helps.

For a while, why LangGraph Feels Right in the Beginning

LangGraph gives you structure.

Nodes.
Edges.
State transitions.

It turns a messy set of interactions into something you can visualize.

Planner → Tool → Evaluator → Response

Nice. Predictable.

You feel like you’re finally in control of the system.

And if your use case is contained — say, a single workflow or a well-defined loop — it works pretty well.

But that’s also where the cracks start.

The Problem Isn’t the Graph

It took us some time to realize this.

The problem isn’t the idea of a graph.

The problem is assuming the graph should be predefined.

Because real systems don’t behave like diagrams.

They behave like environments.

Things happen out of order.
Signals come from outside the system.
Multiple decisions happen at the same time.

And suddenly your clean graph needs:

interrupts
parallel execution
external triggers
dynamic routing

At that point, you’re not really “running a graph” anymore.

You’re managing coordination.

Where It Starts to Break

We ran into this while building a fairly typical setup:

a planning agent
a retrieval layer
a response generator
some background processing

Initially, everything flowed through a defined sequence.

Then reality kicked in.

The UI needed live updates.
A monitoring process needed to inject signals.
Retries depended on external conditions.
Certain tasks needed to run in parallel.

We kept trying to extend the graph.

Adding conditions.
Adding branches.
Adding control logic.

Eventually, the graph became harder to reason about than the system itself.

That’s when we stepped back.

A Different Way to Think About It

Instead of asking:

“How do we define the perfect graph?”

We asked:

“What if there is no central graph at all?”

What if each part of the system just reacts to what’s happening?

Not in a predefined order.

But in real time.

From Graphs to Conversations

This is where the shift happens. Instead of:
Node A → Node B → Node C

You move toward:
Something happens → multiple agents react

Each component becomes independent.

A planner doesn’t “call” an executor it emits an event, an executor doesn’t wait its turn. It listens for relevant signals and acts.

A validator doesn’t sit at the end of a chain.

It observes everything continuously.

It starts to feel less like a graph…

and more like a conversation.

Building the Graph Without Defining It

This is essentially what we ended up doing with DNotifier.

Not replacing graphs.

Just removing the need to hardcode them.

Instead of orchestrating flows, we focused on communication.

Every component — whether it’s:

a client
a backend service
an AI agent
a background worker

…talks through the same real-time messaging layer.

Once that exists, something interesting happens.

The “graph” still exists.

But it’s no longer static.

It forms dynamically based on:

events
responses
context

You don’t define the edges.

You allow them to emerge.

What This Looks Like in Practice

Let’s take a simple example.

A user asks a question.

Instead of pushing it through a fixed pipeline:

Chat → Retrieval → Generation → Response

You get something like:

the input triggers a retrieval agent
the same input notifies a context agent
both feed into a response generator
a monitoring agent observes confidence levels
if needed, another agent steps in

All of this happens in parallel.

No central controller.

No strict ordering.

Just coordination.

Why This Scales Better

When your system is built around interaction instead of orchestration:

adding a new agent doesn’t break existing flows
you don’t need to redesign pipelines
components stay loosely coupled
debugging becomes simpler (you trace events, not execution trees)

Most importantly:

You don’t fight your architecture as your system grows.

The Subtle but Important Shift

LangGraph (and similar tools) are built around control.

You define what happens next.

This approach is built around awareness.

Each part of the system decides what to do based on what it sees.

It’s a small conceptual shift.

But it changes everything.

When You Still Want a Graph

To be clear — graphs aren’t bad.

They’re useful when:

workflows are predictable
execution paths are known
you want strict control

But once your system becomes:

real-time
distributed
multi-agent
interactive

Rigid graphs start getting in the way.

Final Thought

At some point, every growing system hits the same realization:

You can’t predict every path in advance, trying to encode all possible flows into a predefined graph becomes a losing battle.

It’s easier to let the system adapt. Build a strong communication layer, let components react in real time.

Let the structure emerge naturally.

That’s when your “agentic graph” stops being something you draw and starts being something your system is.