Waarom uw AI-agent voor klantcontact een fallbackmodel nodig heeft

Een AI-agent voor klantcontact heeft een fallbackmodel nodig, omdat elk model vroeg of laat uitvalt op het slechtste moment: de provider heeft een storing, uw account bereikt een rate limit, een verzoek loopt op een time-out of één ongewoon gesprek verbruikt meer tokens dan gepland. Zonder fallback valt de agent stil en wacht de klant. Met een fallback neemt een tweede model het over en gaat het gesprek door. In de Agent Harness van MonoChat heeft elke AI Agent-node een hoofdmodel, een fallbackmodel en een snel model, plus een budgetlimiet per run.

Dit artikel legt uit waarom modelstoringen zwaarder wegen in klantberichten dan elders, hoe fallback werkt, hoe u een fallbackmodel kiest en hoe het past bij snelle modellen, budgetten en overdracht aan een medewerker.

Waarom modelstoringen meer pijn doen in klantgesprekken

In een interne tool is een mislukt AI-verzoek vervelend: u klikt op opnieuw proberen. In een klantgesprek op WhatsApp is het een gebroken belofte. De klant stelde een vraag, zag de blauwe vinkjes en wacht op een antwoord.

Een paar dingen maken klantberichten extra gevoelig:

• Klanten proberen het niet opnieuw. Ze schrijven nogmaals, gefrustreerder, of ze haken af.
• Het verkeer is grillig. Een campagne, een leveringsvertraging of een uitverkoop kan het aantal gesprekken in enkele minuten vermenigvuldigen, en dan slaan rate limits toe.
• Agents doen veel aanroepen. Een agent harness draait het model in een lus, vaak meerdere keren per klantbericht. Eén mislukte aanroep kan de hele run laten vastlopen.
• Timing telt op WhatsApp. Vrije antwoorden zijn alleen toegestaan binnen 24 uur na het laatste bericht van de klant. Een lange vertraging kan een antwoord buiten dat venster duwen, waar u een goedgekeurde template nodig heeft.

Niets hiervan gaat over een bepaalde provider die onbetrouwbaar zou zijn. Elke provider heeft incidenten, onderhoud en capaciteitslimieten. De vraag is alleen of uw agent daar een plan voor heeft.

Wat er mis kan gaan

Storingen bij de provider. Gedeeltelijk of volledig, kort of lang. Zelfs een maandelijkse beschikbaarheid van 99,9% staat meer dan 40 minuten downtime toe.

Rate limits. Uw account staat mogelijk een bepaald aantal verzoeken of tokens per minuut toe. Een druk uur kan dat plafond bereiken, ook als de provider zelf in orde is.

Time-outs en trage antwoorden. Een model dat gewoonlijk binnen twee seconden antwoordt, kan onder belasting twintig seconden nodig hebben. Voor een klant op een telefoon voelt dat alsof er niets gebeurt.

Op hol geslagen runs. Een agent die in een lus raakt door een verwarrend verzoek, of een gesprek dat steeds groter wordt, kan veel meer verbruiken dan een normale run.

Modelwijzigingen. Providers werken modellen bij en trekken ze in. Gedrag waarop u vertrouwde, kan met weinig waarschuwing veranderen.

Hoe fallback werkt in een agent

Het idee is eenvoudig: wanneer het hoofdmodel de taak niet kan afmaken, neemt een tweede model het over. In MonoChat neemt het fallbackmodel het over na een zachte limiet of wanneer het hoofdmodel uitvalt. Het gesprek, de tools en de instructies blijven gelijk; alleen het model dat het werk doet, verandert.

In elke AI Agent-node werken drie rollen samen:

Rol	Wat het doet
Hoofdmodel	Redeneert, beslist en schrijft de antwoorden
Fallbackmodel	Neemt over na een zachte limiet of een storing
Snel model	Verwerkt achtergrondwerk

Daarbovenop begrenst een budgetlimiet per run wat één gesprek mag uitgeven.

Hoe kiest u een fallbackmodel

Geef de voorkeur aan een andere provider

Een fallback van dezelfde provider beschermt u tegen één model dat zich misdraagt, maar niet tegen een incident bij de hele provider of een rate limit op uw account bij die provider. Een model van een tweede provider dekt beide. Met eigen LLM’s kunt u in MonoChat meerdere providers koppelen, dus dit is een configuratiekeuze, geen project.

Maak het goed genoeg, niet identiek

Het fallbackmodel hoeft niet het beste beschikbare model te zijn. Het moet uw instructies volgen, uw tools correct aanroepen en een fatsoenlijk antwoord schrijven. Test het afzonderlijk op uw echte gesprekken, alsof het het hoofdmodel is, voordat u erop vertrouwt.

Controleer of het uw tools aankan

Agents zijn afhankelijk van toolaanroepen: een bestelling opzoeken, een tijdslot controleren, een ticket aanmaken. Sommige modellen zijn veel beter in gestructureerde toolaanroepen dan andere. Een fallback die prachtige tekst schrijft maar tools verkeerd aanroept, is slechter dan geen fallback.

Let op de talen die u bedient

Als uw klanten in het Turks, Arabisch of Spaans schrijven, zorg dan dat het fallbackmodel die talen even goed schrijft als het hoofdmodel. Een plotselinge wisseling in kwaliteit of toon valt op.

Houd rekening met kosten in beide richtingen

Een goedkoper fallbackmodel verlaagt de kosten van lange of ongewone runs die een zachte limiet passeren. Een duurder fallbackmodel kan prima zijn als het alleen zeldzame storingen afhandelt. Bepaal welke taak u het fallbackmodel wilt laten doen.

Het snelle model: de andere helft van betrouwbaarheid

Niet elke stap heeft uw beste model nodig. Achtergrondwerk, de taken rond het gesprek in plaats van het antwoord zelf, kan draaien op een kleiner, sneller model. Zo blijven de capaciteit en het budget van het hoofdmodel gereserveerd voor wat de klant daadwerkelijk ziet, en neemt de kans af dat u in drukke uren een rate limit op het hoofdmodel bereikt.

In de praktijk: zet uw sterkste redeneermodel als hoofdmodel, een solide model van een tweede provider als fallback en een snel, goedkoop model voor achtergrondwerk.

Budgetten: het vangnet onder het vangnet

Fallback houdt de agent aan het werk. Budgetten houden het betaalbaar. Een budgetlimiet per run betekent dat geen enkel gesprek, hoe vreemd ook, meer kan uitgeven dan u had gepland. In combinatie met een zachte limiet waarna het fallbackmodel overneemt, krijgt u een voorspelbaar patroon: normale gesprekken draaien op het hoofdmodel, lange gaan door op het fallbackmodel en niets slaat op hol.

Met uw eigen providersleutels rekent MonoChat geen AI-opslag, dus wat u budgetteert is wat uw providers in rekening brengen.

Fallback is geen overdracht

Het is verleidelijk om een fallbackmodel als antwoord op elk probleem te zien. Dat is het niet. Een fallback lost technische storingen op: het model is uitgevallen, traag of zonder budget. Overdracht lost beoordelingsproblemen op: een klacht, een juridische vraag, een terugbetaling boven uw limiet, of een klant die gewoon om een medewerker vraagt.

In MonoChat draait de agent binnen een flow, dus overdracht naar uw gedeelde teaminbox met de volledige geschiedenis is altijd beschikbaar. WhatsApp verwacht bovendien dat geautomatiseerde antwoorden een duidelijke route naar een mens bieden. Ontwerp beide paden:

1. Het hoofdmodel valt uit of bereikt een zachte limiet → het fallbackmodel gaat verder.
2. De zaak heeft een medewerker nodig → overdracht aan het juiste team met de gespreksgeschiedenis.
3. Beide vallen uit → de flow laat de klant weten dat er iemand antwoordt en stuurt het gesprek naar de inbox.

Een eenvoudige checklist

• Hoofdmodel gekozen op kwaliteit voor uw echte gesprekken.
• Fallbackmodel van een tweede provider, afzonderlijk getest met uw tools en talen.
• Snel model voor achtergrondwerk.
• Budgetlimiet per run die past bij de kosten van uw normale gesprek, met wat ruimte.
• Duidelijke overdrachtsregels in de instructies van de agent en in de flow.
• Een controle van een steekproef van gesprekken na de eerste week, inclusief gesprekken die op de fallback draaiden.

Eén keer instellen, voor elk kanaal

Omdat de AI Agent-node in een MonoChat-flow leeft, beschermen dezelfde hoofd-, fallback- en snelle modellen uw agent op WhatsApp, Instagram, Messenger, TikTok, Telegram, webchat, SMS en voice. En omdat u met Agent Harness het framework kiest, werkt dezelfde aanpak of uw agent nu draait op de ingebouwde harness van MonoChat, de Claude Agent SDK, de OpenAI Agents SDK, Pi of uw eigen framework.

Bekijk hoe de modelrollen samenwerken op de Agent Harness-pagina.