PostToolUse- en outgoing-call-hooks

Denk terug aan de agentische lus: verzoek verzenden, stop_reason inspecteren en, wanneer dit tool_use is, het hulpmiddel uitvoeren en het resultaat aan de geschiedenis toevoegen; daarna herhalen tot end_turn.

Een PostToolUse-hook omhult die stap waarin je het hulpmiddel uitvoert. Het model vraagt een aanroep van een hulpmiddel aan; je code voert deze uit; voordat je het resultaat aan de berichtgeschiedenis toevoegt, inspecteert de hook het resultaat en kan deze het aanpassen.

Een veelvoorkomende, praktische taak van PostToolUse is de uitvoer van een hulpmiddel inkorten tot de relevante velden. Ruwe API-reacties zijn vaak enorm en opgeblazen context veroorzaakt het lost-in-the-middle-probleem — modellen letten meer op het begin en einde van de context dan op het midden.

De hook hervormt het resultaat deterministisch, zodat het model alleen de velden ziet die ertoe doen.

PostToolUse is ook de plaats waar je fouten normaliseert. Een algemene status zoals "Operation failed" blokkeert herstel — het model kan een tijdelijke fout niet onderscheiden van een autorisatieprobleem.

Hervorm fouten tot gestructureerde fouten, zodat het model intelligent kan doorsturen: een vlag, een categorie, informatie over opnieuw proberen en context.

Een subtiele regel die PostToolUse helpt afdwingen: een toegangsprobleem is niet hetzelfde als een geldig leeg resultaat.

• Een mislukte query (time-out, authenticatie) is een fout die het model opnieuw kan proberen.
• Een leeg resultaat (nul overeenkomende bestellingen) is een legitiem antwoord — opnieuw proberen verandert niets.

Leg dit verschil vast, zodat het model nooit iteraties verspilt aan het opnieuw uitvoeren van een query die simpelweg geen overeenkomsten heeft.

Nu het belangrijkste toepassingsgebied. In het scenario Customer Support van het examen is er een hulpmiddel process_refund. Het beleid luidt: voor terugbetalingen boven $500 is een medewerker nodig.

Je zou die regel in de prompt kunnen schrijven — maar een prompt is ongeveer 90% betrouwbaar en één gemiste terugbetaling betekent een echt financieel verlies. Daarom omhul je de uitgaande aanroep met een hook die deterministisch blokkeert wanneer de drempel wordt overschreden. Het oordeel van het model krijgt hier geen stem.

Hooks voor uitgaande aanroepen dwingen ook voorwaarden vooraf af — volgordegaranties die een prompt niet betrouwbaar kan bieden. Voorbeeld: verwerk nooit een terugbetaling voordat get_customer een geverifieerde identiteit heeft geretourneerd.

De hook controleert een feit in je eigen status, niet de bewering van het model dat het dit 'al heeft geverifieerd'. Dat is het verschil tussen een deterministische garantie en een hoopvolle instructie.

Blokkeren is slechts de helft van het werk. Een hook die de actie stilzwijgend inslikt, laat het model in verwarring achter en legt de lus stil — dat is stilzwijgende onderdrukking, een antipatron.

Geef de blokkering in plaats daarvan terug als een resultaat van een hulpmiddel dat het model kan lezen en waarop het kan handelen. Een goede blokkeerboodschap vermeldt de reden en de juiste volgende stap (hier: escalate_to_human), zodat de agent zich binnen dezelfde lus netjes herstelt.

Verwar handhavingshooks niet met het vangnet van de lus. Een iteratielimiet stopt een lus die op hol slaat, maar is een noodrem — nooit het primaire besturingsmechanisme en nooit een vervanging voor handhaving van beleid.

Hooks zijn het tegenovergestelde: een precieze, bewuste garantie voor een specifieke actie. Het model blijft beslissingen nemen; hooks reserveren harde code alleen voor garanties die er echt toe doen.

Beslisregel voor het examen en voor productie:

• Gebruik een hook wanneer een fout financiële, juridische of veiligheidskritieke gevolgen heeft, of wanneer je een deterministische voorwaarde vooraf of drempel nodig hebt (terugbetaling > $500, geverifieerde identiteit vóór uitbetaling).
• Gebruik een prompt voor algemene aanwijzingen, toon en de ongeveer 90% van het gedrag waarbij een incidentele fout acceptabel is.

Hooks = deterministisch. Prompts = probabilistisch. Stem het hulpmiddel af op de kosten van een fout.

Belangrijkste punten:

• PostToolUse onderschept resultaten van hulpmiddelen voordat het model ze ziet — kort uitgebreide uitvoer in, normaliseer algemene fouten tot gestructureerde fouten en onderscheid toegangsproblemen van geldige lege resultaten.
• Hooks voor uitgaande aanroepen blokkeren acties die het beleid schenden (terugbetaling > $500) en dwingen voorwaarden vooraf af (geverifieerde identiteit vóór uitbetaling).
• Hooks = 100% deterministisch; prompts = ongeveer 90% probabilistisch. Gebruik hooks wanneer een fout financiële, juridische of veiligheidskritieke gevolgen heeft.
• Geef een blokkering altijd terug als een gestructureerd resultaat — onderdruk deze nooit stilzwijgend. Iteratielimieten zijn een vangnet, geen handhaving.