Het werkt voor de bouwer. Het faalt voor de mensen met wie u het deelt.

Veel agents worden getest door één persoon: degene die ze bouwde. Die heeft de ruimste toegang en de opgeslagen inloggegevens. Werkt de agent voor die persoon, dan lijkt hij af.

Dan wordt hij gedeeld. Andere mensen starten hem, met andere accounts, via andere kanalen. Soms werkt hij dan niet meer, alleen voor hen.

Drie teams meldden dit in september 2026 op hetzelfde communityforum van een leverancier. Het gaat niet om de tool. Het gaat om het patroon.

Dezelfde gebruiker, dezelfde verbinding, twee uitkomsten. Een bouwer meldde een agent met twee tools: de ene bevroeg een dataset voor bedrijfsrapportages, de andere riep via een gateway de eigen API's van het bedrijf aan. Beide werkten voor de bouwer. De bouwer deelde de agent met een groep gebruikers die de agentrollen en rechten op de dataset hadden. Voor die gebruikers werkte de API-tool, en faalde de datasettool. Met de eigen inloggegevens van de gebruikers gaf die tool een autorisatiefout. Met de inloggegevens van de bouwer gaf hij een foutmelding dat de verbinding niet werd gevonden. Daarna bouwde de bouwer dezelfde agent op een tweede agent-engine van hetzelfde platform, met dezelfde dataverbinding. Daar kon dezelfde gebruiker de dataset wel bevragen. Een ervaren forumlid schreef dat deze test een oorzaak in rechten, licenties of een ontbrekende verbinding uitsloot.

Het werkt voor de ontwikkelaars. Gebruikers krijgen een foutmelding. Een team meldde een agent met een stap die een eigen AI-prompt aanroept, en die werkte voor de ontwikkelaars. Toen zij de agent deelden, kregen gebruikers een foutmelding, hoewel de prompt ook met hen was gedeeld. Eén reactie merkte op dat de foutmelding te weinig details bevatte om de oorzaak te vinden. Een andere reactie stelde dat het delen van de prompt gebruikers de definitie geeft, maar niet de capaciteit om hem uit te voeren. Het team accepteerde dat antwoord niet. Het vroeg hoe het de oorzaak kon vinden zonder beheerrechten op het platform. De vraag is niet opgelost.

Het testvenster slaagde. De uitgerolde agent niet. Een derde team meldde een agent met geprogrammeerde gespreksstappen die in het testvenster van de builder werkte zoals bedoeld. Uitgerold in de chat- en assistent-apps van het bedrijf negeerde de agent de meeste van die stappen: het welkomstbericht, de meerkeuzeopties en de connectoren. Alleen het model besliste nog wat er gebeurde. Reacties raadden aan de gepubliceerde versie, de instellingen en een cache te controleren, en opnieuw te publiceren. Het team antwoordde dat test en productie zich met dezelfde instellingen nog steeds anders gedroegen, en dat het daardoor de bouw opnieuw moest beginnen.

In elk geval klopte de bouw voor één persoon op één plek: het account van de bouwer, de inloggegevens van de bouwer of het testvenster van de bouwer. Toen de persoon, de inloggegevens of het kanaal veranderden, veranderde de uitkomst.

In geen van de drie liet de bouw zelf zien waarom. Elk team vond het gat pas toen andere mensen de agent startten.

Deze controles gelden voor elke tool waarmee u een agent of workflow bouwt en deelt, ook de onze. Waar EpicStaff een antwoord heeft, staat dat onder de controle.

1. Weet met wiens rechten een run draait als iemand anders hem start

Er zijn twee gangbare modellen. In het eerste handelt de run met de rechten van degene die hem startte, zodat dezelfde agent voor de ene gebruiker meer kan dan voor de andere. In het tweede handelt de run met de configuratie van de agent of workflow zelf, wie hem ook start. Beide modellen kunnen juist zijn. U moet weten welk model u hebt, want dat bepaalt wat elke gebruiker via de agent kan bereiken.

In EpicStaff: Een beheerder (admin) geeft elke gebruiker een rol, en elke rol bepaalt wat die gebruiker mag doen met flows, agents, tools en inloggegevens (credentials). Wie een flow mag starten, wordt één keer gecontroleerd, bij de start. Daarna gebruikt de run de eigen configuratie van de flow, niet de rechten van degene die hem startte.

2. Weet welke inloggegevens de run gebruikt

Inloggegevens (credentials) zijn de sleutel, het token of de login waarmee een tool een ander systeem bereikt. Sommige tools gebruiken de inloggegevens van degene die de run start. Andere gebruiken één set opgeslagen inloggegevens voor iedereen. De eerste soort faalt voor gebruikers zonder eigen toegang. De tweede soort werkt voor iedereen die de run mag starten, en geeft ieder van hen het bereik van die ene sleutel. Meer over één sleutel die iedereen bedient, leest u in Eén sleutel voor elke klant: het stille risico van uw automatiseringsserver.

Noteer voor elke tool in de agent welke inloggegevens hij gebruikt en van wiens account ze zijn.

In EpicStaff: Een run gebruikt dezelfde opgeslagen inloggegevens (credential), wie de run ook start.

3. Weet of een testrun hetzelfde is als een echte run

Een testvenster kan een andere versie, andere instellingen of een andere engine draaien dan de gepubliceerde agent. Een test die daar slaagt, zegt dan weinig over productie. Vraag welke opgeslagen versie de test draait, op welke engine en met wiens account. Hoe u wat live draait gelijk houdt aan wat u hebt getest, leest u in Wat live draait, is niet wat u hebt getest.

In EpicStaff: Een testrun in de editor en een run die op een andere manier is gestart, draaien dezelfde opgeslagen flow op dezelfde engine.

4. Weet wat de foutmelding zegt als een gebruiker wordt geweigerd

Een gebruiker die wordt geweigerd, moet zien dat dat gebeurde, en waarom: geen toegang tot de agent, tot een tool of tot de gegevens erachter. Start de agent vóór het delen met een account dat één recht mist, en lees wat die gebruiker ziet. Lees daarna wat de bouwer of de beheerder bij dezelfde run ziet. Vertelt geen van beide welk recht ontbrak, bepaal dan nu hoe u daarachter komt.

5. Controleer vóór het delen wat elke rol mag

Rollen en groepen bepalen wie een agent mag openen, starten en wijzigen, en wie de tools en inloggegevens mag gebruiken. Lees de rol van elke groep waarmee u wilt delen. Noteer per rol wat die mag doen met de agent, de tools en de inloggegevens. Controleer ook wie de resultaten van een run kan zien. Een runresultaat kan gegevens bevatten uit de systemen die de agent bereikte, en wie het leest, moet het recht hebben om die gegevens te zien.

6. Controleer of het verslag vermeldt wie de run startte

Faalt een gedeelde agent voor één gebruiker, dan is de eerste vraag: wiens run was het? Een runverslag zonder de naam van de starter maakt die vraag moeilijk te beantwoorden. Wat een runverslag verder moet bevatten, leest u in De AI agent is klaar. Niemand kan zeggen wat hij deed.

In EpicStaff: De JSON-export van elke run legt vast wie de run startte.

7. Test als gewone gebruiker, via het echte kanaal

Maak een testaccount met dezelfde rol als de mensen met wie u deelt: geen beheerder, en niet de bouwer. Start de agent zoals zij dat doen, vanuit de gepubliceerde versie, via dezelfde chatapp, hetzelfde formulier of dezelfde API. Voer drie taken uit die zij echt zullen doen, en één taak die zij niet mogen doen. Vergelijk elk resultaat met de run van de bouwer zelf. Bewaar het account, en herhaal de test na elke wijziging aan de agent, de rollen of de inloggegevens.

In veel teams is het delen van een agent één klik op een deelknop. Die klik verandert wie de agent draait, met welke rechten en via welk kanaal. Het is een release, en het verdient wat een release krijgt: een eigenaar met naam, een test met een gewoon account, een geschreven notitie van welke inloggegevens elke tool gebruikt, en een manier om het delen terug te draaien.

De drie teams hierboven vonden hun gaten na het delen. Dezelfde controles kosten minder als u ze ervoor doet.