Sinds agents van demo's naar productie gaan, duikt er een nieuwe infrastructuurlaag op: een gatewaylaag voor AI-verkeer. En niet zonder reden: zodra agents echt draaien, lopen teams tegen pijnlijk concrete problemen aan — token-rekeningen die uit de hand lopen door een agent die in een loop blijft hangen, agents die de verkeerde tool aanroepen of namens de verkeerde gebruiker handelen, en debugging hell omdat je nergens een volledige trace hebt van wat de agent precies deed. Verwarrend genoeg circuleren er twee termen door elkaar — AI gateway en agent gateway — en worden ze niet consequent gebruikt. Toch zit er een zinvol onderscheid achter. Dit artikel zet de verschillen op een rij.
De kern in één zin
Een AI gateway beheert typisch het verkeer naar de modellen. Een agent gateway beheert in de meeste implementaties het verkeer tussen agents onderling en hun tools en resources. Geen van beide definities staat echter vast — in een snel evoluerend domein verschuiven de grenzen voortdurend.
Anders gezegd: bij een AI gateway is het centrale object de call naar een model — welk model, hoeveel tokens, wat het kost, en of het antwoord gevoelige data lekt. Bij een agent gateway is het centrale object het gedrag van de agent zelf — welke tool hij inschakelt, namens wie, en hoe hij stappen aan elkaar ketent.
Een AI gateway is overigens veel meer dan alleen een tool voor routing, kosten en inspectie. AI gateways zijn historisch modelcall-centric, maar evolueren in 2026 richting een breder execution-aware control plane: van losse modelcalls naar workflow-aware routing, tool-aware beslissingen en stateful inference pipelines. Ze nemen ook prompt templating, lichte of geïntegreerde RAG-orchestratie, pre- en post-processing guardrails en evals- en logging-pipelines voor hun rekening. De modelcall is nog steeds het vertrekpunt, maar het zwaartepunt verschuift naar wat er rond en tussen die calls gebeurt. Belangrijke nuance: in veel setups zit een deel van deze logica — vooral RAG en orchestratie — vandaag nog in de app-laag, in orchestration frameworks zoals LangChain en LlamaIndex, en niet in de gateway zelf.
Een concreet voorbeeld
Stel: een coding agent leest een ticket uit Jira, vraagt context op uit een interne documentatie-tool en schrijft daarna een wijziging naar een Git repository. Daar zie je beide gateways aan het werk. Elke keer dat de agent nadenkt of tekst genereert, loopt die call door de AI gateway — die het model kiest, tokens telt en het antwoord inspecteert. Elke keer dat de agent een tool aanroept (Jira lezen, documentatie ophalen, naar de repository schrijven), loopt die call door de agent gateway — die controleert of deze agent dat mag, namens wie, en die de stap vastlegt in een audit trail.
Het verschil in een tabel
| Aspect | AI Gateway | Agent Gateway |
|---|---|---|
| Wat het beheert | Verkeer naar de modellen (LLM's) | Verkeer tussen agents en hun tools/resources |
| Centraal object | De call naar een model | Het gedrag van de agent (multi-step chains) |
| Analogie | API gateway, maar voor LLM's | Reverse proxy / service mesh voor agentic workloads |
| Protocollen | OpenAI-compatible API, model-provider API's | MCP, A2A, REST/gRPC (emerging protocollen, nog niet breed gestandaardiseerd) |
| Identiteit | API-key / team-niveau | Agent-identiteit first-class, tool-level RBAC |
| Beveiliging | Prompt/response-inspectie, data masking | OAuth token-exchange, mTLS, prompt-injection guardrails |
| Observability | Token-gebruik, model-latency, kosten per model | Traces over agent→tool→LLM chains, reasoning-stappen |
| Kosten | Model fallback, semantic caching, kostenbeheersing | Token-based rate limiting per agent/team, denial-of-wallet |
| Auth-model | Mens → model (request/response) | Niet-menselijke actor → tools, agent → agent |
| Failure mode | Provider-uitval, kostenpieken | Op hol geslagen agents, misbruik van permissies |
| Overlap / convergence | In de praktijk lopen beide door elkaar: dezelfde tool dekt vaak model-routing én tool-governance, en de scheiding is messy. Lees de rijen hierboven dus als accenten, niet als harde grenzen. | |
Use cases: AI Gateway
- Eén unified endpoint voor meerdere providers (OpenAI, Anthropic, Gemini) met automatische failover als een provider uitvalt.
- Kostenbeheersing: budgetlimieten en spend-attributie per team of API-key.
- Semantic caching: een gelijke intent levert een cached response, wat tokens bespaart. Let wel: semantic caching is geen 'free lunch'. Hoewel het uitstekend werkt voor specifieke use cases, vereist het zorgvuldige cache-invalidation en context awareness — anders riskeer je verkeerde antwoorden uit de cache.
- Model-routing op taaktype: een groot context window voor lange PDF's, een snel en goedkoop model voor sentimentanalyse.
- Shadow AI tegengaan: alle modelcalls lopen door één gecontroleerd punt.
Use cases: Agent Gateway
- MCP-servers beheren: bepalen welke agent welke tool mag aanroepen, met tool-level RBAC en een audit trail.
- Agent-to-agent samenwerking beveiligen in multi-agent systemen (capability discovery, task collaboration).
- Prompt-injection mitigatie op elke tool-call, niet alleen op de modelcall. Belangrijke nuance: prompt injection is in de kern een model-alignment- en context-boundary-probleem, geen netwerkprobleem. Een gateway kan patronen detecteren en policies afdwingen, maar hij kan de intentie achter een instructie niet betrouwbaar interpreteren en kwaadaardige instructies dus niet volledig blokkeren. Echte bescherming vereist ook applicatielogica en model-side guardrails.
- Coding agents (Cursor, Claude Code, Gemini CLI) veilig laten praten met interne resources.
- Agentgedrag debuggen: volledige traces over de hele reasoning chain in plaats van losse HTTP-logs.
Conclusie
Behandel het onderscheid vooral als een nuttig mentaal model. Stel jezelf telkens de vraag: redeneer ik over modelkosten en routing (AI gateway), of over welke agent wat mag aanroepen en hoe ik dat audit (agent gateway)? In een serieuze productie-opstelling heb je waarschijnlijk beide nodig — vaak in hetzelfde product, en vaak naast de Gateway API die je al draait.
Voor wie net begint: zet eerst de AI-gateway-laag op orde, want kosten en failover zijn meetbaar en leveren snel waarde. Bouw de agent-gateway-governance uit zodra je meer dan één agent of meerdere MCP-servers in productie hebt. Werk je al met agent-configuratie als infrastructuur? Dan sluit dit naadloos aan op hoe Microsoft APM agent dependencies beheert als softwarepakketten.
Vraag jezelf bij elke beslissing af: gaat dit over modelkosten en routing, of over welke agent wat mag en hoe ik dat audit? Het antwoord vertelt je welke gateway je nodig hebt.