Stell dir deine Support-Leiterin an einem Donnerstagnachmittag vor, drei Stunden in einer Schicht, in der der neue KI-Assistent sie schon einundvierzig Tool-Aufrufe hat bestätigen lassen. Die ersten sechs hat sie Zeile für Zeile gelesen, Argumente geprüft, IDs mit dem Ticket abgeglichen. Bei Aufruf dreißig drückt sie den grünen Button so, wie du bei einer Abfrage von composer update Enter drückst: aus dem Muskelgedächtnis, den Blick längst beim nächsten Thema. Fahrlässig ist daran nichts. Menschen machen das mit jeder Abfrage, die oft genug auftaucht. Und genau so werden, schätze ich, viele Teams das glänzende neue Freigabe-Feature im Laravel AI SDK 1.0 nutzen.

Kurz die Fakten für alle, die das Release am 23. September verpasst haben. Ein Tool, das den Approvable-Contract implementiert und den Trait InteractsWithApprovals einbindet, läuft nicht mehr einfach los, sobald das Modell es auswählt. Der Agent hält an und reicht dir die offenen Aufrufe samt der Argumente, die das Modell gewählt hat. Du beantwortest jeden einzeln: durchlassen, mit einer Begründung ablehnen, die das Modell zu sehen bekommt, oder die Argumente vor der Ausführung ändern. Das funktioniert mit prompt, stream, queue und den broadcast-Methoden, ein Agent in der Queue kann also pausiert bleiben, bis sich jemand darum kümmert. Saubere Ingenieursarbeit, und ich freue mich, dass es direkt mit dem Framework kommt.

Meine Position: Behandle Approvable als letzte Schicht deines Designs, niemals als erste. Wenn ein Tool so gefährlich ist, dass du bei jedem Aufruf einen Menschen draufschauen lassen willst, frag dich zuerst, ob du es weniger gefährlich machen kannst. Das ist besser, als einen müden Menschen vierzig Mal pro Schicht zu deinem Sicherheitsmechanismus zu machen. Ein Tool namens `DeleteFile`, das jeden beliebigen Pfad annimmt, ist ein Pulverfass. Ein Tool, das nur Dateien aus einem bestimmten Mandantenordner in einen Soft-Delete-Papierkorb verschieben kann, der nach dreißig Tagen geleert wird, braucht meist gar keine Bestätigung, denn das Schlimmste, was es anrichten kann, ist lästig und umkehrbar.

Dasselbe Release bringt noch einen leiseren Hebel mit, den ich dafür spannender finde. Middleware läuft jetzt bei jedem Generierungsschritt statt einmal pro Prompt und bekommt einen PendingStep, den du verändern kannst. Du kannst während der Agent läuft auf ein anderes Modell wechseln, Tools aus der Liste streichen oder das Token-Budget kürzen. Für mich ist das der Entzug von Fähigkeiten als vollwertiges Konzept. Der Agent hat die Rechnung gelesen, die er brauchte? Dann nimm ihm für alle folgenden Schritte die Schreib-Tools weg. Das Modell kann kein Tool aufrufen, das es nicht hat, und niemand muss irgendetwas anklicken, damit diese Garantie hält. Die Go-Leute prahlen gern damit, wie klein ihre Interfaces sind. Hier haben wir die Chance, auch den Werkzeugkasten eines Agenten klein zu halten, Schritt für Schritt.

Jetzt das ehrliche Gegenargument, denn es ist ein starkes. Manche Aktionen lassen sich nicht durch Eingrenzen entschärfen. Eine Erstattung ist eine Erstattung. Eine E-Mail an einen Kunden lässt sich nicht zurückholen, egal wie sorgfältig du das Template eingrenzt. Da muss wirklich ein Mensch draufschauen, und eine gut gebaute Pause schlägt jede selbstgebastelte Lösung mit einem Flag in der Datenbank, die ich über die Jahre in Laravel-Apps gesehen habe. Dass sich ein falsches Argument korrigieren lässt, statt den ganzen Lauf wegzuwerfen, gibt der prüfenden Person außerdem einen Grund, wirklich zu lesen, was auf dem Bildschirm steht. Das alles erkenne ich an. Mir geht es um die Menge. Eine Freigabe bleibt nur so lange bedeutsam, wie sie selten genug ist, dass jemand jede einzelne ernst nimmt.

Und es gibt eine Art von Risiko, die kein Freigabe-Button abdecken kann. Gabriele Pieretti, der ein virtuelles Spiegel-Produkt für Friseursalons baut, hat über dieses Release aus der Sicht einer App geschrieben, die Kundenfotos an Gemini auf Vertex AI in einer EU-Region schickt. Dieses Produkt macht den generativen Aufruf erst, wenn serverseitig eine ausdrückliche Einwilligung vorliegt. Was auch immer du von den Details hältst, die Lehre für uns ist einfach: Manche Regeln gehören in deine HTTP-Schicht und deinen Session-State, lange bevor irgendeine Agent-Schleife startet. Wenn die Prüfung in einem Prompt steckt, hat sie schon verloren.

Hier also die grobe Reihenfolge, an die ich mich in meinen eigenen Projekten halte. Mach das Tool so eng und so umkehrbar, wie das Geschäft es zulässt. Nutze Middleware pro Schritt, um alles zu entfernen, was der Agent nicht mehr braucht. Setz harte Regeln in ganz normalem PHP durch, bevor das Modell überhaupt aufgerufen wird. Nimm dann Approvable für das, was übrig bleibt, und zähl mit, wie oft es auslöst. Wenn eine Person mehr als eine Handvoll Freigaben am Tag sieht, würde ich das als Designfehler werten und nicht als Beweis für Sorgfalt.

Mich interessiert, wo du diese Grenze ziehst. Wenn du schon Agenten mit Freigabeschritten in Produktion laufen hast: Wie viele Bestätigungen pro Person und Tag sind machbar, bevor sie zum reinen Abnicken werden, und was hast du geändert, als du gemerkt hast, dass es passiert?