AI toevoegen aan onze eigen SaaS: de drie vragen die de agent van NetPath vormgaven

Er is een bepaalde smaak van LLM-integratieadvies die op de consultancy-circuit rondgaat: drie buzzwords op een slide, een RAG-diagram, een vaag verhaal over "verhoogde productiviteit". We hebben genoeg van die presentaties bijgewoond om te weten wat ze waard zijn.

De reden dat we dit artikel schrijven is dat we dit werk zelf aan het doen zijn. NetPath — het multi-vendor platform voor netwerkobservatie en -analyse dat wij bouwen — heeft dit kwartaal een LLM-ondersteunde assistent in zijn chat-interface uitgerold. Het is onze eigen SaaS. Wij zijn onze eigen klant. En voordat we één prompt schreven, hebben we onszelf door hetzelfde drie-vragen-kader gehaald waar we klantopdrachten doorheen loodsen. Dit artikel is wat daar uitkwam.

Als u overweegt AI toe te voegen aan een platform dat u al exploiteert, of als u een AI-pilot intern scoped, is het kader direct toepasbaar. Als u gewoon benieuwd bent hoe wij de AI-kant van NetPath bouwen — de rest van het artikel gaat daarover.

De drie vragen (en onze antwoorden)

1. Wat is het alternatief?

Elke voorgestelde AI-functionaliteit heeft een alternatief: wat doet een gebruiker vandaag, zonder het model?

Voor NetPath is de basislijn onze UI. Een netwerkengineer kan de meeste vragen over zijn topologie al beantwoorden door door onze bestaande interface te klikken. "Hoeveel routers zitten er in het netwerk?" is een getal bovenaan het dashboard. "Wat is het kortste pad van router-a naar router-b?" is een topologieweergave met een pad-overlay. "Toon me alle kritieke alerts" is een gefilterde lijst.

Niets daarvan is moeilijk. Maar het zijn twintig seconden klikken telkens weer, en voor samengestelde vragen — "vind alle routers met asymmetrische OSPF-buren op interfaces boven 80% belasting" — is er geen enkele weergave. De engineer bouwt ofwel een mentaal model op uit drie dashboards, schrijft een SQL-query tegen onze Postgres, of geeft het op.

Het alternatief was dus niet "niets". Het was "de bestaande UI, met wrijving die oploopt bij samengestelde vragen". De lat die we voor de AI-agent hebben gelegd:

• Minimaal 30 seconden besparen op single-concept vragen (het soort dat u anders doorheen zou klikken).
• Samengestelde vragen mogelijk maken voor gebruikers die geen SQL kunnen of willen schrijven.
• Nooit de enige bron van waarheid zijn. Elk antwoord van het model moet in de bestaande UI verifieerbaar zijn met één klik.

Die laatste bullet is het belangrijkste, en die bepaalt het antwoord op vraag twee.

2. Welke faalmodus kunnen we ons veroorloven?

LLM's zijn probabilistisch. Zelfs die van ons, met strikte tool-calling en retrieval op echte topologiedata, zal af en toe een hostname hallucineren, een pad-kost verkeerd lezen, of een vraag zelfverzekerd beantwoorden met verouderde data uit de verkeerde tool-call.

In ons drie-categorieën-framewerk — Categorie A (gebruiker vangt fouten op tegen nul kosten), Categorie B (menselijke review vóór verspreiding), Categorie C (output gaat rechtstreeks naar productie) — kwamen we stevig uit op Categorie A.

De redenering: netwerkengineers zijn geen casual gebruikers. Ze zullen absoluut merken als het model zegt "er zijn 47 routers" en de topologieweergave in het volgende tabblad zegt 48. Ze worden ervoor betaald om het te merken. De faalmodus die we ons konden veroorloven was "het model heeft ongelijk en de engineer ziet het onmiddellijk, met één klik om te verifiëren". Wat we ons niet konden veroorloven was "het model voert een actie uit — reroute van verkeer, wijziging van BGP local-pref, het triggeren van een discovery-job — op basis van een verkeerde aanname."

Alles stroomafwaarts van die beslissing vloeit eruit voort:

• De NetPath-agent heeft tien alleen-lezen tools: topologie-overzicht, router- / link- / interface-queries, pad-berekening, storingssimulatie, SPOF-analyse, centraliteit, asymmetrie, alerts, metrieken. Nul tools die state muteren. Nul tools die configuratie committen.
• Elke tool-call retourneert gestructureerde data die de engineer kan verifiëren. Pad-berekeningen retourneren de hop-lijst; de engineer kan op elke hop klikken en landen in de deterministische topologieweergave van die router. Als het model het pad verkeerd las, vangt de klik het op.
• Elk antwoord wordt gepersisteerd met zijn tool-calls en ruwe tool-outputs. Wanneer een engineer zegt "ik vertrouw dat antwoord niet", kunnen we exact de data ophalen die het model zag en die vergelijken met wat de UI zou hebben getoond. Geen giswerk.
• De agent draait maximaal 10 tool-calling-rondes per gebruikersbericht, waarna hij overdraagt met een duidelijke "ik kan dit niet betrouwbaar beantwoorden — probeer te herformuleren" reactie. We falen liever luid dan stilletjes tokens op te branden in een lus.

Dat is de architectuur die een Categorie A-assistent krijgt. Waren we meteen voor een Categorie C-agent gegaan — auto-remediatie, auto-failover, auto-configuratie — dan zouden we nu een heel ander systeem schrijven met tien keer zoveel engineering-kosten en veel strengere eval-vereisten. We zijn daar nog niet, en ik weet niet zeker of we daar dit jaar komen.

3. Wat is onze moat?

Dit is de vraag die bijna niemand bij kick-off stelt. Elke LLM-opdracht begint met "we gebruiken GPT-5" of "we gebruiken Claude" of "we draaien Llama op eigen hardware". Niets daarvan is de moat. Het foundation-model is een commodity die elke concurrent bij drie leveranciers kan kopen voor de prijs van een API-aanroep.

Onze moat, voor de NetPath-agent, zit op drie plaatsen:

De tools, niet de prompts. De tien tools die we hebben geschreven zijn het echte product. Een generieke chatbot kan geen single-point-of-failure analyse draaien op uw live netwerktopologie. Een generieke chatbot weet niet wat een OSPFv3 interface-ID is, of waarom die niet overeenkomt met ifIndex op Juniper maar wel op Arista. Onze tools zijn gebonden aan onze topologiegrafiek, onze multi-vendor normalisatielaag, onze BGP-LS ingest-pijplijn en onze ClickHouse analytics-store. Het vervangen van de LLM daarachter is een weekend werk. Het repliceren van de tools is maanden aan netwerkengineering-expertise.

Het evaluatiekader, ten tweede gebouwd. We hebben vroeg de bewuste keuze gemaakt om het eval-kader te bouwen vóór de productie-chat-UI. Het is een set van ~80 echte vragen — het soort dat een NOC-engineer daadwerkelijk zou stellen — elk met een bekend juist antwoord dat we rechtstreeks uit de database kunnen berekenen. Elke prompt-wijziging, elke model-upgrade, elke nieuwe tool loopt door dit kader. We weten, met een getal, of een wijziging dingen heeft verbeterd of verslechterd. De meeste AI-teams die we zien vliegen hier blind; ze leveren een prompt-wijziging op omdat "het voelt beter op het voorbeeld dat we hebben getest" en vragen zich twee weken later af waarom iets anders kapot ging.

De feedback-loop, ingebakken vanaf dag één. Elke chat-sessie wordt gepersisteerd met zijn tool-call-historie. We reviewen logs wekelijks op zoek naar twee patronen: vragen die het model verkeerd beantwoordde (wordt een nieuwe eval-case) en vragen die het model probeerde te beantwoorden maar niet kon omdat geen bestaande tool de query dekte (wordt een nieuwe tool of een verfijning van de tool-beschrijving). Het vliegwiel is dat echte gebruiksdata het systeem verfijnt — wat precies de moat is die een concurrent, die GPT-5 in een week aanbouwt, niet heeft.

Waar we concreet staan

De agent zit in actieve alpha. Hij is aangesloten op de chat-interface die naast de topologieweergave zit. Hij beantwoordt vragen over het verbonden netwerk in natuurlijke taal, draait pad-berekeningen en storingssimulaties op aanvraag, en presenteert resultaten als tabellen met deep-links terug naar de deterministische UI.

Wat we leren in live gebruik:

• Tool-beschrijvingen zijn belangrijker dan de system-prompt. De eerste versie van onze system-prompt was lang en zorgvuldig. Hij vertelde het model precies wanneer elke tool te gebruiken. Die prompt is inmiddels teruggesnoeid tot ongeveer een derde van zijn oorspronkelijke omvang, omdat we ontdekten dat de meeste "het model gebruikte de verkeerde tool"-incidenten werden opgelost door de beschrijving van de tool zelf duidelijker te maken over zijn scope en zijn grenzen.
• Gestructureerde output verslaat proza. Netwerkengineers willen geen alinea's. Ze willen een tabel met hostnames en getallen die ze kunnen verifiëren. We hebben de system-prompt stevig richting tables-first geduwd, en de gebruikerstevredenheid sprong omhoog.
• De top 20 vragen zijn 80% van het gebruik. We verwachtten een lange staart. We kregen een zeer korte staart: dezelfde handvol queries zijn verantwoordelijk voor bijna alle sessies. Dat betekent dat ons eval-kader klein en gefocust kan zijn, en het betekent dat tool-dekking voor de top 20 vragen meer waard is dan slim redeneren voor de rest.

Waar dit kader goed voor is

Als u nadenkt over het toevoegen van een LLM-functionaliteit aan een product dat u al runt, of u scoped een intern AI-project, zijn deze drie vragen een solide startpunt:

1. Wat is het alternatief? Staat er een getal bij de wrijving die de AI moet wegnemen?
2. Welke faalmodus kunt u zich veroorloven? Bouwt u voor de juiste categorie — en bent u bereid de engineering uit te geven die die categorie daadwerkelijk vereist?
3. Wat is uw moat? Als het alleen "we gebruiken GPT-5" is, hebt u er nog geen. De moat zit in uw tools, uw evaluatiekader en uw feedback-loop — en die drie moeten alle drie bewust worden gebouwd, meestal vóór de glamoureuze demo-bare chat-UI.

Wilt u een tweede paar ogen op zo'n gesprek — of bent u benieuwd hoe wij het kader op NetPath toepassen en wilt u het van dichterbij zien — neem contact op. Onze AI-opdrachten beginnen met precies zo'n scoping-gesprek. Geen slides, geen platformpitch, alleen de drie vragen.