DevDay's Missing Slide: Who Gets Paid in the Agent Platform Economy

01 Where DevDay actually landed

OpenAI used this year's DevDay to hand developers a kit of agent-building tools: primitives for constructing assistants that plan, call other software, and complete multi-step work with less hand-holding. The announcements described a platform taking shape, one where independent developers can publish agents to an audience the size of ChatGPT's, which was recently ranked the fifth-most-visited website in the world. What the keynote did not show was the slide that matters most to the people in the room: the payment flow.

That omission is standard practice, and it is also the whole story. A platform's revenue architecture—who pays whom, and what percentage the house keeps—determines what gets built on top of it. DevDay supplied the pipes; the monetization mechanics remain inference. This piece reconstructs the plausible shapes of that payment flow from comparable platform economics and labels every number illustrative.

02 How money can move through an agent platform

Four channels can carry revenue across an agent platform, and each has a different take-rate shape. The first is a share of end-user subscriptions: the ChatGPT consumer tier already runs on a freemium model, and a cut of premium subscriptions that unlock third-party agents resembles the classic platform royalty. The second is usage-based API billing, where developers pay per token or per call and price their own products on top; here the platform's cut is a margin embedded in wholesale rates rather than a visible percentage.

The third channel is an app-surface revenue split, functionally the app-store arrangement transplanted into a chat interface: a developer's agent sells to users inside the platform, and the house takes a percentage of each transaction. The fourth, furthest out, is agent-to-agent commerce, where one agent pays another for a subtask and platforms levy a toll on machine-to-machine settlement. Each shape distributes risk differently between platform and developer, which is why choosing among them is a strategic act, not a billing detail.

03 The take-rate ladder, illustrated

The chart below lines up four billing shapes against the take rates commonly reported for each. The consumer app-store norm, roughly thirty percent, is the ceiling a generation of mobile developers built around. The small-business in-app purchase rate, about fifteen percent, shows how platforms already tier their cuts under regulatory and competitive pressure. Usage-based API margins near twenty percent are less visible but economically similar, and direct enterprise contracts, negotiated and bundled, are thought to surrender closer to ten percent.

Read as a ladder, the chart describes a menu an agent platform can walk as it matures: open with the highest-rate shape the market will tolerate, then trade take rate for volume as developers and regulators push back. Where OpenAI's actual terms land on this ladder is undisclosed; the percentages are illustrative norms, not disclosures.

04 What the arithmetic does to developer incentives

Take rate is destiny for developer supply. A team deciding where to build compares the margin left after the platform's cut against shipping on the open web, and the mobile app-store record shows how that calculation plays out. The thirty-percent norm funded platform empires while breeding a decade of resentment and workarounds: web-billing loopholes, regulatory pressure in multiple jurisdictions, and lawsuits that forced tiered rates. Developers never accepted the norm because it was fair; they accepted it because distribution was worth it.

An agent platform holds the same bargaining chip. If ChatGPT's surface delivers customers a developer cannot otherwise reach, a substantial cut is payable, at least until alternatives mature. The design problem is that high take rates select for developers with no better option, while the richest agent opportunities, durable business software with real pricing power, are built by teams that can walk away. The platform that takes less per transaction may compound a stronger ecosystem, which is the quiet argument for landing low on the ladder above.

05 Seats, outcomes, and the enterprise buyer

The enterprise side runs on different rails. Software procurement is built around seats: a per-user fee, an annual contract, a renewal conversation. Agents strain that model because an agent is not a user; it is capacity, and capacity that can be pointed at work by the thousand. Usage-based pricing maps more honestly onto that reality, and outcome-based pricing, paying per resolved ticket or completed workflow, is the endpoint vendors gesture at when they describe agents doing the work of departments.

Outcome pricing is also a trust technology. Procurement teams sign contracts for what they can verify, and a vendor willing to be paid on verified outcomes is making a claim that seat-based vendors avoid. If verification of agent work matures, it could reprice chunks of knowledge work whose budgets were set by headcount, and shift bargaining power toward whoever can prove results. That possibility is why enterprise agent pricing is worth watching even though none of it is public yet.

06 Why the procurement mix matters

The second chart sketches how enterprise deployments might divide across those three pricing models, with per-seat licenses still dominant, usage-based arrangements growing fastest, and outcome-based deals a small but strategically loud minority. The mix is illustrative, a posture reading of the market rather than survey data. Its direction matters more than its levels: every point that moves from seats to outcomes transfers risk from buyer to vendor and raises the evidentiary bar for what an agent must demonstrate.

For the platform, the mix defines where its take rate comes from. Seats are a stable annuity with a predictable cut, usage billing scales with consumption and its embedded margin, and outcome deals carry the highest variance and the deepest integration. Serving all three requires billing infrastructure that can meter tokens, split transactions, and settle on verified results—a harder engineering lift than the keynote implied.

07 Limits, base rates, and what to watch

Every mechanism described here is inferred from platform precedent, not disclosed by OpenAI, and the base rate for keynote-driven speculation is humbling: platforms announce ambitions far more often than they ship billing systems. Scale is real—a funding round reported in March 2026 put the company's post-money valuation at $852 billion—but valuations price expectations, while this analysis prices mechanics that have not been published.

The question is nonetheless falsifiable. Watch for three disclosures: published revenue-share terms for third-party agents, billing APIs that expose app-surface transactions to developers, and enterprise agent agreements carrying service-level commitments on outcomes. Any one would convert this framework from inference into arithmetic. Until then, the missing slide stays missing, and every take-rate number attached to it is illustrative.