De chat die niet opnieuw kan beginnen

Een maker meldde op het communityforum van een leverancier een AI-agent te hebben gepubliceerd in een zakelijke chatapp. Na een tijd liepen gebruikers tegen de grens aan van hoeveel gesprek de agent kon bijhouden. De chatgeschiedenis wissen hielp niet. De maker vroeg om iets eenvoudigs: een nieuw gesprek na 24 uur, of op verzoek. Toen wij de thread lazen, was het probleem niet opgelost.

Elke chat die blijft groeien, komt uiteindelijk bij die grens. Waar het om gaat, is wat er dan gebeurt: wie de chat opnieuw kan laten beginnen, wat het platform bij de grens doet, en wie het op tijd hoort.

Een model kan in één aanroep maar een vaste hoeveelheid tekst lezen. Die hoeveelheid is het contextvenster (in het Engels: context window). Telkens als een agent antwoordt, leest het model de instructies van de agent, het gesprek tot nu toe, de beschrijvingen van de tools van de agent en wat die tools terugstuurden. Dat telt allemaal mee in hetzelfde venster (uit welke delen een agent bestaat, leest u in wat een AI-agent is). Ook lange instructies nemen hun deel van het venster in; zie Als de instructies van uw AI agent niet meer in het vak passen.

Een lange chat groeit met elk bericht, en één tool die een groot bestand teruggeeft, kan in één stap een groot deel van het venster vullen. Past de volgende aanroep niet meer, dan heeft het platform dat de agent laat draaien in grote lijnen drie keuzes. Het kan stoppen met een foutmelding. Het kan oudere berichten inkorten of samenvatten en doorgaan. Of het kan iemand vóór de grens waarschuwen, zolang er nog tijd is om in te grijpen. Elke keuze heeft een prijs.

Op dezelfde dag meldde een tweede maker dezelfde grens, met dezelfde opzet. De agent van die maker verwerkte documenten voor vastgoedanalyses. Gebruikers liepen na veel berichten tegen de grens aan, en de zichtbare geschiedenis wissen loste het niet altijd op. Een gebruiker op het forum noemde de foutmelding en raadde aan om een model met een groter venster te kiezen, de instructies korter te maken en minder tools te gebruiken. Een medewerker van de leverancier legde uit dat deze chats blijven doorlopen: als u de zichtbare geschiedenis wist, of zelfs de app opnieuw installeert, mag u niet verwachten dat er op de achtergrond een nieuw gesprek begint.

Het antwoord van de medewerker wijst op de echte kwestie: de geschiedenis op het scherm en de geschiedenis die het model leest, kunnen twee verschillende dingen zijn. Een wisknop die alleen het scherm leegmaakt, geeft gebruikers een schoon beeld en hetzelfde volle venster.

In EpicStaff kan een bezoeker in de chatwidget, EpicChat, een nieuwe chat starten. Daarmee wordt het huidige gesprek afgesloten, en hun volgende bericht opent een nieuw gesprek. Elke run via de API is een eigen sessie. Wat een flow tussen chats bewaart, hangt af van hoe die flow zijn geschiedenis opslaat; bepaal dus per flow wat die moet bewaren.

Vraag, voordat gebruikers op een chat gaan rekenen, wie hem opnieuw kan laten beginnen: de gebruiker, een beheerder, een programma via de API, of alleen de leverancier.

Eén team meldde een ander soort fout op het openbare forum van een framework. De agent van het team las een groot bestand, en één toolresultaat was erg groot. Toen de geschiedenis te lang werd, verving de gebruikte bibliotheek oudere berichten door een samenvatting. Daarvoor hield de bibliotheek alleen de nieuwste berichten over die binnen een vast budget pasten. Dat ene grote resultaat was groter dan het hele budget, dus bleef er niets over om samen te vatten. De samenvatting zei in feite dat er geen eerder gesprek was. Die lege samenvatting werd het eindantwoord van de agent, en de run stopte. De taak was niet af.

Het team vond de oorzaak door de code van de bibliotheek te lezen. Het team vroeg om een controle die dit geval opvangt, en om een manier om een groot bericht in plaats daarvan in te korten. Toen wij de melding lazen, had nog niemand gereageerd.

Inkorten om te passen klinkt veilig. In deze run gooide het juist het werk weg waarvoor de run bestond, en toch eindigde de run alsof hij klaar was. Een foutmelding was beter geweest, want een foutmelding zorgt dat iemand gaat kijken. Over runs die als klaar eindigen terwijl het werk ontbreekt, leest u meer in stille fouten in AI-agents.

Vraag dus wat een platform bij de grens doet. Stopt het met een foutmelding die u kunt terugvinden, of kort het in of vat het samen en gaat het door? Als het samenvat, kunt u dan zien wat het bewaarde en wat het weggooide? En als de samenvatting mislukt, mislukt de run dan ook, of wordt de lege samenvatting het antwoord?

Het beste moment om in te grijpen ligt vóór de grens, zolang de run zijn werk nog kan afmaken. Daarvoor is een waarschuwing nodig, en iemand die de waarschuwing leest.

In EpicStaff wordt een modelaanroep boven de grens niet opnieuw geprobeerd; die mislukt met de foutmelding "context window exceeded" van de modelaanbieder.

Een waarschuwing helpt alleen als die iemand bereikt die haar leest. Vraag dus aan uw platform waar een waarschuwing vóór de grens terechtkomt, en bepaal wie de runresultaten van elke agent leest, en hoe snel na een run. Zie ook wat een runverslag moet bevatten. Stuurt een flow ook lange tekst naar een model in stappen die geen agent zijn, test die stappen dan ook met een lange invoer.

Over limieten die een run stoppen terwijl hij nog loopt, leest u in Wie stopt de lus? Limieten die werken tijdens de run.

De maker uit de eerste melding vroeg om een regel voor opnieuw beginnen toen gebruikers de grens al hadden bereikt. Het is makkelijker om dat vóór de lancering te regelen. Een chat die lang loopt, kent drie momenten die een eigenaar nodig hebben: als een gebruiker opnieuw wil beginnen, als de waarschuwing binnenkomt, en als de grens is bereikt. Wijs voor elk moment een persoon of een programma aan, en schrijf de namen op voordat de eerste gebruiker begint te typen.

Dan is een vol contextvenster een moment waarop u had gerekend, en geen verrassing voor uw gebruikers.