Skip to content

Als uw agents alleen in een scherm bestaan, zijn ze niet echt van u

U kunt een agent gebruiken die alleen in een editor bestaat. Maar hij is niet echt van u. Bij software betekent eigendom drie dingen: u kunt de software lezen, aanpassen met uw eigen tools en meenemen naar een andere omgeving.

U opent de editor. U sleept een stap naar het canvas, typt een prompt, kiest een model en klikt op opslaan. De agent werkt.

Zes maanden later hebt u twintig agents, vier mensen die ze aanpassen, een testserver en een productieomgeving. Elke wijziging bestaat nu uit een reeks klikken die niemand anders heeft gecontroleerd. Niemand kan de wijziging beoordelen voordat deze live gaat. Niemand kan dezelfde wijziging op de tweede server doorvoeren zonder alle stappen opnieuw te doorlopen. En uw eigen AI-codeerassistent heeft niets om te lezen en niets om aan te passen.

U kunt zo'n agent gebruiken. Maar hij is niet echt van u. Bij software betekent eigendom drie eenvoudige dingen: u kunt de software lezen, u kunt deze met uw eigen tools aanpassen en u kunt deze meenemen naar een andere omgeving.

Wat teams melden

Op forums over automatiserings- en agent tools lopen ontwikkelaars tegen hetzelfde probleem aan.

Eén team wilde dat elke opgeslagen workflow automatisch naar Git werd overgezet, zonder handmatige tussenstap. Het plan was om het serverlog te volgen, elke gewijzigde workflow via de API op te halen en die vervolgens handmatig te committen. Het team noemde die aanpak zelf kwetsbaar.

Een ontwikkelaar wilde de logica van zijn agents laten bouwen door zijn eigen AI-assistent. De command-line tool van de leverancier werkte niet. Ook het alternatief, de assistent via een browser de webinterface laten bedienen, mislukte.

Een gebruiker die de software zelf host, wijzigde een workflow via de command line. De tool meldde dat de wijziging was geslaagd en de editor toonde de nieuwe versie. Toch bleef de planning de oude versie uitvoeren totdat de server opnieuw werd opgestart. Uiteindelijk stapte de gebruiker over op de REST API.

Een klein team dat workflows voor klanten bouwt, moest elke workflow handmatig van de testomgeving naar de productieomgeving overzetten. Dat betekende exporteren, importeren en vervolgens de toegangsgegevens, adressen en omgevingsinstellingen één voor één opnieuw instellen. Versiebeheer was alleen beschikbaar in een betaald abonnement dat het team niet wilde afnemen. Een lid van de community bood een workflow aan die workflows via de API kopieert en daarbij namen van toegangsgegevens aan elkaar koppelt. Die gebruiker gaf er eerlijk bij aan dat de oplossing geen branches en geen mogelijkheid tot terugdraaien bood.

Een beheerder die zijn platform als code beheert, wilde voor elke nieuwe agent meteen bij het aanmaken een uitgavenlimiet instellen. Die limiet bestond wel, maar was alleen via een beheerscherm in te stellen. Er was geen API waarmee dit kon.

Wat u van een tool nodig hebt om agents als code te beheren

De vraag "Welke versie draait er in productie?" is iets anders dan de vraag die hier centraal staat: wie of wat kan een agent aanmaken en aanpassen?

De teams hierboven vroegen de tool niet om Git, codebeoordeling of CI te vervangen. Die hulpmiddelen hadden ze al. Ze wilden dat de tool hun werkwijze niet in de weg stond. Dat vraagt om vier dingen.

Eén toegangspunt voor mensen en scripts. Als de gebruikersinterface en de API twee verschillende toegangspunten zijn, biedt de API meestal minder mogelijkheden. Sommige instellingen zijn dan alleen via de interface te wijzigen. De veiligste opzet is één API die ook door de gebruikersinterface zelf wordt gebruikt.

Een leesbaar bestand. Als u een agent als tekstbestand kunt exporteren, kunt u dat bestand naast uw andere code bewaren. U kunt twee versies vergelijken en wijzigingen beoordelen in een pull request.

Overzetten zonder geheimen mee te nemen. Het bestand mag geen wachtwoorden of sleutels bevatten. Dat is goed voor de beveiliging, maar betekent wel dat u op de andere installatie de toegangsgegevens opnieuw moet koppelen. Een goede tool maakt dat proces eenvoudig en voorspelbaar.

Een sleutel met bekende rechten. Een script handelt namens iemand. U moet daarom weten wiens rechten het heeft en wat het met die rechten mag doen.

Wat EpicStaff biedt om vanuit code te werken

In EpicStaff is een flow de eenheid die u bouwt, exporteert en overzet. Een flow bestaat uit stappen en de bijbehorende instellingen.

Dezelfde API die de editor gebruikt, kan flows, hun stappen en hun instellingen aanmaken en wijzigen. Daardoor kan een script zelfstandig een flow bouwen. De API is dezelfde als die het product zelf gebruikt en er kan een OpenAPI-beschrijving van worden gegenereerd. Uw script of AI-codeerassistent kan die beschrijving gebruiken om met de API te werken.

Een script roept de API aan met een API-sleutel. Die sleutel heeft de rolrechten van de gebruiker aan wie deze is gekoppeld. Een script of CI-job kan met zo'n sleutel via de API een run van een flow starten.

U kunt een flow exporteren naar een JSON-bestand en op een andere installatie importeren. De export bevat geen geheime waarden, zodat u het bestand bij uw code kunt bewaren. Exports bevatten nooit sleutels of wachtwoorden. Tijdens het importeren hergebruikt EpicStaff een bestaande setup in uw organisatie als die overeenkomt met de geëxporteerde instellingen. Is er geen overeenkomst, dan maakt EpicStaff een nieuwe setup aan waaraan u de sleutel toevoegt. Een setup geldt alleen als overeenkomst wanneer alle geëxporteerde instellingen gelijk zijn, inclusief de naam.

Er zijn wel aandachtspunten. De geëxporteerde JSON bevat database-id's en niet-gesorteerde sleutels, waardoor een diff onoverzichtelijk kan zijn. U kunt benoemde versies van een flow opslaan en een eerdere versie terugzetten.

EpicStaff heeft geen command-line tool, geen ingebouwde Git-integratie en geen ingebouwde stap om een flow van de testomgeving naar de productieomgeving te promoveren.

EpicStaff is source-available onder PolyForm Perimeter 1.0.0. U kunt de code lezen, uitvoeren en aanpassen voor uw eigen gebruik. De belangrijkste beperking is dat u geen concurrerend product mag aanbieden, ongeacht of dat gratis of betaald is. Het bekijken van de code is niet beperkt. Er gelden ook andere voorwaarden, waaronder verplichtingen om vermeldingen te behouden wanneer u de software doorgeeft. Raadpleeg hiervoor LICENSE.md. Als de API zich anders gedraagt dan u verwacht, kunt u dus de onderliggende code bekijken.

Uitgewerkt voorbeeld: van een script naar de productieomgeving

Zo verplaatst u een flow van een script naar de productieomgeving. Bij elke stap leest u wat EpicStaff biedt, waar uw eigen tooling aan te pas komt en welke vraag u aan elke tool kunt stellen, ook aan die van ons.

  1. Geef het script een identiteit. EpicStaff: de API-sleutel heeft de rolrechten van de gebruiker aan wie deze is gekoppeld. Kies daarom een gebruiker met een rol die past bij de taak. Uw verantwoordelijkheid: bewaar de sleutel in de geheimenopslag van uw CI-omgeving, niet in de repository. Vraag aan elke tool: wiens rechten gebruikt een automatiseringssleutel?

  2. Bouw de flow met een script. EpicStaff: de API die de editor gebruikt, kan de flow, de stappen en de bijbehorende instellingen aanmaken. Uw verantwoordelijkheid: genereer de OpenAPI-beschrijving en schrijf een kleine cliënt die de API aanroept. Vraag aan elke tool: kan een script alles wat ik ook via de editor kan doen?

  3. Test de flow. EpicStaff: uw CI-job kan via de API een run starten. Uw verantwoordelijkheid: bepaal wat een geslaagde uitvoering inhoudt en controleer of het resultaat daaraan voldoet. Vraag aan elke tool: kan CI een run starten zonder menselijke tussenkomst?

  4. Exporteer de flow en commit het bestand. EpicStaff: de flow wordt geëxporteerd als JSON, zonder geheime waarden. Uw verantwoordelijkheid: sorteer de JSON-sleutels voordat u het bestand commit, zodat een diff echte wijzigingen laat zien. De database-id's blijven wel behouden. Gebruik vervolgens uw eigen Git-proces met een branch, pull request en codebeoordeling. Vraag aan elke tool: bevat de export geen geheimen en zijn wijzigingen goed te beoordelen in een diff?

  5. Zorg dat u kunt terugkeren naar een eerdere versie. EpicStaff: sla op de productieomgeving een benoemde versie van de flow op voordat u deze wijzigt. Vraag aan elke tool: kan ik in één stap terugkeren naar een bekende, eerdere toestand?

  6. Importeer de flow in de productieomgeving. EpicStaff: sleutels worden niet mee geëxporteerd. Als er op de doelomgeving een setup bestaat die overeenkomt met alle geëxporteerde instellingen, inclusief de naam, wordt deze hergebruikt. Anders maakt EpicStaff een nieuwe setup aan, waaraan iemand de sleutel moet toevoegen. Uw verantwoordelijkheid: zorg dat setups op beide installaties dezelfde namen en instellingen hebben als u ze wilt hergebruiken. Vraag aan elke tool: kan ik een agent naar een andere installatie overzetten zonder alle geheimen opnieuw in te voeren?

  7. Bepaal wanneer de flow live gaat. EpicStaff: er is geen ingebouwde stap om een flow naar productie te promoveren. Uw verantwoordelijkheid: laat uw eigen pipeline bepalen wanneer de flow live gaat. Zo kan een goedgekeurde merge bijvoorbeeld het importproces starten. Vraag aan elke tool: is er een command-line tool en is Git geïntegreerd? Bij EpicStaff is het antwoord op beide vragen nee.

De kernvraag is dus: kan een script een agent bouwen en aanpassen, en kunt u die agent naar een andere installatie overzetten zonder geheimen opnieuw in te voeren?

Met EpicStaff kan een script een flow bouwen en wijzigen via dezelfde API die de editor gebruikt. Geheimen worden nooit mee geëxporteerd. Op de andere installatie hergebruikt EpicStaff een overeenkomende setup, of voegt u de benodigde sleutel eenmalig toe aan een nieuwe setup.

Vragen & Antwoorden

Hoe beheer ik AI agents als code?

Bewaar elke agent als een tekstbestand in Git, pas deze via de API van de tool aan met een script, beoordeel wijzigingen in een pull request en zet ze via uw eigen pipeline over naar de productieomgeving. Controleer eerst of de API alles kan wat u ook via de editor kunt doen.

Kan ik een EpicStaff-flow vanuit een script bouwen?

Ja. Dezelfde API die de editor gebruikt, kan flows, hun stappen en hun instellingen aanmaken en wijzigen. Daardoor kan een script een flow bouwen. De API is dezelfde als die het product zelf gebruikt en er kan een OpenAPI-beschrijving van worden gegenereerd. De API-sleutel van het script heeft de rolrechten van de gebruiker aan wie deze is gekoppeld.

Hoe zet ik een flow over naar een andere EpicStaff-installatie zonder geheimen opnieuw in te voeren?

Exporteer de flow als JSON-bestand en importeer deze op de andere installatie. Exports bevatten nooit sleutels of wachtwoorden. Bij het importeren hergebruikt EpicStaff een bestaande setup in uw organisatie als die overeenkomt met de geëxporteerde instellingen. Anders wordt een nieuwe setup aangemaakt waaraan u de sleutel toevoegt. Een setup komt alleen overeen als alle geëxporteerde instellingen gelijk zijn, inclusief de naam.

Heeft EpicStaff een command-line tool of Git-integratie?

Nee. EpicStaff heeft geen command-line tool, geen ingebouwde Git-integratie en geen ingebouwde stap om een flow van de testomgeving naar de productieomgeving te promoveren. U kunt een flow wel exporteren naar en importeren uit een JSON-bestand zonder geheime waarden, zodat u het bestand bij uw code kunt bewaren.

Keep reading