The question
As multi-agent systems mature, a tempting goal emerges: find the workflow — one orchestration topology, one set of roles, one delegation pattern — that performs well enough on everything. A single architecture you tune once and point at any task. It is an appealing idea because it is simple to deploy and simple to reason about.
The alternative is less tidy but, we argue, more powerful: maintain a registry of many workflows, each evolved for a class of tasks, and retrieve the right one at inference time based on the task in front of you. Think of it as the difference between a single general-purpose model and a mixture of experts — except the experts are entire agentic architectures, and the router is a retriever.
Our position
A retrievable pool of specialized workflows beats a single generalist on accuracy, cost, and latency for any non-trivial task distribution. The cost of retrieval is small and falling; the cost of generalization is paid on every single request.
Why the single-workflow dream breaks down
A workflow that must handle everything has to carry the union of all capabilities it might ever need. That has three compounding costs:
The generalist tax is paid per request
A one-size-fits-all workflow tends to grow extra agents, guardrails, and reflection steps so it can cope with the hardest tasks. A simple lookup then pays for a critic loop it never needed. The worst-case structure becomes the average-case cost — on tokens, on latency, and on the chance of a wrong turn.
No free lunch across task types
The structure that wins at multi-step tool use (a profiler → agent → critic pipeline) is not the structure that wins at open-ended synthesis (parallel best-of with asynthesizer). Tuning one topology to do both means landing on a compromise that is optimal for neither. Specialization exists precisely because objectives conflict.
Optimization pressure gets diluted
When we evolve a workflow against a single benchmark, every mutation is graded by one clear signal. Force one architecture to satisfy a dozen benchmarks at once and the gradient smears: improving retail support may regress code repair. A pool lets each member descend its own fitness landscape without tug-of-war.
Retrieval changes the economics
The objection to a pool of workflows used to be selection cost: if you have a thousand architectures, how do you pick the right one without an expensive meta-controller? Modern retrieval makes that objection obsolete. Picking a workflow is a nearest-neighbor lookup over an index, not an LLM deliberation.
This is where GraphRAG-style retrieval fits naturally. Workflows are not isolated points — they relate to each other: they share roles, target overlapping domains, and descend from common ancestors in an evolutionary lineage. A graph index captures those relationships, so a query can route by domain, by required tools, by benchmark family, or by structural similarity — and traverse to neighbors when the exact match is missing.
Each workflow is embedded by its task signature — domain, tools, eval criteria — and stored as a node in a graph with edges to related architectures.
An incoming task is embedded the same way. A vector + graph lookup returns the top-k candidate workflows in milliseconds — no model call needed.
Execute the best match directly, or briefly A/B the top candidates. The retrieval cost is negligible against the workflow run itself.
The asymmetry is the whole argument: retrieval is O(milliseconds) and amortized across the index; generalization is O(every token of every request). You pay for selection once per task and reap a workflow that was tuned for exactly that task.
This is already how AutoAW thinks
AutoAW evolves multi-agent workflows with Genetic Programming, and every gene in the population is a portable AWP .awf document. Evolution does not produce one champion that wins everywhere — it produces a population of high-fitness architectures, each shaped by the benchmark it was optimized against. That population is the pool.
The AWP registry (coming at awf.sh) turns that pool into a retrievable index. Each entry already carries exactly the metadata a retriever needs — the domain, the tools, the benchmark, and the measured fitness on quality, cost, and latency. Retrieving a workflow is therefore not a bolt-on feature; it falls out of the format we already store.
Don't optimize one workflow until it generalizes. Evolve many, store them with their fitness evidence, and retrieve the best fit per task. The registry is the model; the retriever is the router.
The honest trade-offs
A pool is not free of cost — it moves the cost to places that are easier to control:
- Maintenance surface. Many workflows mean many things that can rot. Mitigated by keeping each
.awfself-describing and re-running its embedded eval on a schedule — stale entries demote themselves. - Cold-start and coverage gaps. A genuinely novel task may match nothing well. This is where graph traversal earns its keep: fall back to the nearest neighbors, or use them as seeds for a fresh evolution run.
- Retriever quality becomes load-bearing. A bad router sends tasks to the wrong expert. But a misrouting is recoverable and measurable; a generalist's compromise is baked in and invisible.
None of these are reasons to prefer a single workflow. They are reasons to invest in the retriever and the eval loop — which is exactly where the leverage is.
The bet we're making
The history of machine learning keeps repeating a pattern: monolithic models give way to specialized components with a cheap router in front. Mixture-of-experts beat dense models on cost per quality. Retrieval beat cramming everything into the prompt. We expect agentic workflows to follow the same arc — and a fast, graph-aware registry of architectures is the retrieval layer that makes it work.
So: not one workflow that generalizes well enough, but many workflows that each excel, with a retriever deciding which one runs. That is the architecture we're building toward.
Have a take?
We'd love to hear where this breaks for your task distribution.