Govern AI spend by notification and trust rather than a cap - alert at a thousand over, and if the person knows what they are doing get out of their way
Situation
Peter met with Steve Wallace and Scott Moody on AI and cloud costs Aug 24 at 11am, then recounted the outcome to Ryan and Bjorn an hour later. What he asked for is visibility plus a Slack notification when someone goes a thousand dollars over their limit, followed by a second one. The rule attached to the notification is not a stop - it is: if you do not know you are doing that, stop what you are doing and figure it out, and if you do know what you are doing and it is right and you are a smart person and it is right, I do not want to get in your way. He explicitly declined a single best-practice standard, differentiating by workload: Sultan costs are fine because he is dealing with a CVE swarm and the right behaviour is solve it as fast as you possibly can, whereas Jason Rodriguez spinning up 13 Opus or Fable agents makes no sense - but Peter attributed that to missing visibility rather than to judgment. He named his own next step as a person-by-person conversation with each leader over what he can now see. Separately on cloud costs he closed the question rather than opening it: the split is 100 percent Fuzzball, and he told Bjorn and Ryan they just need to get used to that being the new normal, while committing to sit with Wolford to slice it up.
Reasoning
Peter is treating the number as an information problem first and a behaviour problem only afterwards. His read on the 13-agent case was that the person lacked visibility into what he was doing, so the intervention that fits is showing him, not capping him - a cap would punish a state he could not see. The trust clause is doing deliberate work: a threshold alert that carries an implied prohibition converts every spike into a request for permission and pushes cost decisions up to Peter, which is the opposite of what he wants from smart people. Refusing a uniform best practice comes from the same place - the correct spend for a CVE swarm and the correct spend for agent sprawl are different numbers, and any single standard would be wrong for one of them. On cloud he made the opposite move because the fact pattern is opposite: the spend has a single identified owner and a product reason, so the useful act is to stop the recurring investigation and reset the baseline expectation rather than keep treating it as an anomaly.
Additional Context
This is the mechanism for the Aug 19 decision to refuse to act on the AI spend number until it was decomposed and then treat the remainder as usage discipline rather than a spend cap. The decomposition has now happened and produced a map of who is spending what.
Observed Evidence
Peter: It is visibility. So it is just getting me a map of who is spending what and now I can see it. So next on my list is sitting down with each of you and going over what I can see and talking about the costs in your world. Peter: the best practice behavior depends. Like for somebody like Sultan who is dealing with a CVE swarm coming in, it is solve the thing as fast as you ever possibly can. Peter: For something like Jason Rodriguez, I think he is spinning up 13 agents. They are all opus agents or fable agents. And it makes no sense. But I also do not think he had visibility. Peter: on the cloud costs specifically, you guys just need to get used to that being the new normal. Peter, to Ryan: Right, but do not dump all of Linux into Fable.
Confidence Breakdown
Reasoning Depth Analysis
People Involved
Source
reflection
AI Confidence
87%
Related Context
fathom
you are going to start seeing you and others will get notifications in Slack. Hey, you just spent 1000 dollars over your limit. ... Do you know that you are doing that? If you do not, stop what you are doing and figure it out. And if you do it, if you are doing it and you know what you are doing and it is right and you are a smart person and it is right, I do not want to get in your way.
calendar
Aug 24 11:00-11:30 PT, the meeting whose outcome Peter recounted an hour later.
Outcome
No outcome recorded yet.
Decision ID: ea6e4797-05ce-4d6e-94c0-22817cc8a9bd