Routing before team execution: AgentWeave + AutoGen integration example

[SAURAV SINGLA (sauravsingla)]

I’ve been exploring a simple systems question for multi-agent applications:

Should every available agent/tool be exposed to the orchestration layer up front, or should a deterministic routing layer first reduce the candidate set?

I built an AutoGen integration example for AgentWeave that uses this pattern:

task
→ AgentWeave routing
→ selected AutoGen participants
→ normal AutoGen team execution

The integration keeps AutoGen’s execution model unchanged. AgentWeave only decides which specialists participate before the AutoGen conversation starts.

The example is local and keyless, so it can be inspected without an LLM/API dependency.

AgentWeave repo:
https://github.com/sauravsingla/agentweave

AutoGen integration PR:
sauravsingla/agentweave#25

I’d be interested in feedback on one design question:

For large multi-agent systems, should participant selection be treated as a separate pre-execution systems layer, or should the agent framework itself handle this internally?

Also interested in failure cases where pre-routing would make orchestration worse.

[Harlock (capitaharlock)]

The more important boundary isn’t separate layer versus framework-internal, it’s whether the selected participant set is closed. Deterministic pre-routing makes sense when the task itself contains enough signal, but the execution path still needs a way to trigger re-selection. Otherwise a specialist whose need only becomes clear at turn 3 was already excluded, and the remaining agents may quietly improvise that work instead of failing loudly. That silent capability gap is where pre-routing makes orchestration worse.