Een team loopt tegen een taak aan die nét te complex is voor hun Copilot-agent. De agent begrijpt de vraag niet meer of mist de rechten voor het juiste systeem en niemand weet goed hoe dat is op te lossen. Dat is het moment waarop de meeste organisaties vastlopen. Niet bij de eerste agent die ze bouwen.
Bijna elke organisatie begint bij Copilot Studio. Terecht, want binnen een middag staat er een werkende agent zonder één regel code. Het probleem is niet die eerste stap. Het probleem is dat de meeste organisaties daar te lang blijven hangen.
Wij zien het steeds opnieuw gebeuren. Een team bouwt een prima werkende Copilot-agent. Een paar maanden later botst het tegen een taak die net iets complexer is. Vervolgens probeert het team die alsnog met workarounds in dezelfde visuele flow te proppen, in plaats van over te schakelen op een hosted agent. Dat is een agent die je zelf met code bouwt in plaats van via een visuele flow.
We beginnen simpelweg te snel met wat op dat moment de snelste oplossing lijkt. Maar niets is zo permanent als een tijdelijke oplossing. Dat kost tijd, geld en een hoop frustratie die te voorkomen was.
Copilot-agent: Je bouwt de agent visueel in Copilot Studio of Agent Builder. Je stelt instructies in, koppelt kennisbronnen en standaardconnectors en de agent draait. Rechten en toegang lopen daarbij grotendeels automatisch mee met de bestaande Microsoft 365-omgeving.
Het verschil zit niet in welke agent beter is. Het zit in wie de regie heeft. Bij een Copilot-agent legt het platform grenzen op in ruil voor snelheid. Bij een hosted agent bepaal je zelf hoe de agent zich gedraagt, in ruil voor meer verantwoordelijkheid.
Er is een simpele vuistregel om te bepalen welke route past: niet hoe belangrijk het proces is, maar of er een kant-en-klare connector voor bestaat.
Zolang een use case leunt op standaardconnectors, zoals SharePoint, Outlook, Dynamics of een handvol veelgebruikte SaaS-koppelingen, is een Copilot-agent meestal ruim voldoende. Een proces is 'standaard' zodra het weinig afwijkt van hoe andere organisaties werken. Bijvoorbeeld een vraag beantwoorden op basis van een SharePoint-document of een ticket aanmaken in Dynamics. Het platform heeft die integratie al gebouwd, getest en beveiligd. Jij hoeft alleen te configureren.
Zodra dat niet meer volstaat, wordt een hosted agent relevant:
Hoe complexer en specifieker de use case, hoe sneller die standaardconnectors tekortschieten.
Microsoft zet Copilot Studio meestal neer als het startpunt voor bijna alles, met hosted agents als uitzondering voor de zware gevallen. Wij zien in de praktijk het tegenovergestelde. Teams proberen te lang binnen Copilot Studio te forceren wat eigenlijk code nodig heeft. Omdat overstappen op code voelt als een grotere stap dan het in werkelijkheid is.
Waarom? Low-code voelt als de veilige keuze. Er is geen infrastructuur nodig, geen architectuurbeslissing, geen team dat de agent moet onderhouden. Maar bij elke complexere use case betaal je die schijnbare eenvoud later terug. In workarounds, in trage foutafhandeling, in een agent die net niet kan wat de business nodig heeft. Wij geloven dat het verstandiger is om meteen voor een hosted agent te kiezen zodra een use case ook maar één van de bovenstaande punten raakt. Niet omdat het spannender is, maar omdat je jezelf dan niet twee keer laat bouwen.
Een klant beoordeelt regelmatig grote aantallen beleidsdocumenten. Deze beleidsdocumenten handmatig doorlopen en toetsen aan de eisen kostte per klant veel te veel tijd. Dat schaalde simpelweg niet.
Een Copilot-agent werkte hier niet. De documenten kwamen in wisselende formaten binnen, van gescande pdf’s tot Word-bestanden. Een Copilot-agent kan alleen tekst uitlezen die al doorzoekbaar is. Een gescande pdf is in de basis een afbeelding, geen tekst. Daarvoor is eerst OCR nodig om de tekst uit te lezen. Voor die stap bestond geen standaardconnector. Een connector was hier bovendien niet genoeg. Een connector haalt data op, maar doet geen OCR of inhoudelijke toetsing. Wij bouwden een tool op Microsoft Foundry, met Mistral OCR voor het verwerken van de documenten en Azure PromptFlow (depreciatie vanaf april 2027) voor de logica die beleidsdocumenten daadwerkelijk toetst aan de vereisten. Dat vereist eigen bedrijfslogica die meerdere bronnen combineert. Precies het type taak waarop een visuele flow vastloopt.
Een agent is zo goed als de data waar hij bij kan. Bij een Copilot-agent zit die toegang grotendeels vast aan de kennisbronnen die het platform ondersteunt. Handig voor veelvoorkomende scenario's. Maar beperkt zodra je data uit meerdere, ongelijksoortige systemen wil combineren.
Microsoft heeft voor hosted agents een oplossing gebouwd: Foundry IQ, een gedeelde kennislaag die niet aan één specifieke agent vastzit. In plaats van dat elke agent zijn eigen retrieval-logica krijgt, richt je een kennisbank in rond een onderwerp, bijvoorbeeld personeelsbeleid of klantcontracten, en koppelt meerdere agents tegelijk daarop aan.
Dit betekent een paar dingen:
Meerdere bronnen, één kennisbank. Foundry IQ combineert data uit onder andere SharePoint, OneLake, Azure Blob Storage, Azure AI Search, het open web en, in preview, MCP-bronnen.
Dit is waar het verschil met een Copilot-agent het grootst wordt. Een hosted agent is niet zomaar ‘dezelfde agent, maar dan met code’. Het is een ander soort bouwwerk, met mogelijkheden die in een visuele flow simpelweg niet bestaan.
Meerdere agents die samenwerken. In plaats van één agent die alles moet kunnen, verdeel je taken over gespecialiseerde agents die onderling communiceren. Microsoft Agent Framework ondersteunt multi-agent-orchestratie als stabiel onderdeel van het platform. Inclusief patronen waarbij een coördinerende agent werk verdeelt over subagents.
Geheugen dat verder gaat dan één gesprek. Foundry Agent Service ondersteunt drie soorten geheugen. Sessiegeheugen binnen één gesprek, gebruikersgeheugen dat voorkeuren onthoudt over meerdere sessies heen en procedureel geheugen, waarmee een agent leert hoe hij een taak het beste uitvoert op basis van eerdere runs. Vroege metingen laten hierbij verbeteringen van 7 tot 14 procent in succesratio zien, tegen nauwelijks hogere kosten. Ook hier geldt: dit zijn Microsofts eigen cijfers.
Vaste taken en langlopend werk. Naast interactieve gesprekken kunnen hosted agents ook routinematig werk oppakken. Denk aan geplande taken of langlopende processen die niet passen binnen één simpele vraag-antwoordinteractie.
Volledige inzage. Elke modelaanroep, toolaanroep en overdracht tussen agents loopt door één tracing pipeline. Daarmee zie je precies waar een agent vastloopt. Je hoeft dus niet te gissen naar de oorzaak op basis van het eindresultaat.
Eigen modellen en finetuning. Waar een Copilot-agent werkt met de modellen die het platform aanbiedt, kun je bij een hosted agent modellen finetunen op je eigen data of open-sourcemodellen hosten via Managed Compute.
Elke hosted sessie krijgt automatisch een eigen identiteit binnen Entra. Krachtig, want een agent kan net als een medewerker eigen herkenbare toegang krijgen tot precies de systemen die nodig zijn. Maar die identiteit staat niet standaard goed ingesteld. Je moet die inrichten.
In de praktijk bouwt een team bijvoorbeeld een hosted agent voor vragen over openstaande facturen. De agent werkt, de antwoorden kloppen, iedereen is tevreden. Wat niemand controleert, is welke rechten die agent bij het aanmaken heeft meegekregen. Is de scope beperkt tot de factuurtabel of kan de agent via een breed geconfigureerde serviceverbinding ook bij salarisgegevens of klantcontracten? Het antwoord op de gestelde vraag klopt, dus niemand gaat op zoek naar een probleem dat niet zichtbaar is.
Bij een Copilot-agent is dit risico kleiner. Niet omdat het probleem niet bestaat, maar omdat het platform het grotendeels voor je afvangt via standaardconnectors. Bij een hosted agent verschuift die verantwoordelijkheid naar het team dat bouwt. Dat is een eerlijke ruil: code geeft je vrijheid en vrijheid vraagt om discipline. De oplossing zit niet in extra tooling, maar in een vaste stap bij elke hosted agent. De identiteit en rechten expliciet ontwerpen voordat de agent wordt gebouwd, net zoals je dat bij een nieuwe medewerker zou doen.
Het belangrijkste verschil met een jaar geleden is dat dit geen twee losse platformen meer zijn. Een hosted agent kun je alsnog rechtstreeks publiceren naar Microsoft 365 Copilot en Teams, met dezelfde identiteit, rechten en hetzelfde beleid als een Copilot-agent. De keuze tussen low-code en code bepaalt vooral hoeveel controle en verantwoordelijkheid je nodig hebt. Niet in welk ecosysteem de agent uiteindelijk terechtkomt.
De keuze tussen een Copilot-agent en een hosted agent komt neer op één vraag: past de taak binnen de standaardregels van het platform of niet? In het laatste geval is code niet de zwaardere optie, maar de enige optie die het probleem daadwerkelijk oplost.
Bij yellow arrow helpen we organisaties bij juist die afweging: welke route past bij welke taak en hoe voer je die keuze verantwoord uit?
Concreet betekent dit dat wij:
Samen met jou bepalen of een taak zich leent voor een Copilot-agent, een hosted agent of een groeipad van het een naar het ander.
De architectuur en code opzetten zodra een hosted agent de juiste keuze is, inclusief de identiteit en rechten van de agent.
Zorgen dat de overstap van prototype naar productie beheersbaar blijft, zonder verrassingen achteraf.
Jouw team begeleiden, zodat het zelf verder kan bouwen en beheren.
Benieuwd welke route bij jouw organisatie past? Stuur ons een mail met jouw situatie. Dan denken we met je mee.