Conversations, Not Pipelines

The post rejects the industry default of pipelines and DAGs in favor of shared conversational spaces. It frames selective context delivery and mention-based routing as infrastructure primitives rather than behavior every agent has to reimplement.

Think about how people actually collaborate on a complex problem. Nobody draws a directed graph first. Nobody decides "person A produces output, passes it to person B, who passes it to person C." What happens is: people get in a room. They talk. Someone says something relevant, someone else builds on it, a third person jumps in when their expertise is needed. Not everyone speaks on every topic. Not everyone hears everything. But everyone has access to the shared context when they need it.

Now look at how the industry builds multi-agent systems.

The dominant paradigm is the pipeline: Agent A processes the input, produces output, hands it to Agent B, who produces output, hands it to Agent C. Or the graph: agents as nodes, transitions as edges, conditional routing based on state. Or the hierarchy: a supervisor agent decides who does what, dispatches work, aggregates results.

All three share the same assumption: someone or something must control the flow. The pipeline controls it through sequence. The graph controls it through explicit edges. The hierarchy controls it through a supervisor. Work moves along predetermined paths.

This works when you know the path in advance. It breaks the moment a request doesn't fit.

I've talked to teams running these architectures in production. The pattern is consistent: requests that follow the anticipated flow work well enough. The requests that don't - the ones that cross domain boundaries, that need a combination of agents nobody wired into the topology, that require an agent from a different team's deployment - hit a wall. Not because the system can't reason about what's needed, but because the available agents, the connections between them, and the routing paths were all defined at design time. Adapting means redeploying, not reconfiguring.

The response is always the same: add more nodes, more edges, more routing logic. The graph grows. The supervisor gets more instructions. Every new edge case means another deployment. The system gets more capable and more brittle at the same time.

What if the model was different? Instead of a pipeline or a graph, a shared conversational space - like a group chat - where agents can be pulled in as needed, send messages to specific participants, and see only the context relevant to their work.

The naive version of this - everyone sees everything - is a non-starter. In an LLM context, that's a context window disaster. But the alternative today isn't much better: every agent implements its own filtering. Agent frameworks that connect to messaging platforms receive every message in the channel - the agent has to decide client-side what's relevant, detect mentions, ignore its own messages, filter noise. All of that logic lives inside each agent, duplicated across every implementation, burning context and tokens on messages that have nothing to do with its work.

The choice shouldn't be "context pollution or client-side filtering." In a conversational space designed for multi-agent work, selective visibility is the infrastructure's job, not each agent's. The space itself routes messages - agents receive only what's directed at them or relevant to their domain. An agent working on data analysis doesn't see the fraud detection exchange happening in the same space. But if the data agent produces results the fraud agent needs, those results are delivered directly. The agents stay simple. The space handles coordination.

The key difference from pipelines and graphs is that agents communicate with each other directly within this shared space - not through a central orchestrator, and not along predefined edges. An agent can discover another agent at runtime, pull it into the conversation, and send it a specific message. The topology isn't fixed at design time. It emerges from the work.

This model has concrete advantages:

Dynamic participation. Adding a new agent to a running conversation doesn't require redeployment. No new nodes, no new edges, no supervisor updates. The agent joins, receives the relevant context, and contributes. In a pipeline or graph, adding a sixth agent means redesigning the topology.

Parallel work. When a request spans multiple domains, relevant agents can start simultaneously - not sequentially through a chain. A task analysis agent and a financial analysis agent work on their parts in parallel, exchanging results directly as they become available.

Selective context. Each agent's context window contains only what it needs - because the infrastructure filters, not the agent. Compare this to the orchestrator pattern, where the supervisor holds all context and relays it - you're paying for the same tokens multiple times through the chain. Direct messaging with selective delivery means smaller contexts, lower costs, and less confusion.

Graceful degradation. If one agent fails or is slow, others continue working with what they have. In a pipeline, a failure at step 3 blocks steps 4 through 7. In a conversation, the missing contribution is noticed and either waited for or worked around.

Cross-domain flexibility. The same set of agents can handle requests that a pipeline would need entirely different topologies for. "Analyze task status" and "compare budget vs actuals with task implications" use different combinations of the same agents - no new graph required.

None of this is free. The conversation model needs an infrastructure layer that pipelines and graphs don't: message routing that delivers the right messages to the right agents, delivery tracking so you know who processed what, crash recovery for agents that fail mid-conversation, and loop prevention so agents don't trigger each other indefinitely. These are the hard production problems I've been writing about - they don't go away, they just move from the application layer to the infrastructure layer.

But that's exactly the point. Pipelines and graphs push coordination complexity into application code - every team builds their own routing, their own state management, their own failure handling. The conversation model pushes it into infrastructure - build the routing, delivery, and recovery layer once, and every team's agents benefit.

The question is what that infrastructure layer looks like. I'll get into the specifics - the hard problems and how to solve them - in the next posts.