The Routing Problem Nobody Talks About
In early 2026, I handed a single AI pipeline a task that required research, scoring, and outreach writing. It completed step one. Then it stalled. Not because the reasoning was wrong, but because nothing told it what to do with the output. The system had no concept of "done with this, pass it forward." It was a capable component with no address to send its work.
That's the routing problem. Single-task AI components are good at their one job. They fail the moment a workflow requires a decision about what happens next. You end up babysitting the handoffs yourself, which defeats the purpose of building the thing in the first place.
The fix isn't a smarter model. It's a different architecture.
Why Single Nodes Break Under Coordination Load
A single reasoning node handling research, classification, and writing simultaneously isn't a multi-step pipeline. It's a monolith. Monoliths fail in predictable ways: they can't be tested in isolation, they can't be retried at the step that failed, and they can't run tasks in parallel when the tasks don't depend on each other.
I made this mistake myself. Our first Autonomous SDR used a flat three-component architecture: research, scoring, and writing all reported to a single orchestrator. It worked on five leads. At fifty, the scoring module sat idle waiting on research that had nothing to do with scoring. The two processes were coupled when they didn't need to be. Splitting them into discrete components with explicit handoff contracts between them cut processing time and made each module independently testable. That's why every pipeline we build now uses explicit inter-component schemas. Implicit data passing doesn't hold up once volume increases.
McKinsey's analysis of AI in enterprise operations notes that organizations are transitioning from isolated AI implementations to coordinated multi-component systems that can autonomously manage workflows and make decisions across enterprise tools (McKinsey Digital, 2024). The transition isn't about capability. It's about coordination.
Designing the Hierarchy Before Writing a Single Node
The architecture decision that matters most happens before you open n8n or write a single line of configuration. You need a role map.
A functional multi-component AI system has three layers:
- Orchestrator: Receives the top-level task, breaks it into subtasks, routes each subtask to the right specialist, and assembles the final output. This layer holds no domain knowledge. It only knows what exists and what each component accepts.
- Specialists: Each handles one domain. A research module pulls and structures data. A classification module scores or categorizes. A writing module generates copy. None of these know about each other. They only know their input schema and their output schema.
- Memory and state: A shared context store that any component can read from and write to. Without this, you're passing state through function arguments and losing it the moment a step fails.
The orchestrator is the hardest part to get right. Most builders make it too smart. An orchestrator that tries to reason about domain problems becomes a bottleneck. Keep it dumb and fast: receive task, identify type, route to specialist, collect result, continue.
Inter-Component Contracts: The Part That Actually Matters
Here's what separates a system that runs once from one that runs reliably at volume: every handoff between components must have an explicit contract. A contract defines what the sending component guarantees to produce and what the receiving component requires to function.
In practice, this means typed output schemas at every boundary. If your research module returns a JSON object, the classification module should validate that object before processing it. If validation fails, the system routes to an error handler, not to a silent failure that corrupts downstream output.
We use n8n's Set and Code nodes to enforce these boundaries. The Set node normalizes output into a known shape before it leaves a specialist. The receiving specialist's first step is always a schema check. This sounds like overhead. It isn't. It's the difference between a pipeline you can debug and one you can only restart.
If you're building on n8n and haven't read through the reliability and observability patterns we've documented, the n8n agent workflow reliability playbook covers the specific node configurations that make these contracts hold under failure conditions.
The Recursive Moment: Using the System to Build Itself
Once the architecture was stable, I ran an experiment. I gave the orchestrator a task: plan and configure the launch sequence for a new pipeline variant. Research the requirements, draft the configuration spec, score the spec against our quality criteria, and output a deployment-ready document.
The system completed it without a single manual handoff.
This is what ForgeWorkflows calls agentic logic: the system doesn't wait for a human to route each step. The orchestrator holds the task graph, the specialists execute their scoped work, and the output assembles itself. The human role shifts from traffic controller to architect. You design the system once. Then you let it run.
That said, this only works when the task is well-defined. Open-ended creative tasks, anything requiring judgment about organizational politics, or work that depends on context the system can't access will still fail. The architecture doesn't solve ambiguity. It solves coordination. Those are different problems.
What We'd Do Differently
Build the error routing before the happy path. Every time we've skipped this, we've regretted it within the first real-world run. The happy path is easy. The failure modes are where the architecture either holds or collapses. Design your error handlers first, then build the success flow around them.
Version your inter-component schemas from day one. When a specialist's output format changes, every downstream component that depends on it breaks silently if you haven't versioned the contract. We now treat schema changes the same way we treat API version bumps: increment the version, maintain backward compatibility for one cycle, then deprecate. This adds friction early and removes far more friction later.
Don't start with more than three specialists. The instinct when designing a multi-component system is to decompose everything. Resist it. Start with the minimum number of specialists that covers your core task. Add components only when a specific bottleneck or failure mode demands it. A system with two well-defined specialists and clean contracts outperforms a system with six specialists and implicit data passing. We've built both. The simpler one ships faster and breaks less.
