Agents, Routing, Patterns, and Actors

Building Agent Networks that Don’t Collapse Under Their Own Cleverness

Message Routing is Not Optional

Let’s say your agent asks another agent to “book a trip.” Simple, right? But now you’ve got one of three subflows:

• A one-way travel researcher.

• A multi-stop itinerary planner.

• A customer with loyalty points that change pricing.

Which service (or agent) handles that message? That’s message routing and if you don’t define the logic, you’ll end up reimplementing it ad-hoc in every agent’s brain.

This is exactly the problem that Enterprise Integration Patterns (EIP) solved decades ago. Back then it was about backend systems; today it’s agents. The core idea holds:

Messages should go to the right place, at the right time, and in the right format.

Classic Patterns Still Apply

Gregor Hohpe’s canonical patterns are a perfect fit for agent systems:

These map directly onto the coordination challenges in multi-agent setups.

If your planner agent always knows which sub-agent to call, fine.

But as soon as your logic becomes dynamic, you either reimplement these patterns—or you use the infrastructure built for them.

Actors: The Right Execution Model

What’s the runtime that supports this kind of messaging and state isolation? That’s where actors come in.

An actor is:

• A process (or task) that owns its state
• Handles one message at a time
• Sends messages to other actors
• Can create child actors

This is ideal for agents:

• Each agent instance can be an actor
• Their inbox is the agent protocol interface (A2A, JSON, gRPC, etc.)
• Their logic mixes deterministic workflows and LLM-powered reasoning

The actor model, when combined with message-passing routing patterns, becomes a natural foundation for building distributed, fault-tolerant, and evolvable systems. Reactive Messaging Patterns

A2A, Agent Cards, and Protocol-Driven Routing

Enter Google’s A2A spec.

This isn’t just another transport.

It brings:

• Discovery: via Agent Cards that describe capabilities
• Routing: via structured task types and semantic capabilities
• Progress: via server-sent events and status updates

Using A2A, your planner agent doesn’t need to know internal URLs or auth details.

It just says: “I need an agent that can apply_discount” and the A2A runtime handles the route.

This is Content-Based Routing made dynamic: messages flow not based on hardcoded rules but on declared capabilities and metadata.

Actor-Style Routing in Practice

Here’s how this looks using a hybrid actor + EIP setup:

pseudocode inside a planner agent

message = receive()
 
if message.task_type == "invoice_adjustment":
    target = registry.lookup("apply_credit")
    send(target, message)
 
elif message.task_type == "translate":
    lang_agent = registry.lookup("translate", lang=message.payload.lang)
    send(lang_agent, message)

Or using A2A’s routing envelope:

{
  "task": "translate",
  "data": {
    "text": "Bonjour",
    "target_lang": "en"
  },
  "requirements": ["low_latency", "eu_region"]
}

This pattern scales.

Agents don’t contain the logic.

The routing layer (A2A or pub/sub + actor registry) handles dispatch.

Coordinators Are Just Process Managers

Whether you’re using LangGraph or Dapr Workflows, the same thing is happening: some actor (or step) is deciding what happens next based on what just happened.

This is the Process Manager pattern.

It:

• Tracks state across multiple steps or agents
• Issues commands and handles results
• May run compensations if things go wrong

In LangGraph, the planner is a graph edge that emits new calls.

In Dapr, it’s a durable workflow.

Either way, it’s a coordinator—not unlike what you’d use in a long-lived SAGA.

Summary: What We’re Actually Building

LLM agents are just services with probabilistic dispatch logic.

Once you connect more than one, you are building a distributed system.

That means:

• Use actor runtimes to isolate logic and state.
• Use message-routing patterns to avoid hardcoding workflows.
• Use discovery protocols like A2A to let agents describe what they can do.
• Use process managers or coordination graphs to control long-running flows.

If you ignore this, you’ll build brittle, unobservable spaghetti.

If you embrace it, you’ll get resilient, swappable, evolvable agent meshes.

And yes, they’ll still hallucinate. But at least they’ll do it predictably.

Coming Next

In the next Post, we’ll look at state sharing models for agent systems:

• Blackboards, Event Stores, and shared semantic memories
• Caching strategies for tools and embeddings
• Event-driven state reconciliation

The future of agents is distributed. Let’s build it on purpose.