AI Agent Architectuur: Modelroutering en Toolontdekking

Het verbinden van een LLM is voldoende om een applicatie tekst te laten genereren. Het is echter niet voldoende om een AI-agent een taak in de echte wereld te laten voltooien.

Vraag een model om een document samen te vatten dat al in zijn context staat, en de modellaag is voldoende. Vraag het om de prijzen van concurrenten van vandaag te vergelijken, een bedrijfsrecord te verrijken, een sociaal account te controleren of de beste API voor een onbekende taak te kiezen, en de ontbrekende helft wordt duidelijk: de agent heeft een betrouwbare manier nodig om externe systemen te bereiken.

Een productieagent maakt daarom twee afzonderlijke beslissingen:

1. Welk model moet deze stap afhandelen?
2. Welke tool of API moet de gegevens of actie leveren?

AIHubMix pakt de eerste beslissing aan met uniforme modeltoegang en modelroutering op aanvraag. Monid pakt de tweede aan met runtime toolontdekking, schema-inspectie en pay-per-call uitvoering. De producten bevinden zich op verschillende lagen van dezelfde architectuur.

Openbaarmaking: Dit artikel is gemaakt als onderdeel van een content samenwerking met Monid. AIHubMix is het modelplatform dat hieronder wordt besproken; Monid is het toolplatform. Elk kan onafhankelijk worden gebruikt.

De twee routeringsproblemen binnen een AI-agent

Een agentrun is zelden één homogene modeloproep. Een onderzoeksagent kan een verzoek classificeren, zoeken naar actuele informatie, gestructureerde feiten extraheren, resultaten vergelijken en een definitief antwoord schrijven. Die stappen vereisen verschillende mogelijkheden.

Hetzelfde geldt buiten het model. Een bedrijfsresearchtaak heeft vandaag misschien een zoek-API nodig, morgen een bedrijfsverrijkings-eindpunt en volgende week een browserautomatiseringstool. Als elk model en elke tool hard gecodeerd is op het moment van bouwen, wordt elke nieuwe taak een integratieproject.

De twee lagen zijn parallel:

Deze scheiding is belangrijk. Een beter model kan geen toegang creëren tot live gegevens, en een groter toolcatalogus kan niet redeneren over de gegevens die het retourneert. De agent heeft beide mogelijkheden nodig, met een duidelijke overeenkomst tussen hen.

Monid presenteert het complementaire toolzijde overzicht in Waarom een AI-agent twee integraties nodig heeft. Van de modelzijde is de architectonische les hetzelfde: houd modelselectie en toolselectie onafhankelijk, en optimaliseer elke laag voor zijn eigen taak.

Waarom één vast model duur wordt in een agentloop

Het gebruik van één model overal lijkt eenvoudig. In de praktijk dwingt het elke stap om dezelfde afweging te accepteren tussen capaciteit, latentie en prijs.

Overweeg een marktonderzoeksagent:

• Intentieclassificatie is kort en mechanisch.
• Toolselectie vereist betrouwbare instructievolging.
• Velden extraheren uit geretourneerde JSON is voornamelijk transformatie.
• Het eindrapport kan sterkere redenering en betere schrijfvaardigheden vereisen.

Alle vier de stappen naar het meest capabele model sturen, verspilt geld aan routinematig werk. Alle vier naar het goedkoopste model sturen, kan de kwaliteit van de enige uitvoer die de gebruiker leest, verminderen. Naarmate een agentloop groeit, wordt die compromis herhaald bij elke oproep.

AIHubMix biedt een OpenAI-compatibele eindpunt over een breed modelcatalogus. Een bestaande OpenAI SDK-integratie kan naar AIHubMix wijzen door de API-sleutel en base_url te wijzigen:

from openai import OpenAI

client = OpenAI(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com/v1",
)

response = client.chat.completions.create(
    model="auto:balanced",
    messages=[
        {"role": "user", "content": "Classificeer dit verzoek en stel de volgende stap voor."}
    ],
)

Het instellen van model op auto verplaatst de modelselectie naar het verzoekpad. De router analyseert de taak en lost deze op naar een geschikt model. Een beleidsachtervoeging maakt het optimalisatiedoel expliciet:

Routering voegt geen aparte kosten toe. Het verzoek wordt gefactureerd tegen de lijstprijs van het model dat het daadwerkelijk heeft afgehandeld. Het opgeloste model en de routeringsdetails worden in de respons weergegeven, inclusief de X-Aihubmix-Router-Resolved-Model header, zodat de beslissing observeerbaar blijft in plaats van een black box te worden.

Het volledige gedrag, ondersteunde eindpunten, beleidsregels en huidige beperkingen zijn gedocumenteerd in de AIHubMix LLM Router-gids.

Modelroutering geeft een agent geen live gegevens

Nadat de modelroutering is geconfigureerd, kan de agent een beter brein kiezen voor elke stap. Het kan echter nog steeds niet weten wat er is veranderd na de trainingsgegevens van het model, toegang krijgen tot een privé bedrijfsysteem of een actie in een andere applicatie uitvoeren, tenzij een tool die mogelijkheid biedt.

Dit is waar veel agentprojecten broze code accumuleren. Een team verbindt één zoek-API, dan één scraping-API, dan één verrijkings-API. Elke integratie introduceert een ander account, inloggegevens, verzoekformaat, foutmodel en factureringsrelatie. Toolbeschrijvingen worden vaak in een systeemprompt gekopieerd en worden langzaam verouderd.

De foutmodus is gevaarlijk omdat het succesvol kan lijken. Een model kan een plausibele oproep produceren tegen een verouderd schema, een onvolledige respons ontvangen en doorgaan alsof de taak is geslaagd. Runtime schema-inspectie is veiliger dan het model vragen om een API-contract te onthouden van training of van een oude prompt.

De toollaag moet daarom drie vragen beantwoorden voordat de uitvoering:

1. Welke tool kan dit doel vervullen?
2. Welk schema en welke prijs zijn momenteel van toepassing?
3. Wat was het resultaat van de oproep?

Toolontdekking is de tweede routeringslaag

Monid verandert tooltoegang in een ontdek-inspecteer-uitvoer workflow. In plaats van dat de ontwikkelaar elke API moet voorspellen die een agent mogelijk nodig heeft, kan de agent in natuurlijke taal in een catalogus zoeken, het contract van een kandidaat inspecteren en het geselecteerde eindpunt uitvoeren.

De basisstroom ziet er als volgt uit:

# 1. Vind tools die overeenkomen met het doel
monid discover -q "vind actuele productprijzen van een openbare webpagina"

# 2. Lees het schema en de prijs van het geselecteerde eindpunt
monid inspect -p PROVIDER_SLUG -e ENDPOINT_PATH

# 3. Voer alleen uit nadat de agent het contract heeft gecontroleerd
monid run -p PROVIDER_SLUG -e ENDPOINT_PATH \
  --query '{"url":"https://example.com/product"}'

Ontdekking en inspectie stellen de agent in staat om opties te vergelijken voordat er iets wordt uitgegeven. De uitvoering wordt gefactureerd volgens het prijsmodel van het geselecteerde eindpunt. De ontwikkelaar behoudt één integratie terwijl de agent toegang krijgt tot tools van meerdere aanbieders.

Voor agentruntime die installatie-instructies kan lezen, publiceert Monid ook een machine-leesbare vaardigheid:

Set up https://monid.ai/SKILL.md

De Monid workflowdocumentatie legt de catalogus, inspectie en uitvoeringsfasen in meer detail uit.

Hoe de twee lagen samenwerken

De modelgateway en toollaag moeten aparte componenten blijven met een kleine, expliciete overdracht:

1. De agent ontvangt een gebruikersdoel.
2. AIHubMix routeert een planningsoproep naar een geschikt model.
3. Het plan identificeert ontbrekende informatie of een vereiste externe actie.
4. Monid ontdekt kandidaattools en exposeert hun schema's en prijzen.
5. De agent selecteert en voert een tool uit binnen zijn bevoegdheden en budget.
6. De tool retourneert feiten of een actie resultaat.
7. AIHubMix routeert de syntheseoproep volgens de vereiste kwaliteit, kosten of latentie.
8. De agent retourneert een antwoord dat is gebaseerd op het toolresultaat.

In vereenvoudigd Python kunnen de modelzijde oproepen onveranderd blijven terwijl het toolresultaat als context wordt ingevoegd:

from openai import OpenAI

client = OpenAI(
    api_key="<AIHUBMIX_API_KEY>",
    base_url="https://aihubmix.com/v1",
)

# Een snel model is voldoende voor een lichte planningsstap.
plan = client.chat.completions.create(
    model="auto:latency_critical",
    messages=[
        {
            "role": "user",
            "content": "Plan hoe de huidige prijzen van deze producten te vergelijken.",
        }
    ],
)

# Jouw agent gebruikt Monid om een geschikte tool te ontdekken, inspecteren en uitvoeren.
# Vervang deze plaatsaanduiders door het gestructureerde resultaat dat door die oproep is geretourneerd.
tool_result = {
    "source": "<source-url>",
    "data": "<structured-tool-result>",
}

report = client.chat.completions.create(
    model="auto:quality_first",
    messages=[
        {
            "role": "system",
            "content": (
                "Schrijf een beknopte vergelijking. Gebruik alleen het aangeleverde toolresultaat, "
                "behoud de bron-URL's en geef aan wanneer een waarde ontbreekt."
            ),
        },
        {"role": "user", "content": str(tool_result)},
    ],
)

Het belangrijke detail is niet het aantal regels. Het is dat geen van beide keuzes permanent in de applicatielogica hoeft te worden ingebed. Het model kan veranderen naarmate de prompt verandert, en de tool kan veranderen naarmate de taak verandert.

Kostenbeheersing behoort tot beide lagen

Model- en toolkosten gebruiken verschillende eenheden, dus ze moeten afzonderlijk worden gemeten.

Op de modellaag bepaalt het opgeloste model de tokenprijs. AIHubMix maakt die beslissing traceerbaar en laat ontwikkelaars een routeringsbeleid kiezen of de modellen beperken die een API-sleutel mag gebruiken. Routinematige stappen kunnen kosten of latentie bevoordelen, terwijl gebruikersgerichte uitvoer kwaliteit kan bevoordelen.

Op de toollaag kan een eindpunt per oproep of per resultaat kosten. Monid exposeert prijzen tijdens inspectie, vóór uitvoering. Een agent kan een eindpunt afwijzen dat zijn budget overschrijdt, een geverifieerde optie verkiezen of om goedkeuring vragen voordat een ongewoon dure operatie wordt uitgevoerd.

Nuttige productiecontroles omvatten:

• Een modeltoegangslijst of prijsplafond voor elke API-sleutel.
• Een maximaal budget voor tooloproepen per taak.
• Provider- of eindpunttoegangslisten voor gereguleerde gegevens.
• Logs die de modelrouteringsbeslissing verbinden met de tooloproep en het uiteindelijke antwoord.
• Expliciete bevestiging vóór onomkeerbare of gevoelige acties.
• Outputvalidatie zodat toolgegevens worden behandeld als onbetrouwbare invoer, niet als instructies.

Deze splitsing maakt ook kostendebugging gemakkelijker. Als een run duur wordt, tonen tokenlogs of de agent te veel heeft geredeneerd, terwijl toollogs tonen of het te veel heeft opgehaald. De oplossingen zijn verschillend, en de architectuur moet dat onderscheid behouden.

Betrouwbaarheid vereist actuele contracten en zichtbare beslissingen

Dynamische selectie mag niet betekenen dat het gedrag onvoorspelbaar is.

Aan de modelzijde rapporteert AIHubMix het opgeloste model en het routeringsbeleid voor elk verzoek. Sessiestickiness kan modelconsistentie en prompt-cachevoordelen behouden tijdens meerturnwerk, terwijl fallbackgedrag kan afwijken van een ongezond model wanneer dat nodig is.

Aan de toolzijde inspecteert de agent het huidige eindpuntschema voordat hij een betaalde oproep doet. Ontdekkingsresultaten bevatten de informatie die nodig is om kandidaten te vergelijken, en het resultaat van de daadwerkelijke oproep wordt het enige externe bewijs dat in de uiteindelijke voltooiing wordt doorgegeven.

Samen creëren deze controles een nuttig auditspoor:

gebruikersdoel
  -> routeringsbeslissing en opgelost model
  -> ontdekte toolkandidaten
  -> geïnspecteerd schema en prijs
  -> geselecteerd eindpunt en resultaat
  -> uiteindelijke modelbeslissing en onderbouwd antwoord

Dat spoor is waardevoller dan alleen toegang hebben tot veel modellen of veel API's. Het legt uit waarom de agent elke keuze heeft gemaakt en welk bewijs zijn antwoord ondersteunde.

Wanneer je niet beide lagen nodig hebt

Niet elke workflow profiteert van runtime-keuze.

Als een applicatie één stabiele prompt naar één getest model verzendt, is het eenvoudiger en deterministischer om dat model rechtstreeks te specificeren dan om te routeren. Als een geplande pijplijn altijd één bekend API aanroept, kan het integreren van die API direct duidelijker zijn dan het toevoegen van een ontdekkingslaag.

De twee-laagsarchitectuur verdient zijn plaats wanneer variëteit deel uitmaakt van de werklast:

• Prompts verschillen voldoende zodat het beste model per stap verandert.
• Agents doen meerdere modeloproepen en moeten de cumulatieve kosten of latentie beheersen.
• Vereiste tools kunnen niet volledig worden voorspeld op het moment van bouwen.
• Externe gegevens moeten actueel zijn en de bron moet zichtbaar zijn.
• Het team wil mogelijkheden toevoegen zonder voor elke nieuwe een nieuwe leverancierintegratie toe te voegen.

Gebruik de modellaag, toollaag of beide, afhankelijk van de beslissingen die jouw applicatie daadwerkelijk moet nemen.

Bouw de agent rond beslissingen, niet afhankelijkheden

Een productie AI-agent wordt niet gedefinieerd door hoeveel modellen of API's hij kan bereiken. Het wordt gedefinieerd door of hij de juiste capaciteit voor de huidige stap kan kiezen, binnen een budget kan opereren en kan uitleggen wat er is gebeurd.

AIHubMix geeft de agent een uniforme model-eindpunt en routering op aanvraag over kosten, kwaliteit en latentieprioriteiten. Monid biedt runtime toolontdekking, actuele schema's, zichtbare prijzen en uitvoering via externe aanbieders.

Één laag beslist hoe de agent denkt. De andere beslist hoe hij informatie vindt en handelt. Het gescheiden houden van die beslissingen produceert een agent die gemakkelijker uit te breiden, te observeren en te beheersen is.

Begin met de AIHubMix snelle start, en verbind vervolgens de toolzijde via Monid.

FAQ

Wat is modelroutering voor AI-agenten?

Modelroutering selecteert een model voor elk verzoek op basis van factoren zoals taaktype, capaciteit, kosten en latentie. Met AIHubMix stelt het instellen van model op auto of een beleid zoals auto:quality_first de selectie op aanvraag in terwijl een OpenAI-compatibele API behouden blijft.

Waarom heeft een AI-agent tools nodig als de LLM al kennis heeft?

Een LLM genereert antwoorden uit de context die het ontvangt en wat het tijdens de training heeft geleerd. Het kan niet betrouwbaar actuele prijzen weten, een privé-database raadplegen of een externe actie uitvoeren zonder een verbonden tool. Tools bieden live gegevens en uitvoering; het model plant en interpreteert het resultaat.

Is een modelgateway hetzelfde als een MCP-server of toolplatform?

Nee. Een modelgateway routeert inferentieaanvragen naar modellen. MCP-servers en toolplatforms stellen externe mogelijkheden aan een agent beschikbaar. Ze lossen complementaire integratieproblemen op en kunnen samen worden gebruikt.

Kunnen AIHubMix en Monid onafhankelijk worden gebruikt?

Ja. AIHubMix kan modeloproepen routeren voor applicaties zonder dynamische toolvereisten. Monid kan toolontdekking bieden aan agents die een andere modelprovider of gateway gebruiken. Het gebruik van beide is nuttig wanneer een agent runtime-keuze op beide lagen nodig heeft.

Hoe kan ik automatische routering controleerbaar houden?

Log het opgeloste model, routeringsbeleid, toolkandidaat, geïnspecteerde prijs, geselecteerd eindpunt en geretourneerd resultaat voor elke taak. AIHubMix exposeert modelrouteringsdetails in de respons, terwijl Monid ontdekking en inspectie scheidt van uitvoering, zodat de toolbeslissing kan worden vastgelegd vóór de betaalde oproep.