AI-agents beheren over meerdere platforms

Gebouwd voor snelheid: ~10ms latentie, zelfs onder belasting
De razendsnelle manier om je modellen te bouwen, volgen en implementeren!
- Verwerkt 350+ RPS op slechts 1 vCPU — geen tuning nodig
- Productieklaar met volledige enterprise-ondersteuning
De meeste bedrijven hebben niet bewust besloten om AI-agents op vijf verschillende platforms te omarmen. Het is hen overkomen. Microsoft Copilot werd geïntroduceerd in de productiviteitssuite. ServiceNow voegde Now Assist toe aan de ticketwachtrij. Salesforce activeerde Agentforce binnen de CRM. Andere data- en SaaS-platforms begonnen agents uit te voeren naast hun basissystemen. Elk platform bracht zijn eigen AI-runtime mee — en, in alle stilte, zijn eigen governance-verhaal dat ophoudt bij de grens van het platform.
Het resultaat is een governance-gat dat voor een afzonderlijke leverancier van een applicatieplatform moeilijk alleen te dichten is. Wanneer een agent binnen het ene platform een API aanroept, wie heeft daarvoor toestemming gegeven? Wanneer een agent in een ander platform een vertrouwelijk document samenvat, welk beleid bepaalde dan de reactie? En wanneer een agent zich in productie misdraagt, wie kan deze dan snel insluiten — zonder te hoeven schakelen tussen meerdere beheerdersconsoles of supportwachtrijen van verschillende leveranciers?
Dit is geen risico voor de toekomst. Het is de operationele realiteit voor elke organisatie die onafhankelijk van elkaar meer dan één AI-platform heeft omarmd — wat steeds vaker voorkomt binnen grote ondernemingen.
De omvang van het probleem
Voordat we praten over een oplossing, is het goed om precies te begrijpen waarom dit echt ingewikkeld is. Het probleem is structureel van aard en uit zich op vier punten tegelijk.
En er is een vijfde probleem dat pas zichtbaar wordt op het moment dat een gebruiker daadwerkelijk iets probeert te doen met een agent van een derde partij: de inloggegevensbelasting.
De verborgen inloggegevensbelasting
Neem een alledaagse prompt die wordt gestuurd naar een officiële agent van een derde partij, geïnstalleerd binnen een assistent in Copilot-stijl. De eerste keer dat een gebruiker ermee werkt, kan de agent pas antwoorden nadat de gebruiker zich rechtstreeks heeft aangemeld bij die externe dienst.

Dit is geen fout. Het is de enige veilige architectuur wanneer elke agent een afzonderlijk geleverd product is. Maar opgestapeld over de volledige toolinventaris van een onderneming heeft dit concrete operationele gevolgen:
- Wrijving per gebruiker en per tool. Elke medewerker moet elke agent opnieuw autoriseren bij het eerste gebruik. Vermenigvuldig dat met het aantal werknemers en vervolgens met de toolinventaris.
- Wildgroei van tokens. OAuth-tokens voor elke verbonden dienst raken verspreid over identiteitsregisters van gebruikers. Compliance wordt een kwestie per leverancier in plaats van één centraal auditspoor.
- Geen centrale intrekking. Wanneer een contract verandert eller een incident het intrekken van toegang vereist, moet de organisatie dit bij elke leveranciersrelatie afzonderlijk regelen in plaats van via één centraal controlepunt.
Hoe een cross-platform control plane kan werken
Een architectuurpatroon dat dit gat rechtstreeks dicht, is beheren op de laag die al deze platforms gemeen hebben. Elke agent, ongeacht welk platform deze host, voert uiteindelijk een LLM-call of een tool-call uit. Onderschep en beheer daar, en u beheert de agentactiviteit die via die gedeelde uitvoeringslaag loopt — zonder dat elk applicatieplatform zichzelf opnieuw hoeft op te bouwen.
Dit is het uitgangspunt achter de Agent Gateway van TrueFoundry: een toegewijde controlelaag voor AI-agents in productie, geplaatst voor de modellen en tools waarvan elke agent afhankelijk is. TrueFoundry trekt een scherpe grens tussen een AI gateway, die statusloze prompts en tokens beheert, en een agent gateway, die fungeert als het datavlak voor agentische AI — statusvolle sessies, uitvoering in meerdere stappen en de data die beweegt tussen agents en hun tools. Het werkt als een service mesh die specifiek is gebouwd voor agentische systemen.
Boven de gateways bevindt zich een vierde laag: de Agent Harness. Een harness is de runtime rond een LLM — de orchestratieloop die plannen maakt, tools aanroept, context beheert, gevoelige acties afschermt via goedkeuringen en elke stap vastlegt in een trace. Het is wat een model-call verandert in een betrouwbare, langlopende agent.

TrueFoundry levert dit als een beheerde dienst in plaats van als een framework. Een geisoleerde uitvoeringsomgeving (sandbox) voert code en langlopende taken uit. Human-in-the-loop goedkeuringsstappen pauzeren gevoelige tool-calls totdat een gebruiker toestemming geeft. Een versiebeheerd Skills Registry bevat herbruikbare instructies met RBAC. En cruciaal — API-sleutels of inloggegevens leven nooit in agentdefinities; ze bevinden zich in de gateways, waar platformteams de toegang één keer configureren en ontwikkelaars van agents nooit in aanraking komen met geheimen.

Het ontdekken van agents beperkt zich niet tot de agents die u op het platform zelf hebt gebouwd. Agents die elders draaien — op Bedrock, LangGraph, een aangepaste HTTP-dienst of het platform van een andere leverancier — worden in dezelfde inventaris geregistreerd als externe agents, met dezelfde metadata en dezelfde controles. De gefragmenteerde vloot verandert zo in één overzichtelijke kaart.

Vijf functionaliteiten om op te letten
Voor teams die evalueren hoe ze dit gat kunnen dichten, zijn de volgende vijf functionaliteiten het overwegen waard — inclusief een toelichting op wat elke functionaliteit onder de motorkap vereist.
Architectuur voor enterprise-omgevingen
Een control plane is alleen nuttig als deze zware belastingen kan verwerken zonder de bottleneck te worden die het juist moest wegnemen. TrueFoundry rapporteert prestaties die van belang zijn op enterprise-schaal:
Het draait volledig in uw eigen omgeving — VPC, on-premise, air-gapped of over meerdere clouds — zodat er geen data uw domein verlaat, met behoud van SOC 2-, HIPAA- en GDPR-naleving via een doordacht ontwerp. En omdat de onderliggende agent gateway een open-sourceproject van de Linux Foundation is, is de controlelaag geen propriëtaire black box en zit u niet vast aan het framework van één specifieke leverancier.
Dit vervangt uw investeringen in platforms niet
Een belangrijke verduidelijking, aangezien dit het meest gehoorde bezwaar is: beheren op de uitvoeringslaag betekent niet het vervangen van de platform-native tools die u al gebruikt. Als uw gevoelige gegevens van kenniswerkers zich in M365 bevinden, beheert een tool zoals Microsoft Agent 365 dat oppervlak goed — identiteit, data en distributie binnen het Microsoft-ecosysteem. Op basis van de lanceringsmaterialen van Microsoft en de openbare berichtgeving die beschikbaar was vanaf juni 2026, heeft Agent 365 zijn ontdekkingsoppervlak bij algemene beschikbaarheid (GA) via Registry Sync uitgebreid naar andere clouds, zoals AWS Bedrock en Google Gemini Enterprise — een geloofwaardige cross-cloud stap aan de ontdekkingszijde.
Op basis van diezelfde lanceringsmaterialen maakten de SaaS-platforms waarop een aanzienlijk deel van het enterprise-agentwerk tegenwoordig draait, geen deel uit van die initiële sync-scope — agents binnen Salesforce Agentforce en ServiceNow AI Agents, beide algemeen beschikbaar sinds 2024, vielen buiten de initiële dekking van Registry Sync, en beleidshandhaving voor elke gesynchroniseerde agent verloopt nog steeds via de eigen controles van Microsoft in plaats van die van het bronplatform. De dekking van connectors door Microsoft kan na verloop van tijd worden uitgebreid; lezers moeten de actuele lijst verifiëren voordat ze op dit detail vertrouwen. De uitvoeringslaag blijft een oppervlak dat elk platform daadwerkelijk deelt.

Waar te beginnen
De snelste manier om te bepalen of dit uw gat dicht, is door het te bewijzen op uw eigen verkeer, afgestemd op de functionaliteiten die vandaag de dag de meeste problemen veroorzaken:
- Implementeer de gateway in een sandbox-VPC en routeer een deel van het echte agentverkeer erdoorheen. Controleer de vertragingsmarge en de uitkomst van de traceerbaarheid.
- Registreer een handvol bestaande agents van ten minste twee verschillende platforms. Controleer de metadata en de geünificeerde inventaris.
- Definieer twee of drie cross-platform beleidsregels — een PII-filter, een snelheidslimiet, een tool-allowlist — en controleer of deze standhouden voor de geregistreerde/gerouteerde agents.
- Meet de tijd voor insluiting bij beheerde paden: van actie tot handhaving, met het auditlogboek om het te bewijzen.
⚠ Redactionele disclaimer Dit artikel is door TrueFoundry, Inc. gepubliceerd voor uitsluitend informatieve doeleinden, gebaseerd op een analyse van openbaar beschikbare documentatie van leveranciers vanaf juni 2026. Alle geuite standpunten zijn bedrijfsinzichten van TrueFoundry, niet die van individuele auteurs, en vormen geen professioneel, juridisch of aankoopadvies. Microsoft heeft dit artikel niet beoordeeld, goedgekeurd of gesponsord. Productfunctionaliteiten, prijzen en roadmaps kunnen zonder voorafgaande kennisgeving worden gewijzigd; getoonde cijfers zijn afkomstig uit openbare bronnen of zijn illustratieve diagrammen. Oorspronkelijke analyses, teksten en diagrammen zijn het eigendom van TrueFoundry, Inc.; alle productnamen en handelsmerken van derden zijn het eigendom van hun respectievelijke eigenaren. Verifieer alle informatie met de huidige documentatie van de leverancier voordat u architectuur- of aankoopbeslissingen neemt.
Bronnen
- Microsoft Learn — Overzicht van Microsoft Agent 365 (GA, de pijlers observeren / beheren / beveiligen).
- Microsoft Learn — Overzicht van Microsoft Agent 365 SDK.
- Windows Central — Aankondiging van Microsoft 365 E7-abonnement ($ 15/gebruiker/maand los; $ 99/gebruiker/maand in E7-bundle).
- De reikwijdte van Registry Sync waarnaar in dit artikel wordt verwezen, is gebaseerd op het openbare GA-materiaal van Microsoft en de berichtgeving uit die tijd vanaf juni 2026; lezers moeten de actuele lijst van connectors controleren in de documentatie van Microsoft voordat ze hierop vertrouwen.
- TrueFoundry — Agent Gateway productpagina (controlepijlers, statusvolle agent-mesh, 99.99% beschikbaarheid, 10B+ verzoeken/maand, ~30% kostenoptimalisatie, Linux Foundation-project, VPC / on-premise / air-gapped implementatie).
- TrueFoundry Docs — AI Gateway (1.000+ LLM's, vertragingsmarge) en Overzicht van Agent Harness (beheerde runtime, sandbox, HITL-goedkeuringen, Skills Registry, credential-model zonder sleutels).
TrueFoundry AI Gateway levert een latentie van ~3–4 ms, verwerkt 350+ RPS op 1 vCPU, schaalt moeiteloos horizontaal en is klaar voor productie, terwijl LiteLLM last heeft van hoge latentie, moeite heeft boven een gemiddeld aantal RPS, geen ingebouwde schaling heeft en het meest geschikt is voor lichte workloads of prototypes.















.png)

.webp)



.webp)








.webp)





