Standardize the Binding, Not Just the Cap
Most agent-payment proposals standardize what’s present on the wire. The enterprise question is what’s provable about it.
Enterprise Agent Architecture adds a fifth domain to the classical four, and that domain has four layers: Workforce, Capability, Control Plane, and Governance. Most agent-payment proposals today live almost entirely in the Capability layer — they describe what a "payment required" state should carry on the wire: network, asset, amount cap, recipient, expiry, idempotency key, proof-header shape, denial reason. That list is the right instinct. It is also drawn at the wrong altitude to answer the question an enterprise actually has to answer.
Present Is Not Provable
Those fields standardize what is present in a transaction. They are silent on what is provable about it.
The distinction is an architecture decision, not a wire detail. A spend cap that is present on the wire is not a spend cap a downstream system can prove was the one the mandate authorized. An intermediary forwards a well-formed challenge whose cap, recipient, or expiry no longer matches the authority that issued it. The Capability layer sees a valid-looking transaction. The Governance layer inherits drift it cannot detect. In a regulated enterprise — where the audit question is not "did the payment succeed" but "was this agent permitted to spend this, against whose mandate, under what limit" — that gap is the whole exposure.
The Binding Belongs to the Workforce Layer
The binding belongs to the Workforce layer that authorized the cap — not the Capability layer that carries it.
A content-addressed reference — guardrail_ref — ties amount_cap + recipient + expiry to the authorizing mandate and travels into the post-payment evidence. The Governance layer then evaluates the action against the authority that actually permitted it, not against a number an intermediary asserted. The cap value stays implementation-local in the Capability layer. The binding to the mandate is the contract the Workforce layer has to make machine-checkable at every boundary the transaction crosses.
The Architectural Lesson Under the Security One
This is the architectural lesson under the security one. When a spend limit is specified only in the Capability layer, every other layer inherits whatever that layer happened to forward. When authority is bound at issue and carried as evidence, the Governance layer can reconstruct the decision after the fact — which is the only version of "auditable" that survives a regulator.
Which Layer Owns the Proof
Enterprise agent platforms set spend limits on agent actions; Salesforce's Agentforce, for example, will do the same. The platform question is not whether the limit exists. It is which layer owns the proof that the limit was the authorized one.
Standardize the binding, and the cap takes care of itself.
About This Series
Michael K. Saleme — Enterprise Agent Architect
A field note applying the Enterprise Agent Architecture layer model to a live standards question: where a spend limit’s authority is bound, and which layer has to prove it.
This page is the canonical version of an essay also published to the Enterprise Agent Architecture newsletter.
Cite the Position Paper
This essay develops the Enterprise Agent Architecture position paper, which is published and peer-citable on Zenodo under CC BY 4.0. Cite the concept DOI — it always resolves to the latest version.
Saleme, M. K. (2026). Enterprise Agent Architecture: The Case for a Fifth Architecture Domain for the Agentic Enterprise. Zenodo. https://doi.org/10.5281/zenodo.21105314
BibTeX
@misc{saleme2026eaa,
author = {Saleme, Michael K.},
title = {Enterprise Agent Architecture: The Case for a Fifth Architecture Domain for the Agentic Enterprise},
year = {2026},
publisher = {Zenodo},
doi = {10.5281/zenodo.21105314},
url = {https://doi.org/10.5281/zenodo.21105314}
}
Michael K. Saleme
Enterprise Agent Architect · Cognitive Thought Engine