🤖 AI

Agent-as-a-Router: Agentic Model Routing for Coding Tasks

Dit artikel introduceert Agent-as-a-Router, een framework dat modelrouting behandelt als een dynamische Context-Actie-Feedbacklus om uitvoering-gegronde ervaring te accumuleren, waardoor het informatiegebrek van statische routers wordt overwonnen en superieure prestaties en kostenefficiëntie in programmeertaken worden bereikt.

Oorspronkelijke auteurs: Pengfei Zhou, Zhiwei Tang, Yixing Ma, Jiasheng Tang, Yizeng Han, Zhenglin Wan, Fanqing Meng, Wei Wang, Bohan Zhuang, Wangbo Zhao, Yang You

Gepubliceerd 2026-06-23

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Pengfei Zhou, Zhiwei Tang, Yixing Ma, Jiasheng Tang, Yizeng Han, Zhenglin Wan, Fanqing Meng, Wei Wang, Bohan Zhuang, Wangbo Zhao, Yang You

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een manager bent die een druk programmeeragentschap runt. Je hebt een team van acht verschillende expert-ontwikkelaars, elk met hun eigen unieke superkrachten en prijsetiketten.

Ontwikkelaar A is een genie in het oplossen van bugs maar vraagt een fortuin.
Ontwikkelaar B is goedkoop en geweldig in het schrijven van datascripts, maar slecht in complexe wiskunde.
Ontwikkelaar C is geweldig in het schrijven van testgevallen maar traag in alles wat daarmee te maken heeft.

In het verleden huurden de meeste bedrijven gewoon Ontwikkelaar A in (de duurste, de "beste") voor elke opdracht om veilig te zijn. Maar dit is verspillend. Als je een simpel datascript nodig hebt, is het inhuren van Ontwikkelaar A alsof je een Formule 1-coureur inhuurt om je naar de supermarkt te rijden.

Dit paper, getiteld "Agent-as-a-Router," introduceert een nieuwe manier om dit team aan te sturen. In plaats van blindelings de "beste" ontwikkelaar te kiezen, bouwden de auteurs een slimme Verkeersregelaar (een "Router") die beslist welke specifieke ontwikkelaar welke specifieke taak moet afhandelen.

Hier is de uitsplitsing van hun ontdekking en oplossing:

1. Het Probleem: De "Informatiekloof"

De onderzoekers vroegen zich eerst af: Waarom werken huidige slimme routers niet beter?
Ze testten een standaard AI-router (een "Vanilla" router) en zagen dat deze fouten maakte. Ze vroegen zich af: Is de router gewoon niet slim genoeg om door het probleem te redeneren?

Om dit te testen, gaven ze de router een spiekbriefje met prestatiestatistieken (bijv. "Ontwikkelaar B is 90% goed in data-taken").

Resultaat: De prestaties van de router sprongen direct met 15,3% omhoog.
De Les: De router faalde niet omdat hij "dom" was; hij faalde omdat hij blind was. Hij had niet genoeg informatie over hoe de verschillende ontwikkelaars presteerden op specifieke taken. De bottleneck was een informatiedeficiëntie, geen gebrek aan intelligentie.

2. De Oplossing: De "Lerende Verkeersregelaar"

De auteurs stellen een nieuw systeem voor genaamd ACRouter. In plaats van een statisch regelboek, ontwierpen ze het als een levende, lerende lus. Ze noemen dit de C-A-F Loop:

Context (De Briefing): De router kijkt naar de nieuwe programmeertaak en herinnert zich wat hij heeft geleerd van eerdere soortgelijke taken.
Action (De Toewijzing): Het kiest de beste ontwikkelaar voor de klus.
Feedback (Het Rapportcijfer): De ontwikkelaar voert het werk uit, en een "Verifier" (een gesandeerde testomgeving) controleert of de code daadwerkelijk werkt en hoeveel het gekost heeft.
Update (Het Geheugen): De router neemt dat rapportcijfer en slaat het op in zijn Geheugen.

De Analogie:
Denk aan een traditionele router als een statische kaart. Die vertelt je elke keer dezelfde route, zelfs als de weg is afgesloten.
De ACRouter is als een chauffeur van een deeldienst met een live GPS.

Hij neemt een passagier (de taak) mee.
Hij zet de passagier af.
Hij controleert of de passagier tevreden was en hoeveel brandstof er is verbruikt.
Hij onthoudt dat "Route X geweldig was voor dit type passagier, maar Route Y was te duur."
De volgende keer dat er een soortgelijke passagier komt, maakt de chauffeur een betere keuze omdat hij ervaring heeft.

3. "Geheugen" is de Sleutel

Het belangrijkste onderdeel van hun systeem is de Geheugenmodule.

Oude routers waren als studenten die voor een toets studeerden, de toets maakten en daarna alles vergaten. Ze konden niet leren van hun fouten.
ACRouter houdt een "dagboek" bij van elke taak die het ooit heeft gerouteerd. Het onthoudt: "Vorige keer dat ik een 'Data Science'-taak naar Ontwikkelaar B stuurde, werkte het perfect en was het goedkoop. Vorige keer dat ik het naar Ontwikkelaar A stuurde, was het duur en mislukte het."

Dit zorgt ervoor dat de router slimmer wordt naarmate hij meer werkt, en zich aanpast aan nieuwe soorten programmeeruitdagingen die hij nog nooit eerder heeft gezien.

4. De Resultaten: Slimmer en Goedkoper

Het team testte hun systeem op een enorme benchmark genaamd CodeRouterBench (ongeveer 10.000 programmeertaken).

Op bekende taken: ACRouter was het meest nauwkeurig bij het kiezen van de juiste ontwikkelaar en versloeg zelfs de "perfecte" statische regels.
Op nieuwe, vreemde taken (Out-of-Distribution): Dit is waar de magie gebeurde. Toen ze de router een compleet nieuw type programmeeruitdaging gaven (Agentic Programming) die hij nog nooit had gezien:
- Faalden de oude "statische" routers (die alleen regels hadden gememoriseerd) hopeloos.
- De "lerende" router (ACRouter) paste zich snel aan, waarbij hij zijn geheugen van soortgelijke patronen gebruikte om succesvol te zijn.
- Het presteerde zelfs beter dan de strategie om simpelweg de duurste, "beste" ontwikkelaar voor elke baan in te huren, waardoor het geld bespaarde terwijl de resultaten verbeterden.

Samenvatting

Het paper betoogt dat om het meeste uit meerdere AI-modellen te halen, je niet alleen de "sterkste" moet kiezen. In plaats daarvan heb je een slimme, lerende manager nodig die:

De specifieke sterktes van elk model kent.
Leert van zijn eigen fouten in realtime.
Een geheugen opbouwt van wat wel en niet werkt.

Door de "informatiekloof" te dichten met deze feedbackloop, wordt het systeem een zeer efficiënte, zelfverbeterende routing-engine die geld bespaart en de kwaliteit van de code verbetert.

Technische Samenvatting: Agent-als-Router

1. Probleemstelling

Echte gebruikers hebben vaak toegang tot meerdere Large Language Models (LLM's) van verschillende providers, die elk uitblinken in specifieke domeinen (bijv. algoritmeontwerp, data science of code-aanvulling), maar geen enkel model domineert alle taken. Huidige coding-agents vertrouwen doorgaans op één enkel, vaststaand LLM voor alle taken, een ontwerp dat de voorspelbaarheid aan de provider-zijde prioriteert boven de taakgerichte kostenefficiëntie en kwaliteit vanuit het perspectief van de gebruiker.

Het kernprobleem is automatische modelrouting: bepalen welk model elke inkomende coding-taak moet afhandelen om de prestaties te maximaliseren terwijl de kosten worden geminimaliseerd. Bestaande routing-methoden behandelen dit als een statisch, eenmalig classificatieprobleem, waarbij vaak taalmodellen als routing-policies worden ingezet. Echter, voorlopige experimenten laten een aanzienlijk prestatieverschil zien tussen deze statische routers en een "per-taak oracle" (die het beste model voor elke specifieke taak kent). Het papier identificeert dat de bottleneck voor bestaande routers niet een gebrek aan redeneervermogen is, maar een informatiedeficiëntie: statische routers slagen er niet in om tijdens de implementatie ervaring op te bouwen die gebaseerd is op executie.

2. Methodologie

2.1. Diagnose: Informatiedeficiëntie

De auteurs voerden een ablatie-studie uit met een zero-shot LLM-router (aangedreven door Claude Sonnet 4.6).

Vanilla Router: Scoorde 41,41% AvgPerf.
+Perf Stats: Wanneer voorzien van voorafgaande prestatiestatistieken van een hold-out probing set, steeg de score naar 47,74% (+15,3% relatieve winst), waarmee zelfs de beste heuristische router (47,50%) die dezelfde statische priors bevat, werd overtroffen.
Conclusie: De primaire beperking is het gebrek aan dynamische, op executie gebaseerde informatie, en niet het redeneervermogen van het router-model zelf.

2.2. Het Agent-als-a-Router Framework

Om de informatieverificatie aan te pakken, stellen de auteurs Agent-as-a-Router voor, een framework dat routing formaliseert als een Context-Actie-Feedback (C-A-F) loop. In tegenstelling tot statische routers, evolueert dit framework over een stroom van taken:

Context ( $c_i$ ): De router observeert de taakprompt, metadata en de geaccumuleerde geschiedenis (Memory) van vorige loops.
Actie ( $a_i$ ): De router selecteert een model uit de kandidaatpool.
Feedback ( $f_i$ ): De output van het geselecteerde model wordt uitgevoerd in een sandbox, en een verifier genereert een score en kosten.
Update: De feedback wordt opgeslagen in het geheugen en samengevoegd in de context voor de volgende taak ( $c_{i+1}$ ).

Deze formulering relateert aan een contextueel multi-armed bandit probleem, waarbij de natuurlijke metriek voor evaluatie cumulatief regret is (het geaccumuleerde gat tussen de prestaties van de router en de per-taak oracle).

2.3. ACRouter Instantiatie

Het framework wordt geïnstantieerd als ACRouter, bestaande uit drie kernmodules:

Orchestrator: Neemt routing-beslissingen door de DimensionBest prior, de top-10 historische buren (opgehaald via cosine kNN uit de Memory) en taakmetadata te integreren. Het gebruikt een lichtgewicht, gefinetuned Qwen3.5-0.8B model gecombineerd met heuristische regels via weighted voting.
Verifier: Evalueert modeloutputs in een gesandboxed omgeving. Het aggregeert signalen (AST parsing, executieresultaten, LLM-as-Judge) tot een uniforme prestatiescore ( $u_i \in [0, 1]$ ).
Memory: Een online vector store gekoppeld aan taak-embeddings. Het logt het gekozen model, prestaties, kosten en verificatie-traces. Het maakt gebruik van een FIFO-gebonden store (20K entries) om fijnmazige, context-bewuste retrieval van eerdere successen en mislukkingen mogelijk te maken.

2.4. CodeRouterBench

Om routing op stromende taken te evalueren, introduceren de auteurs CodeRouterBench, een benchmark bestaande uit:

~10.000 taken verspreid over 10 coding-dimensies (9 in-distribution single-turn taken en 1 out-of-distribution agentic-programming dimensie).
8 Frontier LLMs (inclusief Claude Opus 4.6, GPT-5.4, Qwen3-Max, Kimi-K2.5, etc.).
Execution-Verified Scores: Taken worden gescoord via sandboxed executie of LLM-as-Judge, wat een grondwaarheid observatiematrix biedt voor regret-gebaseerde vergelijking.

3. Belangrijkste Bijdragen

Framework: Het voorstel van Agent-as-a-Router, dat modelrouting formaliseert als een C-A-F loop, waardoor routers actief de informatiekloof kunnen dichten door middel van executie-gebaseerde feedback.
Artifacten:
- ACRouter: Een concrete instantiatie van het framework met Orchestrator, Verifier en Memory modules.
- CodeRouterBench: Een gestandaardiseerde evaluatieomgeving (~10K taken, 8 LLM's) die specifief is ontworpen voor regret-gebaseerde router-vergelijking op stromende taken, inclusief een OOD agentic-programming testbed.
Bevindingen:
- Informatiedeficiëntie: De routing-bottleneck is toegang tot informatie, niet het redeneervermogen. Het verstrekken van prestatiestatistieken levert een 15,3% relatieve winst op.
- Prestaties: ACRouter bereikt het laagste cumulatieve regret op in-distribution taken en generaliseert effectief naar out-of-distribution (OOD) agentic-programming taken.
- Statische Beperkingen: Lichtgewicht statische routers (getrainde classifiers, heuristieken) presteren redelijk op in-distribution taken, maar falen aanzienlijk op OOD taken, waarbij de prestaties dalen naar 8,93%–21,43%, zelfs lager dan willekeurige selectie. ACRouter behoudt sterke prestaties.

4. Experimentele Resultaten

Experimenten werden uitgevoerd op zowel in-distribution (ID) als out-of-distribution (OOD) taakstromen.

In-Distribution Prestaties:
- ACRouter behaalde de hoogste gemiddelde prestatie (49,98%) en het laagste cumulatieve regret (205,5), waarmee het de statische "DimensionBest" heuristiek (47,50%) en alle getrainde policy baselines overtrof.
- Het demonstreerde ook superieure kostenefficiëntie (Perf/$ ratio van 3,79) vergeleken met het altijd gebruiken van het sterkste enkele model (Always-Opus 4.6, die een ratio van 1,29 had).
Out-of-Distribution (OOD) Generalisatie:
- Op het agentic-programming testbed (176 taken) behaalde ACRouter een 62,50% AvgPerf, wat aanzienlijk beter is dan de Always-Opus baseline (57,14%) en alle andere routers.
- Statische classifiers (bijv. LogReg, RouteLLM-BERT) stortten in op OOD taken, met prestaties die daalden naar 8,93%–21,43%, zelfs lager dan willekeurige selectie.
- Het vermogen van ACRouter om tijdens de stroom geëxecuteerde ervaring te accumuleren, stelde het systeem in staat zich aan te passen aan de nieuwe taakverdeling, terwijl statische methoden die steunen op bevroren priors faalden.
Kostenanalyse:
- Hoewel ACRouter overhead veroorzaakt voor de Memory en Verifier modules, blijft het kostenefficiënter dan het altijd selecteren van het duurste model (Opus 4.6), terwijl het een hogere kwaliteit levert.
- De "Always-Kimi-K2.5" strategie bood de hoogste kostenefficiëntie (Perf/$ 12,62) maar tegen een substantiële prijs in absolute prestaties (36,66% AvgPerf).

5. Betekenis en Claims

Het paper claimt dat het actief dichten van de informatiekloof door middel van executie-gebaseerde feedback een algemeen principe is voor het bouwen van agentic systemen die moeten routeren tussen heterogene tools of modellen.

Paradigmaverschuiving: Het werk verplaatst routing van een statisch classificatieprobleem naar een dynamisch, zelfadaptief proces (C-A-F loop).
Praktisch Nut: Het demonstreert dat gebruikers bijna oracle-prestaties en kostenefficiëntie kunnen bereiken door dynamisch te routeren, in plaats van te vertrouwen op één enkel "beste" model.
Generaliseerbaarheid: De C-A-F loop wordt gepresenteerd als meer dan alleen een routingmechanisme; het is een breder besluitvormingsparadigma toepasbaar op tool-selectie, API-endpoint selectie en inspanningsallocatie.
Bescheidenheid: De auteurs erkennen beperkingen, zoals het onvermogen om provider-zijde cache hit rates te observeren (waardoor kostenramingen relatief in plaats van absoluut zijn) en het gebruik van een gereduceerde staplimiet voor OOD-taken om budgettaire beheersbaarheid te garanderen. Ze merken op dat hoewel hun huidige instantiatie een LLM-policy met kNN-geheugen gebruikt, alternatieve technieken op parameterniveau nog verkend moeten worden.

Samenvattend betoogt het paper dat voor agentic coding-systemen de toekomst niet ligt in het vinden van één dominant model, maar in het bouden van adaptieve routers die leren van executie-feedback om de juiste tool voor de juiste taak te selecteren.