Spend policies for agents that buy

The one question the layer answers

The commerce layer of the agentic internet is not another wallet and not a rail. It is a policy format and a pure evaluator that sits over whatever rail actually moves the money — a wallet SDK, a stablecoin transfer, a card — and answers one question: given this policy and this proposed payment, may it go, must it stop, or must a person decide. The open spec is pay-policy/1, and keeping it to that one question is what lets it sit over any rail without becoming one.

The answer is three-valued on purpose — allow, deny, escalate — because the case that matters operationally is the one a boolean throws away: a payment inside the policy but above the line where somebody should be asked. That is neither an approval nor a denial; it is an escalation, and it needs a named owner and a record the same way a reconciliation break does. Deny and escalate always carry reasons, and every failing check is named rather than only the first.

Minor units only

Every figure in a policy, a payment or a ledger state is a whole number of minor units beside an explicit currency. A float anywhere is refused; a figure with no currency is not money; a string is not an integer. The checker refuses a value like 2500.0 in the file text before the JSON parser can quietly round it to an integer. This is the identical discipline this practice applies to any money system it builds: a cap compared as a floating-point number degrades silently once values cross the point where floating-point arithmetic stops being exact, and it degrades in the direction that makes a cap stop capping.

A child policy may only narrow

A policy can be attenuated for a sub-agent, and the child may only narrow: caps no higher, allowlists a subset, rails a subset, jurisdictions a subset, the human gate no higher, same currency, same period. The attenuate operation refuses any widening and names every dimension that widened. This is the commerce layer’s version of the identity layer’s attenuation rule — the same shape applied to money instead of scope — and it is what lets an organisation hand a narrower spending authority to a sub-agent without any risk that the sub-agent ends up able to spend more than its parent.

A human gate on money is mandatory

The refusal that a firm should care about most: any policy whose per-transaction cap is above zero must carry a human-approval threshold, and it must be strictly below that cap. A gate no permitted payment can ever reach is a missing gate wearing a number, and the checker treats it as one. A closed policy — cap zero, able to pay nobody anything — may omit the gate, because it can never reach it. Everywhere money can actually move, a human decides above a line, by construction rather than by discipline.

{
  "decision": "escalate",
  "reasons": [
    { "code": "HUMAN_APPROVAL_REQUIRED",
      "message": "30000 is above the human-approval threshold of 20000 USD minor units; a person must approve" }
  ]
}

A pure evaluator, and why unknown is not zero

The evaluator reads no clock, opens no connection, and mutates nothing. The period’s spending-so-far is injected as a ledger state, never fetched inside the evaluator — which keeps the same grading function safe to call speculatively, to preview a verdict in an interface, without a side effect to undo if the person says no. And when a policy caps a period but no ledger state is supplied, the answer is deny, not allow, because unknown is not zero. A cap that silently permits everything when it cannot see the running total is worse than no cap, because it looks like protection. Reserving spend against the cap happens only after an allow, and is the caller’s job — which is exactly the separation between grading and committing that this practice designs into any agent that touches money.

• The lab’s view (planned)FlashyLabs is preparing an engineering companion to this piece at https://flashylabs.com/insights/spend-policies-for-agents-that-buy — planned, not yet published.
• The studio’s view (planned)The 4 Ventures thesis desk is preparing an investor-lens companion at https://4.ventures/thesis/spend-policies-for-agents-that-buy — planned, not yet published.