The Economics of the Agent Economy

A Whitepaper of the Open Agent Protocol

Version: 1.0 Status: Public Working Draft Date: May 2026 Authors: OAP Commercial Layer Working Group

Abstract

The economic substrate of the existing internet was designed for human consumers who decide once a month what to subscribe to and once an hour what to buy. Its dominant primitives are the credit card transaction, the monthly subscription, the platform takerate, and the marketing funnel that brings the human to the moment of decision. None of these primitives is well suited to the volumes, the latencies, the granularity, or the autonomy of agent driven commerce. An agent that acts on its principal's behalf at machine speed cannot wait for a human to enter card details, cannot tolerate the seven dollar minimum charge that a card network considers economic, cannot reasonably enter into a monthly subscription for a tool it will use only once, and cannot be trusted to discriminate between providers without machine readable evidence of cost, latency, and quality. The Open Agent Protocol responds to these requirements with a normative commercial layer that defines pricing models, a portable wallet abstraction, a settlement format anchored in the same Receipt chain that anchors accountability, and a discovery surface that lets agents make build versus buy decisions on the basis of comparable evidence rather than marketing copy. This whitepaper sets out the design rationale behind that layer, explains why each design choice is necessary, and examines the structural consequences that follow once an entire economy is mediated by the resulting primitives.

1. Why the Existing Payment Stack Does Not Fit

The first observation is the most basic. The unit economics of card payments make them unusable at the scale at which agents operate. A typical card payment carries a fixed cost of roughly thirty cents plus a percentage in the low single digits. An agent invocation that costs a tenth of a cent cannot be billed through such a stack without aggregating thousands of invocations into a single charge, which defers settlement, complicates dispute, and forces every operator to act as its own clearing house. The aggregation can be made to work, and many operators have built it, but it is a workaround imposed by an inadequate primitive rather than a structural answer to the requirement.

The second observation is that the autonomy of the agent collides with the underwriting model of the card networks. A card payment depends on the cardholder's intent at the moment of payment. The cardholder is presumed to be present, to have authorized the specific charge, and to be available to dispute it. An agent acting on its principal's behalf is none of these things. The principal authorized a category of behaviour, not a specific charge. The principal is asleep when the charge is incurred. The dispute mechanism, which assumes a human who can describe what happened, is incompatible with the volume of small charges that an agent generates. Card networks have responded to comparable problems in other domains by inventing card not present rules, recurring billing rules, and merchant initiated transaction rules, and the same approach could in principle be extended to agent initiated transactions. None of those extensions, however, recovers the latency, the unit cost, or the dispute model that an agent economy requires.

The third observation is that the platform takerate that subsidizes the contemporary commerce stack does not survive the move to a substrate in which the platform is replaced by a discovery layer that any participant may operate. A card network that takes three percent of every transaction is sustainable only when the network's gatekeeping role gives it the leverage to extract the rent. A discovery layer that publishes a machine readable manifest at a well known URL has no comparable leverage and cannot sustain comparable rent. The Open Agent Protocol therefore declines to make the platform takerate part of its commercial layer. The protocol's commercial layer is operated by parties who compete on price, latency, and reliability, and the protocol's design forecloses any rent that depends on incumbency.

2. Pricing Models and the Constraint of Machine Comparability

The Open Agent Protocol normatively defines five pricing models in RFC 0013 that together cover the practical space of agent commerce. The free model declares that an action carries no charge and is suitable for connectivity testing, public information, and any other case in which the operator has chosen not to monetize. The per call model declares a fixed amount per invocation and is suitable for actions whose cost to the operator is roughly constant per invocation. The subscription model declares an interval based recurring charge in exchange for unlimited or rate limited use of an action set and is suitable for relationships in which the consumer's value is approximately predictable. The usage metered model declares a charge per declared unit of consumption such as tokens, megabytes, or compute milliseconds and is suitable for actions whose cost to the operator scales with measurable input. The outcome model declares a charge contingent on a declared trigger event such as a successful booking or a confirmed delivery and is suitable for actions whose value to the consumer is concentrated at the outcome rather than spread across the process.

The choice to fix the set of pricing models is deliberate, but it is not closed. RFC 0014 generalizes the five named models into a single five axis Commerce Primitive whose orthogonal dimensions cover the full surface of human and agent commercial activity, and it demonstrates that ten further models drawn from existing real world commerce, including retail purchase, lending, leasing, advertising, professional services, and insurance, are all expressible as presets over the same axes. A pricing model that an agent cannot parse is a pricing model that the agent cannot use to choose between providers, and a pricing model that the agent cannot use to choose between providers is functionally absent from the marketplace. The five normative models of RFC 0013 and the generalized primitive of RFC 0014 are intentionally narrow in their dimensions so that any conformant agent can read any conformant manifest and rank the providers it discovers on a like for like basis. Operators who require pricing structures outside the named presets are required to express those structures through compositions of the normative axes, which preserves comparability at the cost of some expressive freedom. The trade off is justified by the value that comparability creates, which is the precondition for an honest market in agent services.

The decimal string requirement on monetary amounts deserves brief mention. Floating point representations of money introduce rounding errors that aggregate across millions of micro transactions into discrepancies that become difficult to reconcile. The protocol forbids the floating point representation and requires decimal strings, which is the same convention that mature financial systems have long since adopted for the same reason. The currency is identified by the relevant ISO standard, which avoids the failure mode in which a tool denominates its prices in an ambiguous string such as dollar or euro and leaves the agent to infer which dollar and which euro is intended.

3. The Wallet Abstraction and the Portability Requirement

The Open Agent Protocol specifies a normative interface for a Wallet that funds Agent activity. The Wallet, defined in RFC 0014, exposes operations for retrieving the current balance, for authorizing a hold against future spend, for capturing a previously authorized hold, for refunding a captured amount, for retrieving a signed statement of activity, and for reading and setting per Tool, per Agent, and per period spending limits. The interface is deliberately small. It is sufficient for a Wallet to be the source of funds for any Invocation that carries a cost, and it is small enough that any party with the appropriate licensing can implement it.

The portability requirement is the single most important property of the Wallet abstraction, and it is the architectural expression of the principle of memory and identity portability set out in RFC 0016. A Principal must be able to export the complete ledger of activity in a Wallet and import it into a different Wallet provider. The export must be cryptographically verifiable so that the receiving provider can confirm the authenticity of the ledger without trusting the originating provider. The portability requirement forecloses the lock in dynamic that has historically allowed payment platforms to extract rent from their installed base, and it composes with the Replaceability Index defined in RFC 0015, which extends the same discipline to every other primitive a provider exposes. A consumer who finds the terms of a Wallet provider unsatisfactory can move to a competitor with no loss of history, no loss of subscriptions, and no loss of standing in the receipt chain. The threat of departure is the discipline that keeps Wallet providers honest. The protocol provides that discipline at the architectural level rather than asking the regulator to provide it after the fact.

The regulatory posture of Wallet providers is the second important property. A Wallet that holds Principal funds is functionally an electronic money institution, and the protocol requires Wallet providers to be regulated as such in their primary jurisdiction or to operate through a partner who is. The requirement aligns the protocol with the existing supervisory structure for held funds, which is well understood, well staffed, and well integrated with the deposit insurance and reserve mechanisms that protect consumers in the event of operator failure. Crypto denominated balances are similarly required to comply with the markets in crypto assets regime where applicable. The protocol does not invent its own regulatory regime for held funds. It composes with the regimes that already exist.

4. Settlement and the Anti Invoice Property

A Settlement in the Open Agent Protocol is a signed event that transfers value between two parties in respect of one or more underlying Invocations. The Settlement Receipt, defined in RFC 0014 and structurally aligned with the Receipt format described in Accountability in the Agent Economy, cites the Invocation Receipts that it covers, the cost recorded in each cited Invocation Receipt, the aggregated amount, the currency, the rail used, and the timing. The Settlement is signed by the Wallet operator and by both counterparties. The combination of the citation and the signatures yields what we call the anti invoice property.

The anti invoice property is the property that a Settlement does not require either party to trust the other party's invoice. The amount asserted in the Settlement is verifiable independently by any party that can read the cited Receipts and the Manifest of the Tool that produced them, where the Manifest is the structured publication defined in RFC 0005 and discoverable through the well known endpoints specified in RFC 0012. If the Settlement claims that an Invocation cost a hundredth of a cent, any verifier can confirm that the relevant Invocation Receipt records that cost and that the cost matches the pricing declared in the Manifest at the time of the Invocation. The familiar dispute pattern in which the consumer argues that the invoice does not reflect the service received is therefore eliminated by construction. The invoice is the receipts.

The anti invoice property has a second consequence that is easy to overlook. It eliminates the need for the operator to maintain a separate billing system that reconciles its delivery records with its charges. The delivery record is the bill. This collapses a major source of operator complexity, of operator cost, and of opportunity for opaque rent extraction. Operators who rely today on the complexity of the billing surface to disguise unfavourable terms will find that the complexity is no longer available to them. The terms must be expressible in the manifest, and the manifest must produce receipts that match.

5. The Build Versus Buy Decision Protocol

A market is honest only if its participants can compare offers on a like for like basis. The Open Agent Protocol formalizes the comparison through the Build Versus Buy Decision Protocol described in RFC 0014 and elaborated in section 3.7 of RFC 0013. The protocol requires that any Tool participating in the commercial layer publish, alongside its pricing, a token equivalent cost that expresses the cost of the action in a normalized unit, a measured latency in the relevant percentiles, and a quality evidence link that points to either an audit report, a public benchmark, or a conformance receipt issued under RFC 0019 and described in detail in Verifiable Conformance. The agent considering whether to invoke the Tool can therefore evaluate the proposed Invocation against alternatives, including the alternative of building the capability locally rather than buying it from the Tool.

The build versus buy decision is the engine that distinguishes a competitive market from a captured one. A consumer who can credibly threaten to build is a consumer for whom the market must compete, and a consumer who cannot is a consumer who pays whatever the market charges. The protocol's contribution is to make the build versus buy decision computable. The agent does not need to consult a procurement department or a benchmarking firm. It reads the published cost, latency, and quality evidence, computes the cost of the alternative, and chooses on the merits. The choice is then recorded in the Decision Record that accompanies the Receipt, which means that the basis of the choice is auditable after the fact, and the reputation of the chosen provider is updated through the Performance Record mechanism of RFC 0009.

6. Anti Monopoly Properties of the Commercial Layer

The architecture described above has structural anti monopoly properties that are worth making explicit. The Wallet portability requirement of RFC 0014 eliminates the lock in that has historically anchored payment platform monopolies, and the Replaceability Index of RFC 0015 extends the same discipline to every other primitive a provider exposes. The pricing model normativity of RFC 0013 eliminates the obfuscation that has historically allowed dominant operators to disguise unfavourable terms. The Receipt anchored settlement eliminates the dispute asymmetry that has historically allowed operators to under deliver and over bill. The published manifest required by RFC 0005 and the open ranking algorithm requirement on conformant Match Brokers under RFC 0013 eliminate the algorithmic gatekeeping that has historically allowed dominant marketplaces to extract rent from their listed providers. The build versus buy decision protocol eliminates the information asymmetry that has historically allowed dominant providers to charge above cost. The User Sovereignty Charter of RFC 0016 ratifies all of these properties as user-facing rights that no protocol revision may remove without breaking conformance.

Each of these properties has been argued for in detail in the antitrust literature on digital platforms, and each of them has been the subject of regulatory intervention in major jurisdictions. The contribution of the Open Agent Protocol is that it embeds the properties into the protocol itself rather than relying on regulators to compel them after the fact. A market that is structurally pluralistic at the protocol level is a market that does not require constant regulatory rescue.

7. Conclusion

The economics of the Agent Economy are not a marginal extension of the economics of the human consumer internet. They are a different system that requires a different substrate. The Open Agent Protocol provides that substrate with a small, normative set of pricing models, a portable Wallet abstraction grounded in the existing regulatory regime for held funds, a settlement format anchored in the Receipt chain, a comparability surface that lets agents make build versus buy decisions on the merits, and a structural posture that forecloses the rent extraction patterns of the contemporary platform economy. The result is an economy in which the price of an action is what the action actually costs, the choice between providers is made on the basis of evidence, and the discipline of competition is enforced by the protocol rather than by the regulator.

References

OAP-CORE-1.0. The Open Agent Protocol Core Specification.

RFC 0008: Workflow Composition. Defines the multi-step compositions over which pricing aggregates.

RFC 0013: Commerce Models for the Agent Economy. Defines the five normative pricing models referenced throughout this paper.

RFC 0014: Commerce Primitives, A Generalized Commercial Layer. Defines the Wallet, Settlement Receipt, and Build Versus Buy Decision Protocol.

RFC 0015: Composable Software Primitives. Defines the Replaceability Index that disciplines provider lock-in.

Regulation (EU) 2023/1114 on Markets in Crypto Assets.

Directive (EU) 2015/2366 on payment services in the internal market (PSD2).

ISO 4217. Codes for the representation of currencies.