tl;dr Whatever the contract says, your team reads the meter as policy. An opaque unit teaches hesitation, an invisible count teaches asking permission, an unknown cap behavior teaches running the smaller job. You cannot train that away with enablement. The fix is a legible meter and a three-line memo: this is the unit, here is the live count, this is exactly what happens at the cap.
There is a scene playing out this week in most teams that bought agentic software this year. An operator has a run ready to go. It is the right run: the account is live, the moment is now. And they are sitting on it, because the run consumes an allowance somebody else owns, at a rate nobody can state, toward a cap whose behavior nobody has read.
Chris wrote on Tuesday about what vendors started counting, and buried in the buyer's argument was an operational one: "A meter isn't only a commercial instrument. It is a permission structure, and your team reads it that way whether or not you meant it to be one."
That sentence deserves its own note, because the meter conversation usually stops at procurement. The contract gets signed, the rate card goes in a drawer, and the meter goes on to run your team's behavior for the next two years.
Strip Chris's three buyer questions to their operational form and you get three properties of a meter, each of which trains a behavior.
Unit legibility. Can the person taking an action state, in one sentence, what it costs? If yes, they spend judgment on whether the action is right. If no, they spend it on whether the action is affordable, which is a different question they are worse at answering.
Count visibility. Can the person spending the allowance see the live count, or does the count live in an invoice someone else reads at month-end? A visible count produces self-regulation. An invisible one produces two failure modes at once: the cautious operator who under-uses the tool, and the surprise overage from the one who didn't.
Cap behavior. Does everyone know, before it happens, what the tool does at the limit: stops, charges, or degrades? The teams that know run confidently right up to the cap. The teams that don't leave a safety margin whose width is set by anxiety rather than arithmetic.
WHAT THE METER TRAINS (static figure: three meter properties mapped to the behaviors they train) Each property of the meter is a lever on team behavior, whether or not anyone pulled it on purpose. The unit (what one action costs). When it's legible: judgment goes to the work, "is this run right?" When it's not: judgment goes to the bill, hesitation before every run. The count (who can see it, live). When it's legible: self-regulation, the spender watches their own gauge. When it's not: "Can I run this?" queues, plus the month-end overage surprise. The cap (what happens at the limit). When it's legible: confident use, right up to the known edge. When it's not: anxiety margins, the smaller job, run permanently, to be safe.None of this shows up in week one. It shows up as habits.
Hesitation first: the pause before every run that should have been reflexive. Then delegation upward: "can I run this?" questions arriving at whoever owns the budget, which converts a tool you bought for speed into a queue with an approval step. Then batching: saving up runs to spend the allowance deliberately, which is rational behavior and exactly wrong for a tool whose value is responding to moments while they are moments. And finally shrinking: running the smaller version of the job to be safe, permanently, until the smaller version is the job.
THE HESITATION LOOP (interactive: toggle unit legibility, count visibility, and cap behavior; the operator's decision path re-renders across run now, ask first, batch it, shrink the job) Meter state to the behavior it trains (illustrative, not a benchmark): Unit legible, count visible, cap known: run now. Judgment goes to the work; the run happens while the moment is a moment. Unit legible, count visible, cap unknown: batch it and shrink the job. An anxiety margin appears, and the smaller version of the job becomes the job. Unit legible, count invisible, cap known: ask first and batch it. Asking first becomes the norm, runs get saved up, and moments expire in the batch. Unit legible, count invisible, cap unknown: ask first and batch it. The invisible count dominates before the cap is ever reached. Unit opaque, count visible, cap known: ask first and shrink the job. The operator cannot price the action, so the question goes upward and the job shrinks to be safe. Unit opaque, count visible, cap unknown: ask first and shrink the job. The opaque unit dominates. Unit opaque, count invisible, cap known: ask first and shrink the job. The opaque unit dominates. Unit opaque, count invisible, cap unknown: ask first and shrink the job. Every property is illegible; hesitation is the whole loop. Behavioral outcomes illustrative, not a benchmark. The mapping is the argument, not a measurement.The cruel part is what the renewal review sees: low usage. Both sides conclude the team didn't adopt the tool. Nobody in the room can see that the team adopted it fine and then trained themselves away from it, one ambiguous allowance at a time. Hesitation is a cost that never appears on the invoice it protects.
If you own a tool with a meter, the fix costs three lines and an afternoon. Write the internal meter memo:
Send it to everyone who touches the tool. If you cannot write line one, you have rediscovered Chris's conversion-table problem. If you cannot write line two, you have found out the vendor's record is the only record. If you cannot write line three, you are one busy month away from learning it from the invoice. In all three cases the memo failed for an interesting reason, and the reason is a finding about the vendor, not about your team.
We can show our own homework here. Bryn is not another dashboard to watch. It is the governed execution layer that runs Plays through your stack, and its meter was designed to be read by the operator, not just the CFO.
The unit is identified accounts: the companies Bryn resolves and watches during a billing cycle, one sentence, no conversion table. The count is in the audit log, the same exportable record that answers the three questions, so the person running Plays and the person reading the invoice are looking at the same number. And the cap behavior is published: new identifications pause, running Plays keep running, no overage charges, and the pause itself is written to the log.
Chris's version of the consequence is the one to keep: nobody on your team should be doing arithmetic before they run a Play. That is not a pricing feature. That is the permission structure, working.
Two years from now, your renewal conversation will mostly be a conversation about usage. Usage is downstream of permission, and permission is downstream of the meter. Which means the time to fix the permission structure is now, while it is still a memo and not a pattern.
Read the unit. Surface the count. Publish the cap. Then watch what your team does when the next moment fires and nobody has to ask.