Een altijd-aan AI-agent is een agent die verantwoordelijk kan blijven voor werk wanneer er geen gesprek openstaat. Hij kan de staat van een opdracht bewaren, wachten tot de tijd verstrijkt of de buitenwereld verandert, verdergaan in een geschikte omgeving en de controle teruggeven wanneer de volgende beslissing bij een mens hoort.
‘Altijd aan’ betekent niet dat een groot taalmodel onafgebroken nadenkt. Het betekent niet dat een computer dag en nacht op vol vermogen middelen moet verbruiken. En het zou niet moeten betekenen dat een agent voortdurend berichten stuurt of zonder toestemming handelt. De nuttige belofte is continuïteit: de verantwoordelijkheid blijft levend, ook terwijl het grootste deel van het systeem slaapt.
Een prompt inplannen of de chatgeschiedenis bewaren beantwoordt de praktische vragen niet: wat overleeft een herstart, wat maakt de agent wakker, waar werkt hij verder en hoe kan een gebruiker hem stoppen? De antwoorden op die vragen maken van ‘24/7’ een eigenschap van het systeem in plaats van een slogan.
Altijd aan gaat over continuïteit, niet over uptime
Uptime beschrijft of een proces draait. Continuïteit beschrijft of het werk nog een eigenaar en een geldige volgende stap heeft.
Stel dat je een agent vraagt om uit te kijken naar een ondertekend contract, een lanceringschecklist bij te werken zodra het binnen is en de volgende beslissing voor je voor te bereiden. Het contract kan morgen terugkomen of volgende week. Tijdens dat wachten vindt er geen nuttig redeneren plaats. De agent heeft geen open chat nodig, geen warmgehouden modelsessie en geen browser die elke minuut de inbox ververst. Hij heeft een blijvend overzicht van de verantwoordelijkheid nodig en een betrouwbare manier waarop de relevante gebeurtenis die verantwoordelijkheid weer in beweging zet.
Het verschil wordt duidelijk bij een storing. Een proces kan onafgebroken draaien en de opdracht toch kwijtraken na een crash. Een ander systeem kan urenlang naar nul schalen, dan zijn staat herstellen en correct verdergaan wanneer er een gebeurtenis binnenkomt. Het tweede systeem is in betekenisvolle zin altijd aan.
Daarom scheidt infrastructuur voor blijvende agents het wachten van het rekenen. De huidige Durable Extension voor Agent Framework van Microsoft beschrijft bijvoorbeeld agents die hun staat bewaren over workeruitvoeringen heen, pauzeren zonder rekenkracht of modeltokens te verbruiken en verdergaan op externe gebeurtenissen. De gids van Google over langlopende agents die op gebeurtenissen hervatten laat hetzelfde principe zien met blijvende checkpoints en webhooks. De details van de implementatie verschillen, maar de les voor de architectuur blijft: een verantwoordelijkheid die altijd aan is, heeft geen model nodig dat altijd draait.
De zes voorwaarden achter een geloofwaardige altijd-aan agent
Er is geen enkele functie die een agent altijd aan maakt. De eigenschap ontstaat wanneer zes voorwaarden samenwerken.
Een doorlopende identiteit draagt de verantwoordelijkheid
Het systeem heeft een stabiele identiteit nodig waaraan berichten, gebeurtenissen, rechten, taken en verwachtingen van de gebruiker gekoppeld kunnen worden. Als elk gesprek een losse agent zonder gedeelde werkcontext aanmaakt, is er niemand die latere gebeurtenissen kunnen wekken en niemand die verantwoordelijk is voor het voortzetten van het werk.
Een doorlopende identiteit vraagt niet om onbeperkt geheugen. Het betekent dat de gebruiker bij dezelfde agent kan terugkomen en dat het systeem weet welke verantwoordelijkheden bij hem horen. Persoonlijke feiten, gespreksgeschiedenis en taakstaat kunnen nog steeds een andere levensduur en andere controles hebben.
De werkstaat overleeft periodes van rust
Een opdracht moet meer bewaren dan de eerste prompt. De staat die nodig is om verder te gaan, kan het beoogde resultaat omvatten, afgeronde acties, werkmateriaal, beperkingen, het huidige obstakel en de volgende geldige stap.
Die staat moet blijvend genoeg zijn om gewone onderbrekingen te overleven: een gesloten browser, een computer in slaapstand, een uitgerolde update, een herstart van een worker of het verstrijken van een paar dagen. Een transcript kan helpen om te reconstrueren wat er is gebeurd, maar reconstrueren is niet hetzelfde als herstellen. Een geloofwaardig systeem weet welke staat leidend is, in plaats van bij elk ontwaken een model de waarheid uit een lang gesprek te laten afleiden.
Het diepere mechanisme om één opdracht over afhankelijkheden heen te dragen is een andere vraag dan de definitie van de categorie. Op dit niveau is de toets eenvoudiger: kan het systeem genoeg geldige staat bewaren om zonder nieuwe briefing verder te gaan?
Tijd en gebeurtenissen kunnen het systeem weer binnenkomen
Werk in de buitenwereld schiet niet alleen op wanneer een gebruiker een bericht stuurt. Deadlines verlopen. Bestanden veranderen. Antwoorden komen binnen. Een apparaat komt weer online. Een goedkeuring wordt vastgelegd in een andere applicatie.
Een altijd-aan agent heeft daarom meer nodig dan een interactief invoerveld. Hij heeft een pad nodig waarlangs een timer of externe gebeurtenis de verantwoordelijkheid bereikt die erdoor geraakt wordt. Dat pad kan een webhook zijn, een berichtenwachtrij, een planning, een connector of een nauw afgebakend bewakingsproces. Waar het om gaat, is dat de gebeurtenis gekoppeld kan worden aan de juiste agent en de juiste staat.
Dat betekent niet dat elke gebeurtenis een volledige redeneerronde verdient. Werken op gebeurtenissen is juist waardevol omdat het grootste deel van het systeem stil kan blijven tot er werk te beoordelen is. Beslissen of een bepaalde gebeurtenis de hoofdagent wakker moet maken, en of dat ontwaken een mens moet storen, is een apart beleidsvraagstuk naast het definiëren van het altijd-aan systeem zelf.
Er is een uitvoeringsomgeving beschikbaar wanneer het werk hervat
De volgende stap onthouden is niet genoeg als de agent nergens heeft om hem uit te voeren. Sommig werk kan via een API. Ander werk heeft een browser nodig, een cloudcomputer, een lokale machine of een gespecialiseerde agentruntime. De omgeving moet beschikbaar zijn wanneer de verantwoordelijkheid weer actief wordt, met de bestanden, tools en rechten die de volgende stap vraagt.
‘Beschikbaar’ betekent niet voortdurend draaiend. Een cloudcomputer kan slapen terwijl zijn opslag blijft bestaan en wakker worden wanneer dat nodig is. Een lokale machine kan losgekoppeld blijven tot een taak hem nodig heeft. Waar het om gaat, is dat de agent de benodigde omgeving kan herkennen en eerlijk kan omgaan met haar afwezigheid.
Grenzen van de omgeving horen ook bij correctheid. De documentatie over apparaten van Comma zegt dat Salix werk niet stilletjes verplaatst van een offline apparaat naar een andere computer. Het verzoek kan mislukken en opnieuw worden geprobeerd wanneer dat apparaat terugkomt. Dat is minder magisch dan doen alsof elke computer uitwisselbaar is, maar het bewaart de plek, de toegang en de uitvoeringsvoorwaarden waarvan het werk afhangt.
Herstel hoort bij de normale werking
Een altijd-aan systeem krijgt vroeg of laat te maken met een herstart, een dubbele gebeurtenis, een onbeschikbare dienst, verlopen inloggegevens of een verbroken verbinding. Betrouwbaarheid kan dus niet afhangen van één proces dat voor altijd perfect blijft.
Het systeem heeft een herstelpad nodig: blijvende staat, checkpoints of een gelijkwaardige bron van waarheid; een begrensd aantal nieuwe pogingen; een manier om een externe actie niet te herhalen; en een zichtbare foutstatus wanneer automatisch herstel niet meer veilig is. Een herstart die stilletjes vergeet wat al bevestigd was, is geen herstel. Een eindeloze lus van nieuwe pogingen die middelen verbruikt zonder het resultaat te veranderen evenmin.
De Loops-documentatie van Comma geeft een concreet voorbeeld. Een Loop kan een checkpoint opslaan en dat terugkrijgen wanneer hij weer start. Na een storing herstart Salix hem vanaf dat checkpoint binnen een begrensd beleid voor nieuwe pogingen; herhaald falen stopt de Loop en laat de agent het weten. De volledige implementatie, met blijvende gebeurtenissen, deduplicatie, plaatsing en grenzen aan mogelijkheden, wordt uitgelegd in Programmeerbare event loops voor ons gedistribueerde agent-harness. Kijk bij het beoordelen van een product of onderbreking en herstel geplande toestanden zijn in plaats van verrassingen.
De gebruiker kan de continuïteit zien en begrenzen
Voortbestaan maakt controle belangrijker. Een eenmalige chat eindigt vanzelf. Een verantwoordelijkheid op de achtergrond heeft een begrijpelijke reikwijdte nodig, een zichtbare status en een uitknop die echt werkt.
Gebruikers moeten kunnen zien waarvoor de agent verantwoordelijk is, welke bronnen hij volgt, welke omgeving hij mag gebruiken en welke bevoegdheid hij daar heeft. Ze moeten de verantwoordelijkheid kunnen pauzeren of beëindigen, toegang kunnen intrekken en al gemaakt werk kunnen terughalen. Het systeem moet fouten en beslissingen met gevolgen zichtbaar maken, in plaats van stilte op te vatten als bewijs dat alles goed gaat.
Daarom zijn altijd aan en autonoom ook geen synoniemen. Voortbestaan zegt dat het systeem beschikbaar kan blijven. Autonomie beschrijft welke beslissingen of acties het zonder te vragen mag nemen. Een agent kan zeer volhardend zijn en bewust voorzichtig: hij kan voorbereiden, controleren, ordenen en wachten terwijl hij externe toezeggingen of onomkeerbare keuzes teruglegt bij de gebruiker.
Vier werkmodi, geen eindeloze run
De uitdrukking ‘altijd aan’ suggereert één doorlopende activiteit. In de praktijk wisselt een nuttige agent tussen verschillende modi.
Hij kan aan het werk zijn, met een model en tools die een opdracht actief vooruithelpen. Hij kan wachten, omdat een tijdstip, gebeurtenis, omgeving of menselijke beslissing nog niet is gekomen. Een lichtgewicht wachter kan een smalle voorwaarde bewaken zonder de hoofdagent wakker te maken. Of de verantwoordelijkheid kan gestopt zijn, omdat de gebruiker haar beëindigde of een storing het veilige herstelbeleid te boven ging.
Die modi doen er net zo veel toe voor kosten en aandacht als voor betrouwbaarheid. Modelinferentie, rekenkracht in de cloud, het ontvangen van gebeurtenissen, opslag en API’s van derden kunnen elk anders worden afgerekend. Een product zou ze niet moeten samenvoegen tot een ongenuanceerde bewering dat ‘de agent 24/7 draait’. Een rustige achtergrondverantwoordelijkheid kan opslag en bewakingsmiddelen gebruiken zonder ook maar één token van een groot model te verbruiken; een actieve taak kan zowel model- als rekenkracht verbruiken; een gestopte verantwoordelijkheid hoort naast de bewaarde staat geen van beide te verbruiken.
Comma weerspiegelt die scheiding in zijn eigen runtime. Salix draait de agent buiten een sandbox die altijd warm wordt gehouden. Is er werk op een computer nodig, dan kan het een virtuele machine in de cloud wekken waarvan de opslag tussen gebruik door blijft bestaan. Voor doorlopende aandacht kunnen kleine Loops gebeurtenissen volgen zonder de hoofdlus van de agent actief te houden. Alleen wanneer een Loop vaststelt dat de agent nodig is, draait de hoofdlus.
Die architectuur is de implementatie van Comma, niet de universele definitie. Een ander product gebruikt misschien blijvende workflows, wachtrijen, serverless functies of langlopende workers. De toets is of het hele systeem de verantwoordelijkheid bewaart tijdens periodes van rust, niet of het een bepaalde runtime gebruikt.
Altijd aan, ingepland en langlopend zijn verschillende beloften
Een ingeplande automatisering voert een instructie uit op een bekend tijdstip. Die kan heel nuttig zijn zonder een doorlopende agentidentiteit te onderhouden of te reageren op ongeplande veranderingen. Als een dagelijkse taak een rapport maakt uit vaste input, is een planning misschien alles wat het systeem nodig heeft.
Een langlopende workflow kan zijn staat over meerdere stappen bewaren en op een signaal wachten. Hij wordt agentisch wanneer modellen meedoen aan het duiden van informatie, het kiezen van tools of het bijstellen van het plan. Hij wordt in betekenisvolle zin altijd aan wanneer die blijvende workflow hoort bij een doorlopende agent die nieuwe relevante gebeurtenissen kan ontvangen en kan handelen binnen grenzen die de gebruiker bepaalt.
Ook een chatbot kan eerdere gesprekken onthouden en herinneringen geven. Die functies verbeteren de continuïteit voor de gebruiker, maar bewijzen op zichzelf niet dat werk buiten de chat blijft bestaan. De beslissende vraag is niet of het systeem iets over jou onthoudt. Het is of een actieve verantwoordelijkheid kan wachten, hervatten, zich herstellen en een toegestane omgeving bereiken zonder met de hand opnieuw te worden aangemaakt.
Dat onderscheid voorkomt ook dat je te veel bouwt. Niet elk verzoek heeft een altijd-aan agent nodig. Een eenmalige uitleg, herschrijving, berekening of brainstorm is vaak beter af met een interactief model. Altijd-aan werken is zijn complexiteit waard wanneer het resultaat afhangt van tijd, externe veranderingen, meerdere werkomgevingen of een verantwoordelijkheid die openblijft nadat het huidige gesprek is afgelopen.
Een praktische continuïteitstoets
Om een ‘altijd-aan’ product te beoordelen, geef je het één realistische verantwoordelijkheid met een wachtmoment erin. Vraag het een vastgelegde voorwaarde te bewaken, de volgende stap voor te bereiden en te stoppen vóór een actie met gevolgen.
Kijk daarna wat het product je kan laten zien. Waar wordt de opdracht bewaard als je de interface sluit? Welke voorwaarde precies zet haar weer in beweging? Weet het in welke omgeving het werkmateriaal staat? Kan het na een herstart verdergaan zonder afgeronde acties te herhalen? Wat gebeurt er als de gebeurtenis dubbel binnenkomt of het benodigde apparaat offline is? Kun je de bewaking pauzeren, toegang intrekken of de opdracht beëindigen zonder al je geschiedenis te wissen?
Kijk tot slot wat er bij jou aankomt. Een systeem dat elke gebeurtenis doorstuurt, heeft een meldingspijplijn gebouwd, niet per se een agent. Een systeem dat op elke gebeurtenis handelt, verwart beschikbaarheid met bevoegdheid. Een nuttige altijd-aan agent koppelt een verandering aan een bestaande verantwoordelijkheid, doet het werk dat al is toegestaan en vraagt alleen om aandacht wanneer die aandacht het resultaat verandert.
Hoe Comma beschikbaar blijft zonder lawaai te maken
Comma is een gratis, open source persoonlijke agent, ontworpen rond één doorlopende agent over gesprekken en apparaten heen. Snelle vragen kunnen in de chat blijven, terwijl grotere verantwoordelijkheden taken worden. Comma kan werken in gekoppelde apps en bestanden, op een gekoppelde Mac of Linux-machine of op een cloudcomputer die wakker wordt wanneer dat nodig is.
De altijd-aan laag is Salix. Een Comma-agent kan een Loop maken om een afgebakende bron te volgen, zoals een inbox, repository, feed, API of webhook. De Loop draait los van de hoofdlus voor het redeneren, kan een klein checkpoint bijhouden en kan de agent waarschuwen wanneer er werk nodig is. Omdat de hoofdagent niet elke rustige periode hoeft te bekijken, wordt ‘altijd beschikbaar’ niet ‘altijd modeltokens aan het verbruiken’. Een Loop kan nog steeds een snel beslismodel of een andere dienst aanroepen, dus werk op de achtergrond is niet automatisch gratis; de kosten hangen af van wat de Loop werkelijk doet.
Diezelfde continuïteit blijft onder controle van de gebruiker. Gekoppelde computers beginnen alleen-lezen tot de gebruiker acties toestaat, en toegang tot apparaten kan worden ingetrokken. Loops hebben grenzen aan hun mogelijkheden en aan hoe vaak ze wekken. Een grotere taak kan teruggaan naar Ter beoordeling wanneer een beslissing bij de persoon hoort. Comma kan ook zelf gehost worden, al is de beheerder dan verantwoordelijk voor beschikbaarheid, upgrades, back-ups, modelconfiguratie en de rest van de infrastructuur die nodig is om die installatie draaiende te houden.
De aanpak van Comma is één antwoord op het centrale probleem van de categorie: laat de verantwoordelijkheid voortbestaan, terwijl dure rekenkracht, modellen en de aandacht van de gebruiker kunnen rusten tot ze echt nodig zijn.
Veelgestelde vragen
Laat een altijd-aan AI-agent 24/7 een model draaien?
Nee. Een goed ontworpen systeem kan zijn staat bewaren en luisteren naar timers of gebeurtenissen terwijl het hoofdmodel inactief is. Het model draait wanneer het systeem moet redeneren of iets moet genereren. Lichte bewaking, opslag en externe diensten kunnen nog steeds middelen verbruiken terwijl de agent wacht.
Is een altijd-aan agent hetzelfde als een autonome agent?
Nee. Altijd aan beschrijft continuïteit en beschikbaarheid door de tijd heen. Autonomie beschrijft wat de agent zonder menselijke goedkeuring mag beslissen of doen. Een altijd-aan agent kan met een smalle bevoegdheid werken en beslissingen met gevolgen teruggeven aan de gebruiker.
Is een ingeplande AI-taak een altijd-aan agent?
Niet per se. Een planning kan op een vast tijdstip een prompt zonder staat starten. Een altijd-aan agent bewaart daarnaast de verantwoordelijkheid en de relevante staat, kan reageren op passende externe gebeurtenissen, herstelt zich van onderbrekingen en gaat verder binnen blijvende controles van de gebruiker.
Moet de computer van de agent aan blijven staan?
Dat hangt af van de benodigde omgeving. Werk in de cloud of op de server kan doorgaan terwijl een persoonlijke laptop dicht is. Werk dat afhangt van bestanden of applicaties die alleen op een bepaald lokaal apparaat staan, moet op dat apparaat wachten. Sommige cloudomgevingen kunnen tussen acties door slapen en hun opslag behouden.
Wat gebeurt er als een altijd-aan agent faalt?
Het systeem hoort zich te herstellen vanaf een bekend checkpoint of blijvende staat, afgeronde externe acties niet te herhalen en een begrensd aantal nieuwe pogingen te gebruiken. Als het niet veilig kan herstellen, hoort het zichtbaar te stoppen en de agent of gebruiker te vertellen wat er misging, in plaats van eindeloos opnieuw te proberen of de verantwoordelijkheid stilletjes te laten vallen.
Kan ik een altijd-aan agent uitzetten?
Je zou een achtergrondverantwoordelijkheid moeten kunnen pauzeren of beëindigen en de toegang die ze gebruikt moeten kunnen intrekken. ‘Altijd aan’ zou moeten betekenen beschikbaar wanneer het is toegestaan, niet onmogelijk om te stoppen. In Comma kunnen Loops gepauzeerd of verwijderd worden en kan toegang tot gekoppelde apparaten worden ingetrokken.
De agent mag slapen; de verantwoordelijkheid mag niet verdwijnen
Een altijd-aan AI-agent wordt niet bepaald door onafgebroken modelactiviteit. Hij wordt bepaald door een onafgebroken keten van verantwoordelijkheid: een stabiele eigenaar, blijvende staat, een pad waarlangs tijd en gebeurtenissen ertoe doen, een beschikbare uitvoeringsomgeving, herstelbare werking en controles die bij de gebruiker blijven.
Wanneer die onderdelen er zijn, kan het grootste deel van het systeem het grootste deel van de tijd stil zijn. Het model kan stoppen. De cloudcomputer kan slapen. De gebruiker kan de app sluiten. Het werk gaat verder omdat de verantwoordelijkheid nog intact is, niet omdat iemand eraan dacht ‘ga door’ te typen.
