Should agent frameworks separate candidate routing from orchestration?

[SAURAV SINGLA (sauravsingla)]

I’m exploring an architectural pattern for tool-rich and multi-agent systems:

separate candidate selection from downstream orchestration.

The basic idea is:

task
→ candidate catalog
→ deterministic/policy-aware routing
→ smaller selected set
→ normal agent-framework execution

I’m implementing this in AgentWeave and have been testing integrations with AutoGen, LangGraph, MCP, and BFCL-compatible function calling.

The reason I think the boundary is interesting is that routing can carry its own:

• capability constraints;
• trust/policy filters;
• cost/latency signals;
• provenance;
• audit trail.

That lets the downstream framework focus on actual conversation/workflow execution.

Repo:
https://github.com/sauravsingla/agentweave

I’d be interested in community views on:

1. Should routing be a first-class framework concept?
2. Should the selected candidate set be part of workflow state/provenance?
3. Where should policy-aware routing live: inside orchestration, middleware, or a separate layer?
4. What information should survive into traces so we can tell whether an agent/tool was not chosen versus never shown?

I’m especially interested in counterexamples where separating routing from orchestration causes unnecessary complexity.

[Harlock (capitaharlock)]

I’d make the routing record first-class, not necessarily the routing component. Persist the candidate set and an exclusion reason for each filtered candidate into workflow state, so the trace can distinguish policy-excluded from never present in the catalog. A separate routing layer stays clean while policy inputs are fixed per task, but once eligibility changes mid-execution, orchestration has to re-enter selection and that boundary starts growing orchestration of its own.