Retry met backoff bij rate limits
Standaard aanGeeft een aanbieder een rate limit of quotafout terug, dan wordt de aanroep maximaal drie keer herhaald, met een wachttijd van 1, 2 en daarna 4 seconden.
Foutafhandeling en herstel
Modelaanbieders geven time-outs, API's geven foutmeldingen en tools falen. Het platform merkt die fouten op en herstelt zonder dat iemand op opnieuw proberen hoeft te klikken. Meestal merkt de klant niet eens dat er iets misging.
Bij elke functie staat of die standaard aan staat of configureerbaar is per assistent, workflow of tenant. Standaardinstellingen die klantgegevens raken, kunt u uitzetten waar regelgeving of uw eigen beleid dat vraagt.
Als een model faalt
Modelaanroepen zijn de meest voorkomende bron van fouten. Daarom zijn er meerdere lagen van herstel.
Time-outs en automatische retries
Standaard aanModelverzoeken worden automatisch opnieuw geprobeerd en lopen na 90 seconden af, embeddingverzoeken na 30 seconden. Een aanbieder die blijft hangen, kan een gesprek zo niet blokkeren.
Overstappen naar een andere aanbieder
Standaard aanFaalt een aanbieder voordat het eerste woord van een antwoord binnen is, dan gaat de beurt naar een model van een andere aanbieder en wordt die overstap vastgelegd in de trace. De beheerder kan dit per omgeving uitschakelen als data alleen naar goedgekeurde aanbieders mag.
Guardrailcontroles hebben een reserve
Standaard aanEen guardrailmodel krijgt 15 seconden. Faalt het of loopt de tijd af, dan draait de controle nog één keer bij een andere aanbieder in plaats van te worden overgeslagen.
Als een tool of systeem faalt
Agents werken met systemen die traag zijn of plat liggen. Het platform vangt dat binnen de run op.
Fouten gaan terug naar de agent
Standaard aanMislukt in een workflow een toolaanroep, dan krijgt het model de foutmelding terug als resultaat van de tool. De agent kiest vervolgens zelf wat hij doet: andere argumenten, een andere tool of een andere route naar het doel.
Een tijdsbudget voor tools
Standaard aanAlle toolaanroepen binnen één beurt delen een budget van 45 seconden. Eén traag systeem kan het gesprek daardoor niet stilleggen.
MCP maakt opnieuw verbinding
Standaard aanBij een verbindingsfout maakt het platform opnieuw verbinding met de MCP-server en probeert het nog eens. Het kan dezelfde tool ook op een andere MCP-server aanroepen. MCP-servers krijgen elk uur een health check.
Lege resultaten worden opnieuw geprobeerd
Standaard aanGeeft het model in een workflow een leeg antwoord terug, dan wordt de stap maximaal twee keer herhaald.
Validatie en retry per workflowstap
InstelbaarKomt de output van een workflowstap niet door de validatie, dan wordt de stap een ingesteld aantal keren opnieuw geprobeerd met een pauze tussen de pogingen, of stopt de run. Dat hangt af van de instelling.
Als een antwoord niet goed genoeg is
Een antwoord dat technisch gelukt is, kan inhoudelijk toch fout zijn. Deze controles vangen dat op voordat de klant het leest.
Opnieuw genereren onder een kwaliteitsdrempel
InstelbaarDe kwaliteitsguardrail geeft elk antwoord een score. Ligt die onder de drempel, dan schrijft de agent een nieuw antwoord, tot een maximaal aantal pogingen.
Gelekte redenering wordt onderschept
Standaard aanKomt de interne redenering van een model in het antwoord terecht, dan wordt het antwoord opnieuw gegenereerd voordat het wordt verstuurd.
Nooit stilte
Standaard aanMislukt een beurt na al deze stappen toch, dan krijgt de klant het fallbackbericht dat voor die assistent is ingesteld en wordt de fout bij het gesprek gelogd.
Zien wat er gebeurde
Herstel heeft pas waarde als u het achteraf kunt controleren.
Traces per gesprek
Standaard aanTraces leggen per beurt de toolaanroepen, retrieval, guardrailmeldingen, fallbacks naar andere aanbieders en opnieuw gegenereerde antwoorden vast.
Per assistent uit te zetten waar regelgeving of uw eigen beleid dat vraagt.
Geplande monitors
InstelbaarTestsuites draaien volgens een planning, van elke 5 minuten tot eens per dag, en sturen een melding per e-mail of webhook als de resultaten teruglopen.
Decision log
Standaard aanElke herstelstap, van een overstap naar een andere aanbieder tot een opnieuw gegenereerd antwoord, staat in het decision log van het gesprek. Dat exporteert u als JSON of via OpenTelemetry.
Per assistent uit te zetten waar regelgeving of uw eigen beleid dat vraagt.
Foutafhandeling: veelgestelde vragen
Wilt u het zien op uw eigen systemen?
We organiseren een werksessie over uw use case, met uw data en de modellen die u kiest.
Plan een gesprek