All views expressed here are my own and do not represent the views of my employer.
In my last post, I argued that the multi-agent ecosystem is missing a critical piece: a protocol for how agents reach agreement. MCP handles tools, A2A handles discovery, and nothing handles consensus. I proposed what the primitives of such a protocol might look like - weighted voting, three-phase resolution, trust degradation, human escalation as a first-class outcome.
But the consensus gap is really a symptom of a deeper architectural problem. The way we build multi-agent systems today - with a central orchestrator routing tasks through a predetermined workflow - works for simple use cases but starts to break down as these systems grow in complexity and ambition. And I think we're starting to see what the next model looks like.
This piece is about the architectural patterns I believe will define the next generation of agent systems. Not incremental improvements to the current approach. A different way of thinking about how intelligent agents coordinate, share context, and make collective decisions.
The orchestrator ceiling
Let me be specific about what's wrong with orchestrators, because the problems are subtle enough that you can run into them for months before realizing the architecture itself is the issue.
The first problem is brittleness. An orchestrator encodes a workflow: step one feeds step two, which feeds step three. That works when you know the workflow in advance. But the highest-value agent applications are the ones where the right sequence of actions depends on what the agents discover as they work. A fraud investigation agent finds a suspicious pattern that triggers a need for regulatory analysis, which surfaces a compliance gap that requires legal review. No one designed that workflow. It emerged from what the agents found. An orchestrator can't handle emergence because it's built to execute plans, not adapt to discoveries.
The second problem is context loss. In orchestrator-based systems, each agent receives a task, produces an output, and hands it back. The orchestrator passes a summary to the next agent. Every handoff loses nuance. By the time you're three agents deep, the fifth agent is working with a telephone-game version of the original insight. The agents aren't sharing a workspace - they're passing notes through a middleman.
The third problem is scaling physics. An orchestrator that manages five agents is manageable. An orchestrator that manages fifty agents across multiple domains is a distributed systems nightmare. It needs to understand every agent's capabilities, manage every handoff, handle every failure mode, and maintain state for every concurrent workflow. You've recreated a monolith - except this one makes autonomous decisions.
Three patterns replacing the orchestrator
Across the systems I'm studying and the architectures I'm advising on, three patterns keep emerging as alternatives to the orchestrator model. None of them are new ideas - they draw from decades of distributed systems research. What's new is that AI agents are finally capable enough to use them effectively.
Pattern 1: Shared workspace coordination
Instead of passing messages through a central coordinator, agents read from and write to a shared workspace - a common information space where observations, proposals, and results are visible to every agent with the appropriate access level.
This isn't a new concept. The AI research community explored shared workspaces under the name "blackboard systems" in the 1980s. The idea was sound but the agents weren't smart enough to use it effectively - they needed too much structure and couldn't reason about ambiguous information. Large language models change that equation entirely. An LLM-powered agent can observe unstructured information on a shared workspace, reason about its relevance, and contribute meaningfully without being told exactly what to look for.
The key design principle is that agents don't receive tasks - they observe the workspace and decide what to contribute based on their expertise. A risk analysis agent watching a shared workspace doesn't wait to be called. It monitors for proposals that fall within its domain and contributes its assessment when relevant. This is how human expert teams work in high-stakes environments: everyone sees the same information and speaks up when they have something to add.
The practical challenge is governance. When every agent can see and act on shared information, you need clear rules about who can modify what, how conflicts are resolved, and how the workspace is kept coherent. This is where the consensus protocol I described in my previous post becomes essential - it's the resolution layer on top of the shared workspace.
Pattern 2: Event-driven agent activation
The orchestrator model is inherently imperative: do this, then do that. Event-driven activation is reactive: agents subscribe to event streams and activate when they observe something relevant to their domain.
This maps naturally to how real-world processes work. A customer complaint doesn't trigger a predetermined workflow. It produces a stream of events - sentiment analysis, account lookup, similar case retrieval, policy check - and the relevant agents activate in whatever order makes sense for this specific situation. Some events trigger one agent. Some trigger five. Some trigger agents that produce new events that trigger other agents. The topology of agent interaction emerges from the data, not from a workflow definition.
The technical foundation for this already exists. Kafka, Redis Streams, and similar event infrastructure can serve as the backbone. The missing piece is the semantic layer: how agents understand which events are relevant to them, and how they express the results of their work as new events that others can consume. This is a solved problem in traditional event-driven architecture, but agent-native implementations are still early.
Pattern 3: Weighted collective decision-making
This is the pattern I explored in depth in my previous post on agent consensus, but it's worth restating in context: when multiple agents observe the same situation and form different conclusions, the system needs a structured way to reach a collective decision without defaulting to a single orchestrator's judgment.
The key insight is that agents aren't equal. A domain specialist with high confidence should carry more weight than a generalist with low confidence. And an agent with a strong track record of accurate assessments should carry more weight than one that's been frequently wrong. The decision protocol needs to account for domain authority, confidence, and demonstrated reliability - not just majority vote.
When these three patterns combine - shared workspace, event-driven activation, and weighted consensus - you get something qualitatively different from an orchestrator-based system. You get agents that observe, reason, and act collectively without anyone telling them the sequence. The coordination emerges from the architecture rather than being prescribed by a controller.
Why financial markets are the ideal proving ground
If I had to pick one domain where these architectural patterns will be validated first, it would be financial markets. Not because finance is the most important application - but because it has the right characteristics to stress-test multi-agent coordination.
The information is heterogeneous and fast-moving. A trading decision requires synthesizing fundamental analysis, technical indicators, sentiment data, news flow, macroeconomic context, and risk constraints. No single model or agent can do this well. It's a natural multi-agent problem where specialization matters.
The agents need to disagree productively. A bullish sentiment agent and a bearish technical analyst aren't broken - they're reflecting genuine market uncertainty. The system needs to weigh their views, not pick one. This is exactly the weighted consensus problem.
The feedback loop is immediate. Unlike domains where you wait months to know if a decision was right, markets give you feedback in hours or days. This makes it possible to build trust scores and outcome-based weight adjustments that actually converge to accuracy - the trust degradation mechanism I described in the consensus protocol.
The stakes create natural governance requirements. You can't deploy a trading system without risk controls, audit trails, and human escalation paths. These aren't afterthoughts - they're first-class design requirements that force the architecture to get governance right from the start.
There's already good work happening in this space. The TradingAgents framework from Tauric Research has gained significant attention - over 60,000 stars on GitHub - by decomposing trading into specialized agent roles: analysts, researchers, traders, risk managers, and portfolio managers. It mirrors how real trading firms organize human teams, and the results have been impressive enough to demonstrate that multi-agent coordination in finance is viable, not just theoretical.
But TradingAgents and similar frameworks still use an orchestrated workflow model - a graph with predetermined routing. The next evolution would apply the architectural patterns I've described: agents coordinating through a shared workspace rather than passing data through a pipeline, activating in response to market events rather than following a fixed sequence, and making collective decisions through weighted consensus rather than single-agent judgment.
What a next-generation trading system would look like
Imagine a system where a market data event - say, an unexpected earnings revision - lands on a shared workspace. A fundamentals agent observes the event and contributes an updated valuation assessment. A sentiment agent independently notices the social media reaction and adds its analysis. A technical agent identifies the resulting price pattern. None of these agents were "called" by an orchestrator. They activated because they observed something relevant to their domain.
Now a proposal emerges: the fundamentals agent suggests a position adjustment. The sentiment agent endorses with moderate confidence. The technical agent challenges - the price pattern suggests the move is already priced in. A risk agent flags the current portfolio exposure to this sector. These views are weighted by each agent's domain authority, their confidence in this specific situation, and their historical accuracy on similar calls.
The weighted consensus produces a decision - or escalates to a human if the collective confidence is below the threshold. Either way, the full reasoning chain is auditable: who proposed what, who endorsed or challenged it, with what weight, and why.
Compare this to the orchestrator model: analyst produces report → trader makes decision → risk management approves or rejects. The sequential model loses context at every handoff and doesn't capture the nuance of disagreement between specialists.
What I'm working on
As a personal research project, I've been exploring what happens when you actually implement these patterns rather than just write about them. The consensus protocol I outlined in my previous post was the first piece. Now I'm building a personal trading application that applies these architectural patterns to financial markets - a multi-agent system where agents coordinate through shared state, activate on market events, and make collective decisions through weighted consensus rather than orchestrated workflows.
To be clear - this is a personal trading app, not an institutional system. It's a way to pressure-test these ideas against real market data and see where the theory breaks down. I'll be sharing more about it soon, including the design decisions, the failure modes I'm hitting, and what I'm learning about making agent coordination work in practice rather than just in architecture diagrams.
The broader point isn't about trading specifically. It's about whether the architectural patterns I've described - shared workspaces, event-driven activation, weighted consensus - hold up when you implement them for real. Trading is a compelling test case because the feedback is fast and the stakes are concrete. But the same patterns should apply to any domain where multiple specialized agents need to coordinate autonomously: supply chain optimization, clinical decision support, fraud detection, enterprise operations.
The orchestrator model got us started with multi-agent systems. It won't get us to where these systems need to go. The intelligent enterprises of the future won't be built on rigid workflows with a single brain directing traffic. They'll be built on architectures where specialized agents coordinate fluidly, share context naturally, and make collective decisions that are smarter than any single agent could produce alone. That's the shift - from orchestrated intelligence to emergent intelligence. And the organizations that figure out how to build this way will have a structural advantage that's very difficult to replicate.
More to come.
All views expressed in this article are solely my own and do not represent or reflect the views, positions, or policies of my employer. This is independent thinking on open industry challenges, shared as a personal research interest. Not financial advice.