A lot of AI agent pilots never reach production, and the cause is usually the architecture rather than the technology. At the centre of many failed pilots is the same overlooked question: when a system has several AI agents, what decides which one handles which input, and what happens when it gets that wrong?

The answer is routing. It sounds like plumbing, and in a regulated firm it’s the difference between an AI deployment that can be audited and trusted, and one that can’t.

What is AI agent routing, and why does it matter for your firm

Routing decides which agent in a multi-agent system handles a given input at each step of a workflow. With a single agent the question never comes up. As soon as a system has more than one AI component (a client query classifier, a document drafter, a compliance checker, a data retrieval agent), something has to co-ordinate them.

That something is the router. In older automation, routing was rigid category matching: if the input contained the word “complaint”, it went to the complaints handler. Modern routers built on large language models read intent, tone and context to make the choice, which is more flexible.

It’s also harder to govern, and that matters directly to a financial advice firm operating under Consumer Duty and SM&CR.

What goes wrong when routing fails

When routing fails, errors compound rather than staying as single mistakes. A query that should go to a compliance-checking agent but reaches a response-drafting agent instead produces output that has never been checked against your obligations. That output can reach a client, or land in a file, before anyone notices.

The risk is structural, not only operational. If a firm can’t show that its AI workflows send inputs to the right review steps, it can’t show oversight, and oversight is what the FCA and the Financial Policy Committee are now explicitly looking for.[1]

The joint statement from the FCA and Bank of England in early 2026 said that frontier AI models now exceed baseline cyber resilience capabilities, moving AI governance from internal best practice to a formal regulatory obligation for UK financial services firms.[1] The statement wasn’t mainly about chatbots. It was about firms that have put AI into operational workflows without being able to account for how those systems make decisions.

Routing is one of the places where that accountability either exists or doesn’t.

A firm that can’t explain which agent handled a given input, and why, can’t demonstrate the oversight regulators are now looking for.

The three routing patterns you will encounter

There are three main routing patterns, and each carries different governance implications.

  • Single-agent routing sends every input to one agent. It’s simple and auditable, but limited, and suits narrow, well-defined tasks whose scope is unlikely to change.
  • Multi-agent parallel routing sends an input to several agents at once, then combines the outputs. It’s faster but harder to audit: if two agents disagree, the system needs a defined rule for settling it, or a human does.
  • Hierarchical routing uses a co-ordinating agent (often called an orchestrator) to hand inputs to specialist sub-agents in turn, based on what each step produces. It’s the most capable pattern and the hardest to govern. The orchestrator’s decision logic needs to be documented, testable and reviewable, because it effectively decides the whole downstream workflow.

For regulated tasks such as suitability checking, client communication and AML screening, hierarchical routing needs the human review step built into the routing logic itself, not bolted on at the end. Any routing decision that lets regulated output skip human review is a governance gap, not an efficiency gain.

What the EU AI Act adds to the picture

The EU AI Act treats routing logic as part of a high-risk system, so it falls under the Act’s obligations. The Act classes AI systems used in financial services, including those involved in creditworthiness assessment and client suitability, as high-risk. That brings specific obligations: documented risk management, data governance controls, transparency to the people affected, and human oversight that works in practice, not only on paper.

For a multi-agent system, that means the routing logic itself is open to scrutiny. If the system sends a suitability-related query down an automated path with no human checkpoint, that isn’t compliant architecture under the Act’s high-risk requirements. The orchestrator’s logic is part of the system’s risk profile, not separate from it.

Firms within scope of the Act, including those serving EU clients, should treat the routing layer as a regulated component, document it as one, and test it as part of ongoing risk management.

Why most pilots stall before any of this is addressed

Pilots tend to stall because nobody designed the routing, and the products bought often can’t support it anyway. Gartner’s term “agent-washing” describes the second part: many vendor products marketed as AI agents are rebranded older automation rather than real agent architectures. A firm that buys an “AI agent” platform and then finds it has no real routing capability, no audit trail of which agent handled what, and no configurable human oversight hasn’t deployed a multi-agent system. It has deployed a slightly more expensive workflow tool with a bigger marketing budget.

Checking a vendor’s routing capability, audit logging and human oversight settings belongs in the procurement conversation, not as a technical afterthought. The questions to ask in an AI demo cover how to test those claims live.

What to do if your firm is building or evaluating a multi-agent system

Map the inputs

List every type of input the system will receive, and for each one, decide which agent should handle it and why. If you can’t answer that clearly, you don’t have a routing design yet. You have a system where routing gets decided implicitly, which means you can’t audit it.

Document the routing logic explicitly

For hierarchical systems, write down what the orchestrator decides and on what basis. It doesn’t need to be formal engineering documentation at the start. It needs to be honest enough that you could explain it to a regulator, or to the senior manager responsible under SM&CR.

Build the human review step into the routing, not onto the end

Every regulated output (a draft suitability letter, a compliance flag, a client communication) should pass through a defined human review step before it leaves the system. If the current design treats that review as optional, or as something done after everything else, move it inside the routing logic.

Test with adversarial inputs

Send inputs that are ambiguous, misleading or at the edges. Does the system route them correctly? Does it fail quietly or visibly? A routing failure you can’t detect is more dangerous than one that shows itself.

Assess your vendor’s routing transparency

Ask the vendor to show you the routing logic and an audit trail of which agent handled which input. If they can’t, that’s a governance gap you’re taking on, not them.

How this maps to your AI integration decision

For most advice firms the answer is Level 2, integration, not a custom build. The question I’m asked most often is “do we need to build this ourselves, or can we buy it?” You don’t need custom engineering to get a governed multi-agent workflow. You need existing orchestration tools (n8n, Make or similar) configured with explicit routing rules, human review steps and audit logging. That’s configuration work rather than development, and it typically takes days to weeks, not months. The platform comparison for advice firms covers which tool suits which kind of flow.

Level 3, a custom build, comes in when input volume is high enough that manual review of routing is impractical, or when the regulated tasks are complex enough that a general orchestration tool can’t express the logic your compliance team needs. That bar is higher than most firms assume.

Quite often, a firm that thinks it needs a custom multi-agent build needs someone to sit with its compliance team, map the workflow inputs, and configure a Level 2 integration that routes correctly and logs everything. That’s a much smaller project than most vendor proposals suggest.

This article is for informational purposes only and does not constitute regulated financial advice or a compliance opinion. Consult a qualified compliance professional for advice specific to your firm.

This article reflects the EU AI Act as understood at the date of publication. Implementation timelines have been subject to amendment. Verify current requirements against primary EU sources and take qualified legal advice for your specific circumstances.

This article does not constitute legal advice. Data protection obligations vary by circumstance and jurisdiction. Consult a qualified solicitor or data protection adviser for advice specific to your firm.

Sources

[1] FCA, Bank of England and HM Treasury joint statement on frontier AI and systemic cyber risk (2026), https://www.fca.org.uk (primary regulatory source; check the FCA website for the current version of this statement).