Full narration of the briefing. Click a section heading to jump the player to that moment.
An enterprise agreement here is doing a different job from a licence agreement. It is not defining who may install what. It is defining a meter, a rate, and what happens when reality diverges from the forecast. I am Tom, Claire is with me, and we are going to go through the six things this paper has to settle.
And a note on evidence: we are describing what a well drafted agreement should cover, from our engagements. We are not going to tell you what discount is standard, because that is not public and anyone claiming to know it is guessing.
First, the commitment, and the shape matters more than the number. Ask what happens to unused commitment at the end of each period: is it forfeited, does it roll forward, or is there a true up window. Ask whether the commitment is annual or spread across the term, because a term wide commitment gives you room to be wrong in a single year. And ask what triggers a step up in the ramp, so that growth you have not achieved cannot pull you into a higher tier you then have to fund.
Second, the rate card, and this is nearly the opposite of every other software negotiation we do. In most categories you fight for a price hold, because prices go up. In this market published rates have generally come down as models get more efficient. So a rate locked for three years can turn into a rate above the market you could have had.
What you want is protection against increases without being locked out of decreases, meaning the better of your negotiated rate and the prevailing published rate. Ask for that explicitly, because you will not get it by accident.
Third, data handling, and for most of our clients this is what legal and security actually care about. Get the position on whether your inputs and outputs are used to train models written into the agreement rather than relied upon from a public policy page, because a policy page can change and a contract cannot. Then the ordinary enterprise questions: retention periods, where data is processed, sub processors, deletion on termination, and what the audit rights are. None of this is exotic.
It is simply easier to get before signature than after.
Fourth, and this one has no equivalent in traditional software. The specific model your application depends on may be deprecated during your term, because this field moves quickly and older models get retired. That is a real operational risk if you have tuned prompts, evaluations and guardrails against one model's behaviour. So ask for notice periods on deprecation, ask how long a retired model remains available, and ask what migration support looks like.
Treat it exactly as you would an end of support date on any other platform, because that is what it is.
Fifth, capacity. Consumption pricing assumes you can consume, so if your workload is spiky or business critical, ask what throughput you are entitled to and what happens at your peak rather than at your average. And sixth, service levels: availability, latency where it matters to you, support response, and a named escalation path. Ask what the remedy is when a level is missed, because a service commitment with no remedy attached is a statement of intent rather than a term of the contract.
And the order matters. Settle flexibility first: the shape of the commitment, rollover, the ramp triggers. Then the protections: data terms, deprecation notice, capacity, remedies. Then the rate, last, because a strong rate on a rigid commitment you cannot meet is worse than a fair rate you can actually use.
That ordering is the same conclusion we reach with every vendor, and it is more true here than anywhere, because your forecast is less certain here than anywhere. Next time, Daniel and I are honest about why this is hard.
Redress Compliance works on contingency: our fee is 25 percent of what we save you. Nothing saved, nothing paid. Independent, buyer side only, never vendor funded. Want Redress to contact you? Reach out and we respond the same day.
Talk to a Anthropic negotiator