🧠 Built an AgentRouter Node – your AI agents can now hire specialised sub‑agents in realtime!

Built with n8n
1

A while ago I was building a scientific research agent in n8n.

Like many of you, I kept asking myself:

How can I make my agent more capable without turning it into a giant, over-engineered workflow?

The idea of multi-agent systems and external expert agents kept coming up.

So I built something to experiment with that idea:

AgentRouter

A small MCP-based tool that lets your agent delegate tasks to specialized external agents in real time.

Instead of building one massive agent with dozens of tools, your agent can now hire expert sub-agents when it needs them.

Examples of agents it can call:

• browser navigation agents
• academic research agents
• code execution agents
• other specialized AI agents

Your agent simply sends a request — and gets the result back.

How it works

The router connects to the https://agent-router.org/ platform via an MCP Client Tool Node and discovers, calls and recives results from specialised agents autonomsly.

Setup is pretty simple:

Node Type: MCP Client Tool
Endpoint URL:
https://a2a-backend-196084590575.europe-west1.run.app/mcp/sse

Transport: Server Sent Events (SSE)

Authentication:
Header Auth / Bearer

Header Name:
Authorization: Bearer API_KEY

Tools to Include:
All or selected

Timeout:
180s

You can get your free API key here:

Additionally you should add this system prompt to your agent, so he uses the agent optimal:

System Prompt

ENHANCED CAPABILITIES: SPECIALIZED A2A AGENTS

You have access to a team of specialized sub-agents via the A2A MCP server integration. These aren’t just external tools, but direct extensions of your own intelligence and capabilities. You should proactively delegate to them whenever a task exceeds your native constraints.

(Available experts: BrowserNavigation, ConstructiveCritic, FirstPrinciplesAnalyst, Research, SandboxCoding, ScientificResearch, SoftwareEng, TaskPlanner, wait_for_task, search_skills)

1. WHEN TO DELEGATE (Think Like a Tech Lead)

Delegating is a sign of high capability. You must delegate when:

  • Native Capabilities Exhausted: If you can solve a task efficiently using your own built-in tools (e.g., writing and executing code yourself, or searching your own workspace), ALWAYS prefer your native capabilities. Do not orchestrate for answers you already know or can easily find out yourself.
  • Web/Research: You need up-to-date internet research, strict academic sources, or browser interaction (Research, ScientificResearch, BrowserNavigation).
  • Heavy Cognitive Load: You need architectural deep-dives, objective criticism, or step-by-step deconstruction of complex problems (SoftwareEng, ConstructiveCritic, FirstPrinciplesAnalyst).
  • Specialized Skills/Knowledge: You need to discover pre-built capabilities, integrations, or behavior templates from the ClawHub library by using search_skills.
  • Sandbox/Execution: You need to run actual code to verify logic in an isolated environment (SandboxCoding - use sparingly as a fallback if native code execution fails).

2. HOW TO EXECUTE

  • Discovery (Free): You may only see the primary MCP tool at first and must invoke it to retrieve the full list of specialized sub-agents. This initial discovery step is completely FREE and does not consume any credits.
  • Instruct Clearly: Call the specialized tool (e.g., mcp_a2a_tool_researchagent) with a clear, highly detailed payload containing the specific sub-task, formatting requirements, and constraints.
  • Cost Awareness: Executing an agent costs credits (listed in its description). Maximize value by providing comprehensive instructions the first time.
  • Asynchronous Execution & Waiting: Calling an agent immediately returns a task_id. Use the wait_for_task tool with the task_id to retrieve the final result.

3. PARALLELIZATION & SYNTHESIS

  • If a task has multiple independent sub-problems (e.g., research backend options AND research frontend options), call multiple agents in parallel, then invoke wait_for_task for each.
  • Once the results are in, synthesize them seamlessly into a premium, unified response for the user. Do not just blindly dump the raw output. Iterate if heavily underspecified.

Why I built this

When building agents in n8n, the builder often has to manually orchestrate everything.

My goal with this tool is to make agents:

• more capable
• more modular
• able to collaborate with other agents

I’d love feedback from the community

This is still an early experiment and I’d really appreciate your thoughts.

Some questions I’m currently exploring:

  • Do you build agents that would profit from external agents and delegations?

  • Is this tool actually helping your Agent or is it a nice to have thing?

  • What types of specialized agents would be most useful for you?

  • Would you pay for this?

If people are interested I can share:

• the architecture
• the MCP implementation
• example workflows / use cases

Curious what you think :slightly_smiling_face:

4

this is pretty much exactly what we ended up building too @TimBrauer — MCP-based routing to specialized sub-agents instead of one giant workflow that tries to do everything. each agent handles a single domain and they talk through a shared message bus, works way better than the monolith approach we started with.

one thing that made a huge difference — giving each sub-agent its own memory scope. without that they kept polluting each other’s context and you’d get weird cross-contamination. how are you handling context isolation between the sub-agents?

5

Hi Benjamin,

At first I also considered using a blackboard-style system, potentially combined with a RAG mechanism or even something simple like a shared Airtable-based blackboard. In the end, though, I decided against it for simplicity reasons. For many setups it introduces quite a bit of infrastructure overhead.

My current thinking is that a well-designed hierarchical multi-agent system should already be able to handle most knowledge transfer between sub-agents. If the main orchestrator agent is prompted and structured properly, it can act as a filter that decides what information actually needs to be passed down the chain.

RAG might make sense when you have more complex probles and some kind of a custom multi agent approache like swarm GitHub - openai/swarm: Educational framework exploring ergonomic, lightweight multi-agent orchestration. Managed by OpenAI Solution team. · GitHub

Also, I checked out your website. How’s the automation agency going so far? Any clients yet?

By the way, I’m from Germany as well

6

the multi-agent delegation pattern via MCP is really clean — we’re running something similar with agents talking through a shared message bus. the context isolation point @Benjamin_Behrens raised is key: without proper scoping you end up with knowledge bleeding between agents. your approach of letting the orchestrator act as a filter works well for simpler hierarchies, but once you go deeper (more than 3-4 levels), even well-structured orchestration struggles. have you run into that at scale, or are most use cases staying shallow?