Dertig seconden, één poging: tool calls naar bedrijfssystemen

Het verzoek met publiek

Midden in een zin besluit het model dat het iets nodig heeft wat het niet weet: of deze beller een openstaande order heeft, of donderdag om tien uur vrij is, hoe hoog het saldo staat. Het stuurt een tool call, en op ons platform wordt dat een ondertekende HTTP-POST naar een endpoint dat van jou is, met de gesprekscontext en de argumenten die het model heeft gekozen.

Vanaf dat moment loopt er een klok die niets met jouw infrastructuur te maken heeft. Het is de klok in het hoofd van de beller. Twee seconden stilte aan de telefoon is een pauze. Vijf is een probleem. Bij acht zeggen mensen hallo om te controleren of de lijn er nog is. De technische timeout doet er veel minder toe, en op ons platform wacht een synchrone tool call maximaal dertig seconden. Die dertig seconden zijn het plafond waarop het systeem het opgeeft. Het is geen budget dat je van plan moet zijn op te maken.

caller: "can you check my last invoice"   t+0.0s
  [llm]   tool call: lookup_invoice           t+0.9s
  [http]  POST https://you.example/tools      t+0.9s
  [say]   "one moment, let me look"           t+1.1s   <-- filler, not a stall
  [erp]   token read from cache               t+1.1s
  [erp]   filtered query, one record          t+1.2s
  [http]  200 · 412 bytes                     t+3.4s
  [llm]   answer generated                    t+3.9s
  agent:  "that one was paid on the fourth"   t+4.2s

  tool budget used                            2.5s of 30s
  attempts                                    1 of 1

Het gesprek hierboven kostte tweeënhalve seconde binnen een ruimte van dertig, en de beller hoorde een kort tussenzinnetje in plaats van stilte. Dat is de vorm waar je naar zoekt. De rest van dit artikel gaat over de manieren waarop het misgaat.

Waarom één poging en niet drie

Een mislukt verzoek opnieuw proberen is zo gebruikelijk dat het weglaten eruitziet als een vergissing. Tijdens een lopend gesprek is het precies andersom. Een tweede poging die vier seconden later slaagt, geeft antwoord op een vraag waar het gesprek allang voorbij is, en dan zegt de agent iets wat nergens op slaat of moet hij te horen krijgen dat hij het moet negeren. Erger nog: de beller heeft die vier seconden naar niets zitten luisteren.

Daarom wordt een synchrone tool call op ons platform precies één keer geprobeerd. Webhooks voor gebeurtenissen gedragen zich juist omgekeerd, want die vuren achteraf en hebben geen publiek: een kortere timeout van tien seconden en maximaal drie pogingen, omdat daar niemand wacht en aankomen belangrijker is dan snelheid.

Er is een tweede reden, en die komt van de systemen aan de andere kant en niet van ons. Exact Online staat niet meer dan tien fouten toe per API-sleutel, per gebruiker, per administratie, per endpoint, per uur, en blokkeert de sleutel zodra je daaroverheen gaat. Die blokkade valt er een uur later vanzelf af. Een agent die bij elke fout drie keer opnieuw probeert, bereikt dat plafond tijdens precies de storing die je het kortst wilt houden, en maakt van een slechte minuut een slecht uur.

Lezen mag blokkeren, schrijven niet

Bijna elke koppeling valt netjes uiteen in twee helften die een tegengesteld ontwerp verdienen. De leeshelft beantwoordt een vraag die de agent nodig heeft voordat hij kan praten, dus die moet blokkeren. De schrijfhelft legt vast wat er is gebeurd, en niemand heeft ooit aan de lijn gewacht om een CRM dat te horen bevestigen.

1. 01

   Lezen op de gespreksroute, gefilterd en smal

   Eén record, geselecteerd op een kenmerk dat je al hebt, met de vier velden die de agent misschien hardop zegt. Alles wat een brede zoekopdracht nodig heeft, hoort niet op de gespreksroute, en doen alsof van wel is hoe een zoekopdracht een stilte van negen seconden wordt.
2. 02

   Schrijven in een wachtrij voor na het gesprek

   De uitkomst, de samenvatting, het aangemaakte ticket. Neem de tool call aan, zet het werk in een wachtrij en geef meteen antwoord. De agent gaat verder met het gesprek en jouw systeem krijgt de registratie een paar seconden later.
3. 03

   De uitzondering die de regel bevestigt

   Een schrijfactie die de beller hardop bevestigd wil horen, zoals een ingeplande afspraak, moet wél blokkeren. Die is het wachten waard, want de beller wacht precies op dat antwoord en weet dat.

De fout die je wilt vermijden is die scheiding zien als een optimalisatie voor later. Het is een ontwerpkeuze, en hem omdraaien als de agent eenmaal draait betekent veranderen wát de agent zegt, niet alleen hoe snel.

Wat de agent zegt terwijl hij wacht

De grootste verbetering die hier te halen valt is niet technisch. Het is dat de agent iets zegt vóórdat de zoekopdracht begint, en niet pas nadat die is mislukt. Een beller die hoort dat iemand het even voor hem nakijkt, wacht moeiteloos vier of vijf seconden. Diezelfde beller die helemaal niets hoort, begint zich na twee seconden af te vragen wat er aan de hand is.

Dat is lastiger dan het klinkt bij speech-to-speech-modellen, want die vertellen niet uit zichzelf dat ze iets aan het opzoeken zijn. Het moet dus in de instructie staan en niet gehoopt worden. De promptkant daarvan staat in de prompting guide voor Gemini Live en de timingkant in het latency-budget van een telefoongesprek.

Een trage zoekopdracht met een tussenzin is een gesprek. Een snelle zoekopdracht met stilte is een storing.

De beller vraagt het twee keer

Mensen herhalen zichzelf aan de telefoon. Ze zeggen het anders als ze denken dat ze niet werden begrepen, ze noemen de datum voor de zekerheid nog een keer, en als de lijn stil valt stellen ze de hele vraag gewoon opnieuw. Elk van die momenten kan een nieuwe tool call opleveren met dezelfde bedoeling, en schrijft jouw endpoint bij elke aanroep weg, dan heb je nu twee afspraken, twee tickets of twee orders.

De oplossing is gewoon werk en moet er staan vanaf de eerste schrijfactie, niet pas na de eerste dubbele. Elke tool call draagt een kenmerk van het gesprek en een van de aanroep zelf. Leid daar een sleutel uit af op basis van het gesprek plus de handeling plus de argumenten die ertoe doen, bewaar die, en laat een herhaling op dezelfde sleutel landen en het oorspronkelijke resultaat teruggeven. Dan kost de tweede poging niets en hoort de beller dezelfde bevestiging twee keer, wat precies is wat hij wilde.

Geef een antwoord terug, geen record

De meest voorkomende oorzaak van een agent die vreemd klinkt, is een endpoint dat teruggeeft wat de API teruggaf. Een CRM-record heeft veertig velden, waarvan drie genest, en een model dat dat allemaal krijgt kiest er iets uit om te zeggen wat je niet had verwacht. Misschien leest het een intern kenmerk voor. Misschien noemt het een veld dat een beller niet hoort te horen.

Geef het kleinste terug dat de vraag beantwoordt, al klaargemaakt om uitgesproken te worden. Niet het factuurobject, maar het feit dat factuur 2026-0412 op vier augustus is betaald. Datums voluit in plaats van in ISO. Bedragen afgerond zoals een mens ze zou uitspreken. Niets waar de beller geen recht op heeft, want een model dat een veld krijgt, vindt er vroeg of laat een reden voor om het te gebruiken.

Hardop falen

Ergens in deze keten ligt op enig moment iets plat: het ERP, het netwerk ertussen, of je eigen endpoint tijdens een deploy. De vraag die bepaalt of dat een klacht wordt, is wat de agent er vervolgens mee doet.

Hij zegt het. De tool call loopt af, de agent krijgt te horen dat het opzoeken mislukte, en hij vertelt de beller dat hij het nu niet kan nakijken en biedt aan terug te bellen of door te verbinden naar iemand die het wel kan. Wat hij nooit mag doen, is het gat vullen met een aannemelijk antwoord, en dat is geen voorkeur per koppeling. Het is dezelfde keuze om dicht te vallen die ook geldt voor wat er gebeurt als doorverbinden mislukt: een weigering waar de beller iets mee kan is beter dan een stellig antwoord dat verzonnen blijkt.

De andere helft van goed falen is dat je het achteraf kunt zien. Elke tool call wordt vastgelegd met zijn status, zijn duur en zijn antwoord, dus een beller die klaagt dat de agent niets van zijn order wist, wordt een vraag die je uit de registratie kunt beantwoorden in plaats van een verhaal dat je moet reconstrueren. Dat is dezelfde redenering als bij het lezen van de SIP-logs, maar dan een laag hoger.