Lessen uit de inzet van een multi-agent analytische assistent op Databricks
Onze reis
Toen onze klant vroeg om een AI-assistent die zakelijke vragen over categoriemanagement kon beantwoorden, begonnen we eenvoudig: één agent met een uitgebreide prompt en toegang tot de gegevens. Vergelijkbaar met ChatGPT, Gemini of Claude.
Het werkte niet.
De enkele agent werd een manusje-van-alles, meester in niets. Met een grote prompt die het hele domein probeerde te bestrijken en talloze op maat gemaakte gegevenstools tot zijn beschikking, had hij moeite om voor elke vraag de juiste aanpak te kiezen. Simpele vragen werden beantwoord met onnodige complexiteit. Complexe vragen werden oppervlakkig behandeld en de agent was niet in staat om meerdere tools na elkaar te gebruiken.
Dus hebben we het herbouwd als een multi-agent systeem: Een ’team’ van gespecialiseerde agenten georkestreerd door een coördinator, die elk een afzonderlijk analytisch domein behandelen.
Twee maanden later hebben we een systeem dat alles afhandelt, van“toon me de top 3 performers” tot“waarom is onze conversieratio gedaald en wat moeten we eraan doen?”.
En het werkt. Zakelijke gebruikers kunnen nu complexe analytische query’s uitvoeren die vroeger uren handmatig werk vereisten. Maar het was een hele reis om hier te komen en we hebben veel lessen geleerd die we graag willen delen.
De architectuur: Eén stem, veel specialisten
Toen we de architectuur opnieuw bekeken, kwamen we al snel uit op wat we het woordvoerderpatroon noemen: slechts één agent praat ooit met mensen. In principe volgt het dit patroon:
Gebruikersvraag
↓
[Coördinator] → Classificeert, wijst taken toe
↓
[Gespecialiseerde agenten] → Stil parallel werken
↓
[Coördinator] → Syntheseert bevindingen in één antwoord
↓
Gebruiker ontvangt één samenhangend antwoord
Onze prototype coördinator laat elke agent reageren en delen in één massale reactie.
Het landde niet goed. Het antwoord was erg gedetailleerd, lang en vol tegenstrijdigheden.
De Store Agent zou zeggen,“Duitsland is je beste markt“, terwijl de Category Agent zou zeggen,“Nederland laat de grootste groei zien“. Technisch gezien zijn beide correct (verschillende statistieken), maar dit brengt gebruikers in verwarring.
De les: gebruikers ervaren je systeem als één geheel. Meerdere stemmen zorgen voor verwarring, zelfs als elke stem nauwkeurig is. De coördinator moet synthetiseren, niet doorgeven.
Agenten en hulpmiddelen: Een korte verduidelijking van de terminologie.
In deze context is een agent een LLM met een specifieke rol en instructies. Maar agenten kunnen alleen redeneren en tekst genereren. Om daadwerkelijk dingen te doen, zoals een database bevragen of gegevens ophalen, hebben ze hulpmiddelen nodig.
Tools zijn functies die de agent kan aanroepen: een SQL query executor, een data retrieval API en een rekenfunctie. Als we zeggen dat een LLM goede “tool-calling” mogelijkheden heeft, bedoelen we dat het betrouwbaar weet wanneer een tool moet worden gebruikt, welke tool moet worden gebruikt en hoe het verzoek correct moet worden geformatteerd.
Onze agents denken niet alleen na over gegevens. Ze raadplegen actief databases, halen meetgegevens op en voeren berekeningen uit. Als het aanroepen van tools onbetrouwbaar is, kan de agent een antwoord hallucineren in plaats van het op te halen, of de verkeerde functie helemaal aanroepen. Het was essentieel om dit goed te doen om een systeem te bouwen waarop gebruikers kunnen vertrouwen.
Uitdagingen die we hebben opgelost
Natuurlijk kwamen we tijdens de ontwikkeling en validatie uitdagingen tegen. Na vele iteraties en versies denken we dat dit de top 3 is:
- Hallucinaties temmen met temperatuur
Als agenten gegevens niet zuiver kunnen ophalen, schatten ze in. En ze vertellen je niet dat ze schatten.
We zagen gevallen waarin een agent een metriek rapporteerde en vervolgens dezelfde metriek twee keer zo hoog noemde in de volgende. Niet omdat de gegevens veranderden, maar omdat de agent de berekening niet goed kon uitvoeren en plausibel klinkende getallen begon te verzinnen.
De oplossing was eenvoudig: verlaag de temperatuur drastisch. De temperatuur bepaalt hoe “creatief” het model is. Hogere waarden produceren meer gevarieerde uitvoer, lagere waarden houden het feitelijk. Wij werken met 0,1. Voor analytisch werk wil je geen creativiteit; je wilt dat het model zich houdt aan wat de gegevens werkelijk zeggen. In combinatie met een strikte handhaving op het gebruik van gereedschap, heeft dit het probleem opgelost.
- Agent loops voorkomen
Multi-agent systemen kunnen in loops terechtkomen. Agent A vraagt om opheldering, Agent B geeft die, Agent A vraagt opnieuw. Zonder beveiligingen kunnen systemen minutenlang draaien, tokens verbranden en niets produceren.
Vier mechanismen die samenwerken hebben dit opgelost:
- Een harde grafiekrecursielimiet
- Zachte iteratielimieten per vraag
- Detectie van dezelfde agent die herhaaldelijk wordt uitgevoerd
- Expliciete “geen taken meer in behandeling” controles
Elke laag vangt verschillende faalwijzen op. Verwijder er één en de lussen keren terug.
- Gereedschapsresultaten isoleren
Hier is een subtiele bug die wat tijd kostte om te diagnosticeren: Agent A voert een database query uit, krijgt resultaten. Agent B ziet die resultaten in de gedeelde berichtgeschiedenis, raakt in de war en voert een soortgelijke query uit met andere parameters. De resultaten waren samengesteld en de analyse werd inconsistent.
De oplossing: elke agent handelt zijn tools intern af, waarbij de resultaten nooit in de gedeelde staat komen. Agenten retourneren hun bevindingen (samengestelde tekst), niet hun proces (ruwe query resultaten). Schone scheiding, schone resultaten.
3 belangrijke tips
- Specialisatie boven generalisatie
Elke agent met een gericht domein, duidelijke verantwoordelijkheden en een beheersbare set hulpmiddelen presteert veel beter dan één agent (of een paar) die alles probeert te doen. De coördinatieoverhead is het waard.
Onze zwerm agenten bezit elk een specifiek analytisch domein: winkelprestaties, categorietrends, anomaliedetectie, prijsanalyse, promoties en meer. Als een vraag meerdere domeinen beslaat, stuurt de coördinator deze door naar de relevante specialisten en synthetiseert hun bevindingen.
- Snel pad voor eenvoudige vragen
Onze eerste versie voerde alle agenten uit voor elke vraag.“Wat is het topmerk?” activeerde anomaliedetectie, prijsanalyse en levenscyclusbeoordeling. Dat zijn meer dan 30 seconden verwerking voor een antwoord van 2 seconden.
We hebben fast-path detection geïmplementeerd: eenvoudige vragen slaan de volledige orkestratie over en gaan direct naar een enkele relevante agent. De responstijden daalden aanzienlijk voor eenvoudige vragen.
Het raffinement van je antwoord moet overeenkomen met het raffinement van de vraag.
- Domeinkennis in elke agent
Generieke LLM’s begrijpen uw bedrijf niet. We wisten dit al, en we zagen het bij huismerken: de eigen merken van onze klanten hebben geen externe concurrenten, dus ze tonen altijd de “beste concurrentiepositie”. Vroege versies rapporteerden trots deze betekenisloze metriek.
Elke agent had expliciete instructies nodig over bedrijfsspecifieke eigenaardigheden: welke entiteiten uit te sluiten van concurrentieanalyse, wat “prestatie” betekent in verschillende contexten, en wanneer ontbrekende gegevens duiden op een probleem versus verwacht gedrag.
Je kunt geen bruikbare bedrijfs-AI maken zonder zakelijk inzicht te coderen.
Hoe kies je het juiste model?
Modelselectie is belangrijker dan we aanvankelijk dachten. Niet alle LLM’s zijn gelijk als het gaat om tool-calling en analytisch redeneren.
We gebruiken de Claude-modellen van Anthropic via Databricks’ model serving.
We zijn begonnen met Claude Sonnet 4.5 en onlangs overgestapt op Claude Opus 4.5. Vergeleken met andere LLM’s die beschikbaar zijn in Databricks, vielen Claude’s betrouwbaarheid en analytische mogelijkheden op. Wanneer je agents consistent de juiste database queries moeten selecteren en moeten redeneren over de resultaten, dan zijn deze verschillen van belang.
Geschikt voor het doel
Niet elke agent heeft het krachtigste model nodig. Bedenk wat elke agent eigenlijk doet:
- Complexe redeneertaken (diagnostiek, aanbevelingen): profiteren van een capabel model zoals Opus
- Eenvoudig opvragen (eenvoudige opzoekingen, gegevens ophalen): een lichter model kan volstaan
- Hoog-volume toepassingen: kosten tellen snel op met premium modellen
We hebben dit nog niet volledig geoptimaliseerd, maar er is ruimte om modellen te mixen op basis van de complexiteit van de agent.
Limieten en kosten van tokens
Multi-agent systemen verbruiken tokens snel. Elke agent verwerkt context, tool calls worden opgeteld en de coördinator synthetiseert alles. Met een zwerm agenten die mogelijk bijdragen aan een enkele reactie, kan het tokengebruik hoog oplopen. En elk model heeft een tokenlimiet per sessie en per dag.
Databricks rekent in DBU’s (Databricks Units) en de kosten voor modelservices schalen met het gebruik. Monitor dit vroegtijdig. Je kunt tokens per agent bijhouden om te begrijpen waar het verbruik plaatsvindt en waar optimalisatie zou kunnen helpen.
De balans is altijd tussen mogelijkheden en kosten. Een beter model kan bij de eerste poging een goed antwoord geven, terwijl een goedkoper model misschien nog een keer moet proberen of uitvoer van lagere kwaliteit produceert. Houd rekening met de volledige kosten van fouten, niet alleen met de prijs per token.
De realiteit van Databricks
Een multi-agent systeem werkend krijgen in een notebook is misschien 20% van de inspanning. Het inzetten voor echte gebruikers op Databricks is de andere 80%. Dat gezegd hebbende, Databricks gaf ons alles wat we nodig hadden om in productie te gaan.
Het platform is geavanceerd en capabel. MLflow zorgt voor versiebeheer en implementatie. Model Serving schaalt automatisch en de Unity Catalog houdt de governance strak. De diepte van de integratie is indrukwekkend, maar het betekent ook dat er veel te leren valt. We doken diep in de interne aspecten van MLflow toen de documentatie te kort schoot, maar de antwoorden waren er altijd.
Zie het als het krijgen van een Zwitsers zakmes met elk denkbaar gereedschap en dan te horen krijgen dat je een huis moet bouwen. Het gereedschap is er allemaal. Nu nog uitzoeken hoe je ze samen kunt gebruiken. Dit is bijna het terrein van software engineering en zeker niet van low-code.
Gebouwd voor data workflows, niet voor chat
Een realisatie die laat kwam: De agentgebaseerde mogelijkheden van Databricks zijn voornamelijk ontworpen voor data workflows. Agents die documenten in batch verwerken, datapijplijnen automatiseren, informatie extraheren en classificeren of als onderdeel van grotere orkestraties draaien.
Model Serving geeft je een API eindpunt, geen chatapplicatie. Dat is een ontwerpkeuze die logisch is voor een dataplatform. Het platform gaat ervan uit dat je agent aansluit op gegevensprocessen, niet dat hij rechtstreeks met zakelijke gebruikers praat.
We hebben een chat-gebaseerde analytische assistent gebouwd, die goed werkt. Maar als jouw use case vergelijkbaar is, weet dan dat je je eigen frontend moet bouwen of Databricks Apps moet gebruiken. Op dit moment gebruiken we AI Playground voor interne tests terwijl we de productie-interface plannen.
Databricks gelanceerd Agent Bakstenen medio 2025, wat dit deels kan vereenvoudigen. Het was niet beschikbaar in onze EU-regio toen we begonnen, en was nog steeds in bèta met alleen beschikbaarheid in de VS. De moeite waard om te evalueren als het voor jou toegankelijk is.
Workflow voor ontwikkelaars
Dit is een ontwikkelaar-georiënteerd platform. Een prompt aanpassen betekent opnieuw implementeren. Het aanpassen van het gedrag van een agent betekent een herimplementatie. Elke verandering doorloopt de volledige MLflow logging en Model Serving deployment cyclus.
Voor teams die vertrouwd zijn met CI/CD workflows is dit bekend terrein. Voor productiesystemen die niet-ontwikkelaars nodig hebben om het gedrag van agents te itereren, plan je een ontwikkelaar in de loop of bouw je je eigen configuratielaag er bovenop.
Operationele tips
De moeite waard om vooraf te weten:
- Versielimieten: Model Serving endpoints ondersteunen maximaal 15 versies. Onze workaround: neem een major versienummer op in de naam van het eindpunt en pas het aan na elke 15 implementaties.
- Snelheidslimieten: 11 agents die parallelle API-aanroepen doen kunnen limieten bereiken. Exponentiële backoff met retry handelt dit netjes af.
Afhaalmaaltijden
Voor technische leiders die multi-agent systemen overwegen:
- Specialisatie werkt. Een enkele agent met een enorme prompt en elk hulpmiddel worstelt in de praktijk. Gespecialiseerde agenten met gerichte verantwoordelijkheden presteren beter. De overhead aan coördinatie is het waard.
- Gebruikers hebben één stem nodig. Het woordvoerderpatroon is belangrijk. Meerdere agenten moeten bijdragen aan een enkele, samenhangende reactie.
- Temperatuur is belangrijk. Draai koud (0,1) voor analytisch werk. Nauwkeurigheid gaat boven creativiteit als je met gegevens werkt.
- Databricks kan dit. Het platform heeft alles wat je nodig hebt, maar het is gebouwd voor ingenieurs. Houd rekening met de leercurve en plan je strategie voor de gebruikersinterface op tijd.
- Codeer je domein. De beste architectuur ter wereld heeft een zakelijke context nodig om nuttig te zijn. Investeer in het leren van je agents wat belangrijk is in jouw specifieke domein.
–
Het systeem dat we hebben gebouwd, kan nu dagelijkse analytische taken aan die voorheen uren handmatig werk vereisten. Complexe vragen krijgen uitgebreide antwoorden. Eenvoudige vragen krijgen snel antwoord. Gebruikers vertrouwen de output omdat deze consistent is en gebaseerd op hun echte gegevens.
Multi-agent systemen vereisen een behoorlijke investering in engineering, maar voor de juiste gebruikssituaties leveren ze veel op.
