How is the floor component calculated?

The floor covers four cost categories: the compute cost of the autonomous operation at the contracted transaction volume, the Steward’s time allocated to governance of this customer’s system, the pro-rated Agentic Core infrastructure overhead, and a solvency margin of 20–30% above the combined cost. The floor should be lower than the customer’s current human-staffed cost by enough to make the baseline case for switching economically self-evident — the customer should be paying less for the autonomous operation than they were paying for the human-staffed equivalent even before the outcome share is applied. The floor is reviewed at contract renewal based on the actual compute cost profile of the preceding period.

What is the right outcome share percentage?

The outcome share percentage is negotiated at onboarding based on the documented baseline. The range is typically 15–25% of the verified Operational Arbitrage delivered in the measurement period. A lower percentage is appropriate when the customer’s baseline is well-documented and the arbitrage is highly predictable — the autonomous business can forecast its outcome share income reliably. A higher percentage is appropriate when the baseline is harder to document and the arbitrage is larger: the autonomous business shares more upside to compensate for the baseline uncertainty. The percentage is structured to ensure that the customer retains more than half of the Operational Arbitrage even at the maximum outcome share — preserving the incentive for the customer to continue the engagement as the arbitrage grows.

How does the pricing architecture interact with the Inference Floor?

The [Inference Floor](https://arcoventure.studio/lexicon/inference-floor) — the capability threshold at which all frontier AI models perform equivalently, making model costs a commodity — compounds the floor-plus-outcome-share architecture’s advantage over time. As the Inference Floor falls and model costs decrease, the compute component of the floor decreases. The autonomous business can either pass the cost reduction through to the customer by lowering the floor, or maintain the floor and improve its margin. The outcome share component is unaffected by Inference Floor movements: it is calculated against the customer’s baseline cost, which does not decrease when AI costs decrease. The Operational Arbitrage captured by the outcome share grows as the Inference Floor falls, because the autonomous operation’s cost falls while the human-staffed baseline it is compared against does not.

How does the pricing architecture affect the Turnkey Margin profile?

The floor-plus-outcome-share architecture produces a predictable cash flow profile that the [Turnkey Margin](https://arcoventure.studio/lexicon/turnkey-margin) assessment requires. The floor provides recurring baseline revenue that is forecastable and not dependent on system performance variability. The outcome share provides upside that is correlated with system performance but bounded by the documented arbitrage calculation. An acquirer evaluating the autonomous business sees a revenue model with a protected floor, a documented upside calculation, and an improving cost structure as Inverse Complexity Scaling takes effect. This profile is significantly more attractive than a pure outcome-based model’s variable revenue or a per-seat model’s revenue that would decline as the autonomous business’s own De-SaaS-ing discipline eliminates the user seats its pricing depends on.

Can the pricing architecture be applied to B2B autonomous businesses where the buyer is not replacing headcount?

Yes, with a baseline recalibration. The floor-plus-outcome-share architecture is not specifically about headcount replacement. It is about any operational cost the autonomous business reduces for the customer. In a B2B context where the customer is not replacing human staff but is reducing procurement costs, improving yield, or accelerating a revenue cycle, the baseline is the cost of the current state: what the procurement cycle costs in time and margin, what the yield loss costs in revenue, what the delayed revenue cycle costs in working capital. The outcome share is a percentage of the verified improvement against that baseline. The floor covers the autonomous operation’s costs regardless. The architecture transfers to any context where a verifiable before/after comparison can be documented.

Price the Arbitrage, Not the Seat

The Operational Arbitrage an autonomous business produces for its customers — the cost and output differential between the human-staffed operation it replaces and the agentic operation it installs — is the primary commercial asset. It is also the primary pricing anchor. The pricing architecture that captures the most value while remaining consistent with the autonomous business’s design is not the one inherited from SaaS pricing conventions. It is the one designed around the economic relationship between the autonomous operation’s cost and the customer’s baseline.

Three pricing models are available. Per-seat subscription pricing is what the SaaS market has standardised on. Pure outcome-based pricing is where the market appears to be moving. Neither is the right architecture for an autonomous business. The right architecture is the third model: a floor that covers the cost of autonomous operation plus an outcome share that captures the verified Operational Arbitrage delivered. Each model has a different risk profile, a different incentive alignment, and a different relationship to the autonomous business’s structural cost properties.

Why per-seat pricing is wrong

Per-seat pricing was designed for software that requires humans to use it. Every seat is a licence for a person to access a human-facing interface. The UI Tax is embedded in the per-seat model: the graphical interface development, the user training, the permissions infrastructure, and the subscription markup charged for enterprise UX are all costs that exist because a human must use the product to derive value from it. An autonomous business’s agents do not use graphical interfaces. The value is delivered through API calls and workflow executions, not through human-facing screens. Charging per seat for output that is generated without human involvement is pricing a capability with the wrong unit.

De-SaaS-ing — the replacement of per-user subscription software with API-first, compute-based infrastructure — is the market’s own confirmation of this logic. Every tool that migrated from per-seat to per-API-call pricing was confirming that its value was generated by computation, not by human interaction. An autonomous business that prices per seat for agentic output is applying the SaaS model to a fundamentally different product. Its buyers, who are evaluating the Operational Arbitrage of replacing human staff, will find the pricing structure inconsistent with the value they are purchasing.

Why pure outcome-based pricing is fragile

Pure outcome-based pricing is the pricing model that appears to follow from the Operational Arbitrage argument: charge only when value is delivered, and the price is proportional to the value. Two perspectives on the blog have established that outcome-based pricing is not the destination. The structural argument for why it fails as the sole pricing architecture for an autonomous business is risk allocation: pure outcome-based pricing transfers all execution risk to the autonomous business. If the autonomous system has a bad cycle — Logic Decay from data environment drift, an unusual input distribution, a novel exception class that requires Steward intervention to resolve — the business charges nothing while still paying compute costs, Steward time, and the Agentic Core infrastructure overhead.

Early-stage autonomous businesses cannot absorb pure outcome-based risk without a floor. The Revenue Loop requires continuity: the business must cover its operational costs across the cycles when performance is nominal and the cycles when it is not. A pricing model that charges nothing during below-nominal cycles produces a cash flow profile that is inconsistent with the fixed cost structure of autonomous infrastructure. The Operational Ledger improvement cycle that makes the system better over time requires continuous operation, not intermittent operation governed by whether any given cycle produced a chargeable outcome.

The floor plus outcome share architecture

The pricing architecture consistent with autonomous business design has two components. The floor covers the operational cost of the autonomous system: compute costs, Steward time, infrastructure overhead, plus a margin that makes the business solvent across cycles when performance varies. The floor is not negotiable. It is the price of access to the autonomous operation, regardless of any given cycle’s outcome. The floor is designed to be substantially lower than the customer’s current human-staffed cost — not to capture all the Operational Arbitrage, but to make the baseline case for switching economically self-evident.

The outcome share captures a percentage of the verified Operational Arbitrage delivered in each measurement period. Calculated against the customer’s documented Workforce Arbitrage baseline — the role-level cost of the human-staffed equivalent operation the autonomous system replaced — the outcome share aligns incentives: the autonomous business earns more when the system performs better, and the customer pays more only when the system produces more documented value. The percentage is negotiated at onboarding based on the documented baseline. The measurement is transparent and traceable, derived from the Operational Ledger and the Cost Attribution Layer that makes the Operational Arbitrage verifiable at the step and task-class level.

This architecture has three structural properties that make it consistent with autonomous business design. It protects the Revenue Loop solvency through the floor: the autonomous business covers its costs across all operational cycles, not just the high-performing ones. It aligns incentives through the outcome share: both parties benefit from the system performing better, and neither party is advantaged by underreporting performance. And it compounds: as Inverse Complexity Scaling takes effect and the cost per unit of output falls, the Operational Arbitrage delivered per period increases, and the outcome share component grows without requiring price renegotiation.

The Operator’s Verdict

The pricing architecture is the mechanism through which Operational Arbitrage becomes revenue. A per-seat model gives away the structural advantage by pricing a capability with the wrong unit. A pure outcome-based model transfers the execution risk that the autonomous architecture was designed to manage. The floor-plus-outcome-share model captures the arbitrage, protects the Revenue Loop, and aligns the autonomous business’s incentives with its customers’. Both parties earn more when the system performs better. Neither party is advantaged by underperformance.

Technology changes what can be delivered for the cost. Pricing determines how much of that cost advantage the business captures.

KEY TAKEAWAY

What is the pricing architecture for an autonomous business and why does it differ from SaaS pricing conventions?

The pricing architecture for an autonomous business is a floor plus an outcome share. The floor covers the operational cost of the autonomous system — compute, Steward time, infrastructure overhead, and a solvency margin — and is charged regardless of any given cycle’s performance. The outcome share captures a percentage of the verified Operational Arbitrage delivered in each measurement period, calculated against the customer’s documented Workforce Arbitrage baseline. This architecture differs from per-seat SaaS pricing because the UI Tax embedded in seat-based pricing is structurally absent from an autonomous operation: agents do not use graphical interfaces and value is not delivered through human interaction. It differs from pure outcome-based pricing because pure outcome-based pricing transfers all execution risk to the autonomous business, producing a cash flow profile inconsistent with fixed infrastructure costs. The floor-plus-outcome-share architecture protects Revenue Loop solvency through the floor, aligns incentives through the outcome share, and compounds as Inverse Complexity Scaling reduces the per-unit cost of autonomous operation over time. Key principle: the outcome share component is calculated against the customer’s documented Workforce Arbitrage baseline, not against an arbitrary benchmark. The Operational Arbitrage is the differential between the autonomous operation’s verified cost-per-unit and the customer’s human-staffed cost-per-unit.