Azure AI Foundry Threads: zo maak je AI klaar voor de enterprise

Wie een AI-agent in Azure AI Foundry inzet, start niet zomaar een groot taalmodel. De agent draait in een beheerde runtime waarin elk bericht, elke tool-aanroep en elke stap wordt gelogd en getraceerd. Daardoor wordt een experiment controleerbaar en zakelijk inzetbaar.

In dit artikel lees je hoe de bouwstenen samenhangen: de agent met model, instructies en tools, de threads als logboek, de runs en run steps als uitvoeringsspoor, en de beveiligde toolkit eromheen. Zo zie je waarom Foundry geschikt is voor productie, voor zowel ontwikkelaars als compliance-teams.

Azure AI Foundry agents: een teamleider met model, instructies en tools

Een agent in Foundry is geen chatvenster waarin iemand wat zit te typen. Het is eerder een veldkapitein die is gebouwd voor missies met een duidelijk ontwerp. Dat ontwerp bestaat uit drie kernelementen, en een Azure AI agent is er expliciet uit opgebouwd.

Het model: het brein

Het model verzorgt redenering en taal. Het ontleedt menselijke taal, plant stappen en stelt antwoorden op. Je zit daarbij niet vast aan één model: in de Foundry-catalogus kun je wisselen. Denk aan GPT-4 voor complexe strategie, een lichter model voor eenvoudige taken, of bijvoorbeeld Mistral of DeepSeek. Jij kiest wat bij de opdracht past.

De instructies: de missiebriefing

De instructies verankeren het model in de resultaten die je werkelijk nodig hebt. Voorbeelden zijn: haal gegevens uit een contractenset en rapporteer de resultaten terug in een specifiek formaat. Zo blijft de agent in lijn en voorspelbaar. De instructies werken als een vast reglement dat gevolgd moet worden.

De tools: de uitrusting

Tools geven de agent specialisatie: code-uitvoering, zoekconnectoren, rapportage-API's of elk extern systeem dat je koppelt. Een code interpreter voert analyses uit. Een SharePoint- of MCP-connector voert live data in het plan. De toolset kun je beperken of uitbreiden, afhankelijk van de use case.

In veel chat-API's krijg je alleen een model en een prompt. Er is dan geen formeel besef van opdrachten of tool-orkestratie. De Foundry agent-service garandeert dat alle drie de lagen aanwezig zijn. Het resultaat is een agent die niet improviseert, maar een opdracht uitvoert met logs en controlepunten.

Threads in Azure AI Foundry: het persistente logboek

Een thread is geen vluchtig chatvenster dat verdwijnt zodra je het sluit. Het is een persistente conversatiesessie. Elke uitwisseling wordt opgeslagen, of die nu van jou komt, van de agent of van een andere agent in een multi-agentopstelling. De geschiedenis blijft lang na afloop van het gesprek beschikbaar.

Threads zijn bovendien gestructureerde containers. Ze regelen automatisch het afkappen van de context, zodat de actieve context binnen de limieten van het model blijft en er toch een volledige audit trail bewaard blijft. De agent behoudt het overzicht over het gesprek, terwijl het bedrijf een permanent, controleerbaar archief houdt. Je krijgt dus continuïteit voor de agent en governance voor de organisatie.

Wat een bericht bevat

Een thread is opgebouwd uit berichten. Die bestaan niet alleen uit platte tekst, maar kunnen ook een afbeelding, een spreadsheet of een blok gegenereerde code bevatten. Elk bericht heeft een tijdstempel en een rol (gebruiker of assistent). Je ziet dus wat er is gezegd, wie het zei, wanneer het gebeurde en welk type inhoud erbij hoorde.

Stel je een compliance officer voor die een dossier opent. Die ziet het exacte verzoek van gisteren, het antwoord van de agent en het tijdstip van beide gebeurtenissen. Het is te vergelijken met het notitieblok in een Dungeons & Dragons-campagne: omdat alles is vastgelegd, verdwijnen discussies over vergeten details.

Waarom dit ertoe doet

• Audit en compliance: toezichthouders en interne auditteams zien de volledige reeks: het verzoek, het antwoord, de gebruikte tools en het tijdstip.
• Debuggen: ontwikkelaars kunnen een thread terugspoelen naar het moment van de vraag en precies zien hoe een foutieve uitkomst ontstond.
• Multi-agentsystemen: ook de interactie tussen agents die samen taken verdelen wordt vastgelegd.

Runs: het moment waarop de agent aan het werk gaat

Het verschil is eenvoudig: threads onthouden, runs handelen. Een thread bevat de gespreksgeschiedenis, de opdrachten en de context. Een run is de trigger die de agent die context laat nemen en daadwerkelijk uitvoeren. Je thread kan bijvoorbeeld de opdracht bevatten om een CSV-bestand te analyseren of een lijngrafiek te tekenen. Pas de run verwerkt dat verzoek via de modelinstructies en tools. De agent kan dan extra data ophalen, berekeningen maken of de code interpreter aanroepen om een artefact te genereren.

Een run is geen black box, maar een gemonitorde uitvoering met statusregistratie. Doorgaans zie je de volgende statussen:

1. in de wachtrij
2. in uitvoering
3. vereist actie
4. voltooid
5. mislukt

SDK-voorbeelden pollen deze statussen vaak in een lus. Zo weet je niet alleen wat er gebeurt, maar ook wanneer.

Run steps: schaaknotatie voor AI

Een antwoord kan er prima uitzien en toch kun je niet zien of de agent een externe API aanriep, code schreef of gewoon wat tekst improviseerde. In een zakelijke omgeving is die ondoorzichtigheid riskant. Het is alsof je halverwege een schaakpartij binnenloopt en hoort dat de juiste zetten zijn gedaan, zonder dat je het kunt narekenen.

Run steps nemen dat giswerk weg. Elke run wordt stap voor stap vastgelegd: welke modeloutput is gegenereerd, welke tools zijn aangeroepen, welke berekeningen zijn uitgevoerd en welke berichten zijn geproduceerd. Je kunt het zien als schaaknotatie voor AI: bestand ophalen, codeblok uitvoeren, grafiekartefact teruggeven, elk met een tijdstempel en in volgorde.

Voordelen voor ontwikkelaars

Zonder run steps kijk je naar een eindantwoord zonder te weten hoe het tot stand kwam. Was de zoekopdracht fout? Is er een rekenfout ingeslopen? Met run steps scroll je door de tijdlijn, zie je waar het misging en herstel je het. Debuggen wordt zo forensisch onderzoek in plaats van gissen.

Voordelen voor compliance en operatie

Als auditors vragen hoe een samenvatting tot stand is gekomen, hoef je het redeneren van het model niet abstract uit te leggen. De tool-aanroep, de interpretatiestap en het samengestelde antwoord zijn allemaal van een tijdstempel voorzien. Je toont bewijs in plaats van verhalen. Voor de dagelijkse operatie betekent dit reproduceerbare patronen: een workflow kun je opnieuw uitvoeren en een betwist resultaat kun je opnieuw afspelen.

Samen vormen ze de levenscyclus van de agent: threads als dagboek, runs als activering en run steps als gedetailleerd logboek.

Tools in Foundry: van woorden naar daden

Tools maken van een agent een werknemer in plaats van een kletskous. In plaats van alleen te beschrijven hoe je een document controleert of een berekening uitvoert, doet de agent het en geeft hij de output terug. Foundry kent drie categorieën.

1. Ingebouwde tools

Denk aan de Code Interpreter, Bing Search, SharePoint- en Microsoft Fabric-connectoren en Azure AI Search. Daarmee analyseert de agent data, haalt hij bestanden op, doorzoekt hij bedrijfscontent en genereert hij grafieken of rapporten zonder maatwerk.

2. Eigen tools via OpenAPI en MCP

Je kunt eigen tools registreren via OpenAPI-specificaties of via het Model Context Protocol (MCP). MCP wordt gezien als de USB-C voor AI-tools. Bij het koppelen van agents aan remote MCP-servers regelt het systeem automatisch tooldetectie, versiebeheer en aanroepen. Dat verlaagt de integratielast aanzienlijk, zeker als je omgeving uit tientallen onderling verbonden systemen bestaat.

3. Observeerbare tool-aanroepen

Elke aanroep wordt op stapniveau gelogd, met identiteit, invoer, uitvoer en tijdstempels. Je kunt dus precies zien wat is aangeroepen, bevestigen dat de juiste machtigingen zijn gevolgd en permanente records bewaren voor compliance.

Een voorbeeld uit de quickstart: je uploadt een CSV-bestand als bericht in een thread. De agent roept binnen zijn run steps de code interpreter aan, verwerkt het bestand en genereert een grafiek. Die komt terug als bijgevoegde afbeelding, direct zichtbaar in het thread-logboek. Je hoefde zelf geen parser of visualisatie te schrijven.

Enterprise-integratie en beveiliging

Tools kunnen koppelen aan Logic Apps, waardoor de agent toegang krijgt tot meer dan 1400 bestaande SaaS- en on-premises-connectoren. In plaats van adapters voor CRM-, ERP- of ITSM-platforms opnieuw te programmeren, configureer je op basis van connectoren die het bedrijf al gebruikt. Eén agent kan zo veilig werken in een breed landschap zonder kwetsbare API-bruggen.

Beveiliging zit in de kern. Wanneer tools verbinding maken met systemen als SharePoint of Fabric, gebeurt dat via on-behalf-of-authenticatie, bemiddeld door Microsoft Entra. Had je gisteren geen toestemming om een bestand te lezen, dan omzeilt de agent die barrière vandaag niet. Identiteit en machtigingen blijven intact, en dat is de voorwaarde waaronder compliance-teams hun goedkeuring geven. Daarbij blijft elke aanroep traceerbaar: wie riep aan, wat is verzonden en wat is ontvangen.

Veelgemaakte fouten en stolpersteine: wat er misgaat zonder structuur

Het risico van AI zonder deze lagen is concreet:

• Inconsistente resultaten: de ene contractsamenvatting zegt iets anders dan de volgende, omdat instructies en vaste kaders ontbreken.
• Verlies van traceerbaarheid: geen enkel logboek legt vast hoe een antwoord tot stand kwam.
• Debuggen als gissen: ontwikkelaars kunnen de redenering niet volgen.
• Bewijs via screenshots en herinneringen: dat houdt geen stand wanneer compliance bewijs vraagt of support een bug moet reproduceren.
• Alleen praten, niet werken: zonder verantwoord gekoppelde en betrouwbaar gelogde tools blijft een agent een chatsessie die veel zegt maar het werk niet doet.

In een onderneming is dit geen kleine ergernis. Het is een reëel risico dat vertrouwen en adoptie blokkeert. Foundry pakt dit aan met ingebouwde veiligheidsmechanismen, instructies als reglement, een aanpasbare toolset en een model dat vrij te wisselen is binnen een structuur die verantwoording afdwingt.

Praktische takeaways

• Ontwerp elke agent met drie lagen: een passend model, duidelijke instructies en een bewust gekozen toolset.
• Gebruik de modelcatalogus om per taak het juiste model te kiezen, bijvoorbeeld zwaarder voor complexe strategie en lichter voor eenvoudige taken.
• Zie threads als je audit trail: ze bewaren berichten met rol, tijdstempel en inhoudstype, ook bij multi-agentopstellingen.
• Gebruik runs en hun statussen om de uitvoering te monitoren, bijvoorbeeld door de status in een lus te pollen.
• Gebruik run steps om te debuggen en om auditors bewijs te geven van tool-aanroepen en tussenstappen.
• Start met de ingebouwde tools en breid uit met OpenAPI of MCP als je eigen systemen wilt koppelen.
• Laat toegang lopen via Microsoft Entra, zodat identiteit en machtigingen intact blijven.
• Begin klein: start een testproject, maak een basisagent, draai een thread en inspecteer de run steps in de SDK of de portal om te bevestigen dat je logs overeenkomen met het verhaal.

Fazit

Azure AI Foundry is meer dan prompts naar een model sturen. Het biedt een herhaalbare manier om agents te bouwen met een brein, een regelboek en een toolkit, waarbij elke actie wordt vastgelegd in threads, runs en run steps. Voor devleads en compliance-medewerkers is de kernboodschap hetzelfde: reproduceerbare, auditeerbare uitvoering met volledig inzicht in de levenscyclus van de agent. Zo wordt AI een verantwoordelijke teamgenoot wiens acties je kunt traceren, testen en verdedigen.