Picture your support lead on a Thursday afternoon, three hours into a shift where the new AI assistant has asked her to confirm forty-one tool calls. The first six she read line by line, checking arguments, comparing IDs against the ticket. By call thirty she's pressing the green button the way you press Enter on a composer update prompt: from muscle memory, eyes already on the next thing. Nothing about that is negligent. Humans do this with any prompt that shows up often enough. And it's exactly how I expect a lot of teams to use the shiny new approval feature in Laravel AI SDK 1.0.

Quick facts for anyone who missed the release on September 23. A tool that implements the Approvable contract and pulls in the InteractsWithApprovals trait no longer just runs when the model picks it. The agent stops and hands you the pending calls along with the arguments the model chose. You answer each one: let it through, turn it down with a reason the model will see, or change the arguments before execution. It works across prompt, stream, queue and the broadcast methods, so a queued agent can sit suspended until someone gets around to it. Good engineering, and I'm glad it ships with the framework.

My position is that you should treat Approvable as the last line of your design, and never the first. If a tool is dangerous enough that you want a human to look at every call, first ask whether you can make it less dangerous. That beats asking a tired person to be your safety mechanism forty times a shift. A tool called `DeleteFile` that takes any path is a loaded question. A tool that can only move files from one specific tenant folder into a soft-delete bin that gets purged after thirty days usually doesn't need a confirmation at all, because the worst thing it can do is annoying and reversible.

The same release gives you a quieter lever I find more interesting for this. Middleware now runs on every generation step instead of once per prompt, and it receives a PendingStep you can modify. You can switch to a different model, drop tools from the list or cut the token budget while the agent is running. To me that's capability removal as a first-class idea. The agent read the invoice it needed? Take the write tools away for every step after that. The model can't call a tool it doesn't have, and nobody has to click anything for that guarantee to hold. Go folks like to boast that their interfaces are small. Here's our chance to keep an agent's toolbox small too, one step at a time.

Now the honest counterpoint, because it's a strong one. Some actions can't be made safe by narrowing them. A refund is a refund. An email to a customer can't be recalled, however carefully you scope the template. There, a human really has to look, and a well-built pause beats every homemade flag-in-a-database approach I've seen in Laravel apps over the years. Being able to fix a wrong argument, instead of throwing away the whole run, also means the person reviewing has a reason to actually read what's on screen. I accept all of that. My point is about volume. Approval stays meaningful only while it's rare enough for a person to take each one seriously.

There's also a class of risk no approval button can cover. Gabriele Pieretti, who builds a virtual mirror product for hair salons, wrote about this release from the view of an app that sends client photos to Gemini on Vertex AI in an EU region. That product only makes the generative call once explicit consent exists on the server side. Whatever you think of the details, the lesson for us is simple: some rules belong in your HTTP layer and your session state, well before any agent loop begins. If the check lives in a prompt, it has already lost.

So here's the rough order I'm using in my own projects. Make the tool as narrow and as reversible as the business allows. Use per-step middleware to strip away whatever the agent no longer needs. Enforce hard rules in plain old PHP before the model is even called. Then use Approvable for whatever is left, and count how often it fires. If one person sees more than a handful of approvals a day, I'd treat that as a design bug and not as proof of diligence.

I'd like to know where you draw that line. If you're already running agents with approval steps in production, how many confirmations per person per day can you sustain before they turn into rubber stamps, and what did you change once you saw it happening?