AI-agentbuilder: waar u op moet letten als agents binnen uw eigen omgeving moeten draaien

Een AI-agentbuilder is een tool waarmee u AI-agents bouwt. U definieert de agent, geeft hem tools en kennis en het platform voert hem uit. De meeste producten zijn goed op het gebied van bouwen. De vraag die uiteindelijk bepaalt of u het product aanschaft, is anders: waar draait de agent en wie beheert wat hij achterlaat?

Als uw agents binnen uw eigen omgeving moeten draaien, komt die vraag op de eerste plaats. Op productpagina's vindt u het antwoord meestal pas als laatste. In deze guide bespreken we wat een agentbuilder u moet bieden, welke vier vragen u moet stellen en op welke drie manieren deze platforms worden aangeboden.

Vijf dingen waar u om moet vragen. Als er één ontbreekt, zal uw team het later zelf moeten bouwen.

Hoe agents, tools en kennis te definiëren. Elke agent heeft een taak, een instructie, de tools die hij mag aanroepen en de documenten die hij mag lezen nodig. Als die vier onderdelen niet op één plek staan, kan niemand de agent beoordelen voordat deze live gaat.

Een runtime die de agents uitvoert. Het platform moet het werk starten, de status bijhouden, een mislukte stap opnieuw uitvoeren, werk tussen agents doorgeven en stoppen wanneer iets misgaat.

Een registratie van wat er is uitgevoerd. De prompts, tool-aanroepen, modelreacties en het resultaat. U hebt deze informatie deze week nodig om fouten op te lossen, en volgend jaar zal iemand ernaar vragen.

Machtigingen voor wat de tools mogen benaderen. Een agent is maar zo veilig als de tools die u hem geeft. Het platform moet aangeven wie een tool mag maken, wie een flow mag wijzigen en tot welke systemen een tool toegang heeft.

De mogelijkheid om te stoppen en op een persoon te wachten. Voor de stappen die u daarvoor kiest: geld versturen, schrijven naar een bronsysteem of een bericht naar een klant sturen. Vraag om dit werkend te zien in de versie die u daadwerkelijk zou installeren.

1. Waar draait het?

Vraag de implementatiemogelijkheden schriftelijk op. "We ondersteunen on-premises" kan betekenen dat u het volledig op uw eigen servers installeert. Het kan ook betekenen dat er een agent binnen uw netwerk draait die voor het denkwerk nog steeds verbinding maakt met de cloud van de leverancier.

2. Wie kan de code lezen?

Er zijn drie antwoorden. Niemand buiten de leverancier. Iedereen, maar slechts deels. Iedereen die de code ontvangt, binnen de voorwaarden van de licentie. Als uw securityteam moet beoordelen wat er met uw gegevens gebeurt, is het eerste antwoord het einde van het gesprek.

Let op de woorden "open source". Verschillende platforms hier zijn source-available, en dat is niet hetzelfde: u kunt de code lezen en uitvoeren, met beperkingen die in de licentie zijn vastgelegd. Lees daarom het licentiebestand en niet alleen de marketingpagina.

3. Wat staat er in de registratie en wie beheert die?

Twee vragen, en leveranciers beantwoorden vaak alleen de eerste. Vraag voor de inhoud wat één registratie bevat: de prompt, de tool-aanroepen en de modelreactie, of alleen "stap 4 voltooid". Vraag voor het beheer waar de gegevens worden opgeslagen. Als de registratie in de database van de leverancier staat, leest u die via hun console zolang u ervoor betaalt. Als de registratie in uw eigen database staat, kunt u deze zelf bewaren, exporteren en verwijderen.

4. Wat verlaat het netwerk?

Breng elke uitgaande verbinding van het platform in kaart: het modelendpoint, de service die documenten omzet in vectoren voor zoekopdrachten, voice als u die gebruikt en alles wat het product over zichzelf naar buiten stuurt. Vraag vervolgens welke daarvan u naar uw eigen servers kunt laten verwijzen.

Een tool die u zelf bouwt, valt onder uw eigen verantwoordelijkheid. Als u een tool schrijft die verbinding maakt met een openbare API, verlaat die verbinding uw netwerk omdat u dat zo hebt ingericht. Die keuze maakt u zelf.

Deze tabel vergelijkt leveringsmodellen, niet leveranciers. Producten kunnen in de loop van de tijd van kolom veranderen, dus controleer altijd welke tiers momenteel worden aangeboden.

Vraag	Hosted SaaS	Zelfgehost, open core met betaalde governance	Zelfgehost, source-available
Waar draait het?	In de cloud van de leverancier.	Uw servers voor de core. Sommige betaalde onderdelen hebben mogelijk nog de leverancier nodig.	Uw servers.
Wie kan de code lezen?	Niemand buiten de leverancier.	Iedereen, voor de open core. De betaalde laag is meestal gesloten.	Iedereen die de code ontvangt, binnen de voorwaarden van de licentie.
Waar staat de registratie?	In de database van de leverancier.	Uw database voor de core. Langere bewaartermijnen en logstreaming kunnen in een betaalde tier zitten.	Uw database.
Toegangsbeheer	Inbegrepen in de prijs.	Basisrollen kunnen in de gratis editie zitten; single sign-on kan betaald zijn. Controleer de tierlijst.	Bepaald door de tierlijst van de leverancier. Lees deze goed.
Wat kunt u aanpassen?	De instellingen die de leverancier beschikbaar stelt.	De open core.	De code, voor uw eigen gebruik, binnen de voorwaarden van de licentie.
Waarvan bent u afhankelijk?	Dat de leverancier beschikbaar blijft.	De leverancier voor de betaalde laag.	De code die u zelf beheert.

Geen van de drie is verkeerd. Hosted SaaS biedt de snelste start. Open core geeft u de code voor de gebruikelijke toepassingen en verkoopt de onderdelen die grotere organisaties nodig hebben. Source-available geeft u de code en de mogelijkheid om zelf te hosten, met beperkingen die in een licentie staan in plaats van in een tierlijst.

EpicStaff draait op uw infrastructuur. Het is source-available onder PolyForm Perimeter 1.0.0: u kunt de code lezen, uitvoeren en aanpassen voor uw eigen gebruik; de beperking betreft commercieel concurrerend gebruik, niet inspectie. Role-based access control zit in de source-available tier, niet in de betaalde tier. De registratie van prompts, tool-aanroepen en modelreacties wordt opgeslagen in uw eigen PostgreSQL-database en kan worden geëxporteerd als JSON of CSV. EpicStaff maakt alleen verbinding naar buiten met de providers waarvoor u sleutels configureert. Tools doen wat u ze opdraagt: een tool die u bouwt of inschakelt en die het internet bereikt, is uw keuze en uw configuratie. De modeladapter maakt verbinding met het LLM-endpoint waarnaar u deze laat verwijzen.

Als u ons vergelijkt met één specifieke workflowtool, hebben we een vergelijking per dimensie met n8n.

Een visuele builder volstaat vaker dan engineers verwachten. Het past wanneer het werk een duidelijk patroon heeft: deze stap, dan die stap, hier een persoon inschakelen, daar het resultaat wegschrijven. De mensen die verantwoordelijk zijn voor het proces kunnen dan zelf een stap wijzigen zonder dat daar een ticket voor nodig is.

In drie gevallen hebt u code nodig. Ten eerste bij een intern systeem dat eigen regels heeft: paginering, retries, afwijkende foutcodes of een datamodel dat niemand buiten uw organisatie kent. Ten tweede voor het bewerken van gegevens: opschonen, matchen, samenvoegen of een getal controleren aan de hand van een tweede bron. Ten derde voor hergebruik: als drie flows dezelfde actie nodig hebben, moet dat één tool met één eigenaar zijn.

Zoek daarom een platform dat beide biedt. Een engineer moet een tool in Python kunnen toevoegen en tools moeten ook via MCP beschikbaar kunnen komen. MCP, het Model Context Protocol, is een gestandaardiseerde manier om een bestaande tool met een agent te verbinden, zodat u niet voor elk platform een nieuwe adapter hoeft te schrijven. In EpicStaff voegen engineers tools toe in Python en verbinden ze systemen via MCP.