Der er et tidspunkt, hvor agent‑projekter begynder at knage. Ikke i demoen. I drift. En opdateret artikel hos Towards AI beskriver, hvordan semantic routing skærer både latenstid og omkostninger, når agent‑systemer rammer virkeligheden med dusinvis af SaaS‑værktøjer i bagenden (kilde: Towards AI, 23. juli 2026). Påstanden er skarp, men også plausibel, fordi den rammer et kendt smertepunkt i produktion.
Kernen er, at mange teams lader en dyr LLM afgøre, hvilket værktøj der skal bruges, og derfor sender hele værktøjs‑inventaret med ind i hvert kald. Det puster konteksten op, spilder tokens og kan udløse hallucinerede API‑kald. Semantic routing foreslår det modsatte: adskil routing fra reasoning. Først en hurtig, billig vektor‑classifier til at vælge sti. Så – kun hvis nødvendigt – et LLM‑kald til den svære del.
Hvorfor det betyder noget nu
Timingen er ikke tilfældig. Priserne på LLM‑kald fylder i budgetterne, og latenstærskler presser SLA’er. Samtidig dukker små rute‑modeller og frameworks op; kilden nævner vLLM Semantic Router som et praktisk startpunkt, og peger på standarder i horisonten som SIRP samt relaterede protokoller som MCP og A2A (kilde: Towards AI). Når infrastruktur og standarder bevæger sig, bliver arkitekturvalg realpolitik – ikke teori.
Det, der gør historien konkret, er koblingen til drift. Artiklen og supplerende tekniske notater beskriver, hvordan en agent, der fungerer i udvikling, kan mangedoble sine omkostninger i produktion, når antallet af integrationer stiger. Kilden nævner ikke sjældent cirka ti gange dyrere og uacceptabel ventetid, når værktøjsflokken nærmer sig 30 (kilder: Towards AI; teknisk manual‑brief). Ikke fordi agenten ændrer sig – men fordi rutevalget sker på den dyre måde.
Hvad går galt i drift i dag
Der er et mønster. Når en LLM vælger værktøj, pakker udviklere ofte hele tool‑kæden ind i hver prompt. Konsekvensen er tokenbloat, forvirret kontekst og høj ventetid. Kilden peger også på hallucinerede API‑kald, fordi modellen presses til at “finde på” valg mellem overlappende værktøjer (kilde: Towards AI).
Hertil kommer klassiske produktionsfejl: manglende batching og asynkron orkestrering, sløset prompt‑ og modelstyring, uventede tredjeparts‑requests uden guardrails og for lidt observability i hele kæden (kilde: teknisk manual‑brief). Regningen afspejler ikke enhedspriserne i udvikling, og driften får sager, hvor et kald tager 2,1 sekunder i går og 11,8 i dag – uden synlig forklaring.
Hvad semantic routing er teknisk
Idéen er jordnær: rutevalg er en klassifikationsopgave, ikke et åbent‑end logisk problem. Man bruger en hurtig vektor‑classifier (embeddings + nearest‑neighbour eller en letvægtsmodel) til at vælge værktøj, skill eller agent. Først derefter kaldes en stor model, og kun når opgaven kræver egentlig reasoning. Det er netop denne separation, kilden lægger vægt på (kilde: Towards AI).
Arkitekturdiagram i ord
Flowet i den “nye skole”: brugerforespørgsel ind. En semantic router koder teksten til et vektorrum og matcher mod et sæt værktøjs‑ eller intent‑embeddings. Højeste score vinder, hvis konfidensen er over en tærskel. Det valgte tool kaldes direkte. Kræver tool’et mere kontekst eller vurdering, suppleres med et enkelt LLM‑kald.
Sammenlign med alternativerne: 1) “alle‑i‑én” LLM‑routing, hvor modellen hver gang sluger hele værktøjskataloget og beslutter på ny; 2) hårdkodede regler, der er hurtige men skrøbelige ved overlappende intents. Semantic routing lægger sig mellem de to: hurtigere og billigere end LLM‑routing, mere fleksibel end rene regler.
Økonomien og prisstrukturen
Når rutevalget bliver billigt og stabilt, bliver omkostningerne mere forudsigelige. Towards AI argumenterer for, at det gør multi‑agent‑opsætninger økonomisk levedygtige igen, fordi man undgår at betale en fuld LLM‑billet for hvert værktøjsvalg. Det giver også pricing‑modeller med mindre sving efter kontekstens længde (kilde: Towards AI). Effekten afhænger dog af trafiksammensætning og tool‑mix.
Et forsimplet eksempel – baseret på kildens idéer og almindelige listepriser: Antag 1 mio. månedlige requests, hvor 60 % kan routes uden yderligere LLM. En vektor‑classifier, ofte ~100 ms ifølge kilden, koster marginalt i forhold til LLM. Hvis hvert undgået LLM‑kald sparer 0,3 cent, er det ca. 1.800 dollars pr. måned. Realismen afhænger af, om alternativet var at sende 30 tools ind i hver prompt – eller om man allerede havde god caching og snæver kontekst. Pointen er variansen, der falder.
Implementering i praksis
Kilden foreslår at evaluere semantic routing, når værktøjspaletten er ved at vokse, ikke før. Start med noget som vLLM Semantic Router for at måle rå effekt, og planlæg tidligt for SIRP‑kompatibilitet, hvis den standard lander i praksis. Læg en baseline for cost og p95‑latenstid før skiftet, så gevinsten kan måles (kilde: Towards AI).
Suppler med driftstrin, som tekniske noter understreger: indfør batching, asynkrone flows og kontrolleret model‑fallback. Etabler telemetry og cost‑dashboards, så rute‑konfidens, tool‑fejl og afvigelser kan spores over tid (kilde: teknisk manual‑brief). Placeringen af vektor‑indekset er vigtig: central placering letter styring, mens edge‑deployments kan skære 50‑150 ms af round‑trip i globale setups. Opdatér embeddings for nye tools inkrementelt – gerne med review – så semantiske overlap fanges tidligt.
Drift og support ændrer sig
Når routing flytter ud af LLM’en, flytter fejlkilderne sig også. Observability skal vise, hvorfor et tool blev valgt – ikke kun, hvad LLM’en skrev. Det kræver logs for konfidensfordelinger, tætteste matches og alternativer, der var tæt på. Fejlhåndtering bliver central, især når classifieren misforstår en ambivalent forespørgsel.
Governance og sikkerhed får en ekstra vinkel. Automatiske API‑kald uden menneske i løkken bør omgives af whitelists, audit‑logs for routing‑beslutninger og preflight‑checks før destruktive operationer. SLA’er kan faktisk blive skarpere, fordi 100 ms routing + deterministisk tool‑kald er mere forudsigeligt end 1‑2 sekunders LLM‑overvejelse – men kun hvis fallback‑vejene er lige så stramme. Ellers flytter man blot flaskehalsen.
Sikkerhed, standarder og interoperabilitet
Fordelen ved tidlig standardadoption er interoperabilitet. Risikoen er at kode mod en bevægelig specifikation og skulle refaktorere senere. Et forsigtighedsråd er at isolere SIRP‑bindinger bag en adapter og gøre routing‑laget konfigurerbart, så man kan skifte uden at omskrive hele agenten. Tænk feature‑toggles – bare for protokoller.
Caseevidens fra produktion
Der findes driftserfaring i stor skala, om end ikke som direkte bevis for semantic routing. Monday.com beskriver, hvordan de kører agentisk AI i produktion på Amazon Bedrock, med rapporterede interne metrikker som, at per‑engineer PR‑throughput er steget med mere end halvdelen, og at ni ud af ti “Builders” bruger AI‑kodeværktøjer hver måned (kilde: AWS blog, monday.com data). Det er deres egne tal, ikke uafhængigt verificerede, men casen dokumenterer, at agentarkitekturer kan bære i et komplekst produktionsmiljø.
Casen minder også om forskellen på greenfield og legacy. Monday.coms arkitektur er mangeårig, og agent‑integrationerne lever i et miljø med rigtige on‑call‑rotationer og compliance. Demos imponerer hurtigt; den reelle prøve er at lade en agent åbne pull requests i et system med millioner af brugere. Det skærper kravene til determinisme, sporbarhed og rollback.
Modargumenter og usikkerheder
Semantic routing er ikke en sølvkugle. Klassifikationsfejl er uundgåelige, især hvor intents overlapper, eller hvor brugeren skifter mål halvvejs. Der er også en vedligeholdelsesomkostning ved at holde et vektor‑indeks friskt, opdatere embeddings for nye tools og rydde semantisk støj. Den pris indgår sjældent i de første regnestykker.
Praktisk checkliste
Hvornår giver evaluering mening? Når værktøjslisten er så stor, at I reelt fylder for meget kontekst i LLM‑kald – eller når p95‑latenstiden bliver ujævn. Hvilke teams skal med? Platform\/ML‑engineering for router og index, produkt for intents og tool‑scope, sikkerhed for whitelists\/audits, finans for cost‑baseline og A\/B‑test. Hvilke KPI’er? Cost per request, p95\/p99‑latens, hallucinationsrate, rate af uventede API‑kald, classifier‑confidence‑fordeling over tid.
Et snævert POC‑scope kan være 5‑8 højt brugte tools med tydelige intents og en klar abort‑sti ved lav konfidens. Byg en simpel router, mål gevinsten, og rul derefter ud i ringe. Hold øje med rute‑ændringer efter første svar – det kan korrelere med hallucinationer. Test også på degradede netværk, hvor edge‑deployments kan være forskellen på 200 og 700 ms.
Hvor feltet kan være på vej hen
Når routing bliver en selvstændig komponent, åbner det for specialiseret hardware og nye deployments. Routing‑bevidste chips, der kværner embeds lokalt. Små vektor‑classifiers ved kanten tæt på brugeren. Og mere komplekse agent‑protokoller, hvor rute og forhandling sker mellem agenter uden at gå gennem en generalist‑LLM ved hvert trin.
Det er stadig tidligt for de åbne standarder, og der er huller i dokumentationen: ingen uafhængige benchmarks for vLLM Semantic Router, begrænset viden om TCO for store vektor‑indeks og få casestudier ud over monday.com. Retningen er dog klar nok til at teste. Man mærker først forskellen i drift, når en kaldkæde, der plejede at tage halvandet sekund, pludselig svarer på under et halvt.
