Building API Products in the AI Era

Janet Wagner · article · 2026-05-09 source ↗ Reader 🖥️

Agent-Native Design Agentic Commerce API Products & Sprawl MCP (Model Context Protocol)

APIs must now serve both human developers and AI agent consumers, which requires rethinking API product design across multiple dimensions — granularity, protocol diversity, monetization models, and developer experience — to remain competitive in an AI-driven market.

practical · conference recap / panel synthesis — Synthesizes advice from four industry panelists at Platform Summit 2025 into prescriptive guidance for API product managers and architects. Primarily practitioner-oriented — surveys current thinking rather than advancing original theory.

Structure

Part	Role
API Product vs. API as a Product	Establishes the definitional distinction between APIs that support a business product and APIs that are the product
Consider Different API Consumers	Introduces the dual-consumer thesis — human developers vs. AI agents have different integration patterns (direct coding vs. MCP orchestration)
Break Up the Monolithic API	Argues for smaller, targeted APIs that reduce cognitive load for both human and AI consumers
Support Multiple API Styles and Protocols	Advocates multi-protocol offerings (REST, gRPC, webhooks, MCP, A2A) to serve diverse consumer types
Treat Internal APIs as Products	Extends the productization argument to internal APIs via developer portals and documentation
Monetize the API Experience / Evolve Monetization for AI	Argues for value-based pricing over per-call models and introduces agent payment protocols (AP2, ACP)
Never Forget About Developer Experience	Emphasizes solution-oriented documentation and community as enduring foundations
Same Foundation, New Rules	Closing frame — APIs are still foundational but the design rules are changing

Key terms

API product API Products & Sprawl
An API built around business capabilities to solve a specific problem, where the business team drives the product decisions and IT provides the technical solution
API-as-a-product API Products & Sprawl
An API that is itself the standalone product being sold, serving as the core value of the business (e.g., Twilio, Stripe)
multi-protocol API Products & Sprawl
Offering the same API product through multiple architectural styles and protocols (REST, gRPC, webhooks, MCP, A2A) so consumers can choose their preferred interaction pattern
MCP server MCP (Model Context Protocol)
A Model Context Protocol server used to orchestrate multiple APIs for AI agent consumers, providing structured context and workflow coordination
agent-based payments Agentic Commerce
Payment protocols that enable AI agents to autonomously execute financial transactions when consuming APIs, exemplified by Google's AP2 and Stripe/OpenAI's ACP
outcome-based pricing Agentic Commerce
API monetization that charges based on the value or outcome delivered rather than the volume of API calls

Propositions

explicitdevelopedAPIs must now serve both human developers and AI agents as primary consumers, requiring a fundamental rethink of API product design.conf: high
extends ←Why Developer Portals Must Evolve in the AI Agent Age · p3 — Both assert APIs/portals must now serve human and agent consumers simultaneously; this document extends that claim by arguing specifically that MCP alone cannot substitute for the portal's governance/analytics/lifecycle layer.
explicitSmaller, targeted APIs are superior to monolithic APIs because they reduce cognitive load, are faster to integrate, and achieve better product-market fit.conf: high
explicitAI agents will typically consume APIs through MCP servers that orchestrate multiple APIs, while human developers should code integrations directly for high-volume production use cases.conf: medium
explicitdevelopedOne product should be accessible via multiple protocols, and the consumer should choose the interaction pattern.conf: high
extends ←Presentation: APIs for Agents: Rethinking API Programs in the MCP Era · p9 — That proposition argues one product should be accessible via multiple protocols with the consumer choosing; this talk both demonstrates it working (Trades API via REST/MCP/A2A) and adds the nuance that MCP and A2A are different interaction paradigms, not interchangeable transports.
explicitcorroboratedInternal APIs should be treated as products with their own developer portals, documentation, and onboarding experience.conf: high
supports ←Why Developer Portals Must Evolve in the AI Agent Age · p1 — The earlier document's claim that internal APIs need their own developer portals is directly reinforced by this document's argument for why the portal layer persists even with MCP available.
explicitAPI monetization should be based on the value and experience delivered, not on access to the API endpoint itself.conf: high
explicitcorroboratedTraditional per-call API pricing becomes impractical for AI agent consumers due to the volume and unpredictability of their usage patterns.conf: high
supports ←When Your Buyer Is an AI Agent · p3 — The B2B per-seat pricing breakdown described here is the SaaS-contract analog of that document's claim that per-call API pricing becomes impractical for agent consumers — both describe the same unit-of-billing mismatch between discrete-session pricing and continuous, machine-speed agent usage.
explicitOperationalization — scaling, pricing platforms, SLA monitoring — must be solved before monetization can work.conf: high
explicitSolution-oriented documentation outperforms feature-listing documentation for developer adoption.conf: high
explicitThe industry will converge on agent-based payment protocols, though competing standards (AP2, ACP) currently coexist.conf: low
extendsAAIF's MCP Dev Summit: Gateways, gRPC, and Observability Signal Protocol Hardening · p8 — Broadens the x402 agent-micropayment signal into a claim that the industry will converge on agent payment protocols, with AP2/ACP currently competing.
implicitAPI product companies that do not adapt to AI consumers risk losing market share to those that do.conf: medium

Arguments

API providers must design for AI agent consumers alongside human developers. strength: medium

Explicit premises:

44% of enterprises assessed or deployed AI agents in 2025 (NVIDIA report).
AI agents consume APIs differently — they need structured workflows, contextual understanding, and orchestration across multiple APIs.
MCP servers are emerging as the orchestration layer for AI-to-API interaction.

Implicit premises:

The 44% figure will continue to grow, making AI agents a dominant consumer class.
Providers who ignore this shift will lose competitive ground.

Inferences:

Therefore API product design must account for AI agent consumption patterns from the start.

Monolithic APIs should be broken into smaller, targeted APIs. strength: medium

Explicit premises:

Large APIs increase cognitive load and are harder to understand.
Developers search for simpler services that get them to 'Hello World' faster.
Smaller APIs can be tailored to specific business use cases with clear documentation.

Implicit premises:

Time-to-first-call is a primary driver of API adoption.
The cost of maintaining multiple smaller APIs is justified by higher adoption and retention.

Inferences:

Therefore smaller, purpose-built APIs produce better developer acquisition, retention, and product-market fit.

API monetization must evolve beyond per-call pricing for the AI era. strength: medium

Explicit premises:

Per-call pricing becomes impractical with millions of AI agent requests.
Subscription models don't cover unpredictable AI usage patterns.
Customers expect pricing aligned with outcomes, not volume.

Implicit premises:

AI agent traffic volumes will be orders of magnitude larger than human-driven API traffic.
Providers who don't adapt pricing will either lose money or lose customers.

Inferences:

Therefore outcome-based, dynamic, or agent-payment-protocol-based pricing models are needed.

Narratives

Twilio and Stripe as exemplars of API-as-a-product companies that built great developer experiences and turned developers into brand advocates
→ Establishes the gold standard that the article's recommendations build upon
Appelros's museum analogy — you don't monetize the door into the museum, you monetize the experience inside
→ Reframes API monetization from access-based to value-based thinking
Google's internal/external protocol strategy — gRPC internally, REST externally, with MCP/A2A as additional consumer-chosen protocols
→ Provides a concrete multi-protocol implementation pattern from a major platform company
Employees hunting through Slack messages and support tickets to figure out internal API integrations, with information getting lost
→ Negative example that motivates treating internal APIs as products

Questions addressed

✅ How should API products be designed differently now that AI agents are major consumers?
Design for multiple consumer types, offer multi-protocol access, use MCP servers for AI orchestration, break monolithic APIs into targeted services, and evolve monetization to outcome-based models.
✅ What is the difference between an API product and an API-as-a-product?
An API product is built around business capabilities with business-team ownership; an API-as-a-product is a standalone product where the API is the core value (e.g., Twilio, Stripe).
⭕ How should API pricing change for AI consumers?
The article identifies the problem (per-call and subscription models are inadequate) and points to emerging solutions (outcome-based pricing, AP2, ACP) but acknowledges no consensus exists yet.
✅ Should internal APIs be treated as products?
Yes — with developer portals, documentation, and proper onboarding to boost productivity and reduce information loss.
✅ What makes for good API developer experience?
Solution-oriented documentation, easy onboarding, community building, active social channels, and portals that are both functional and engaging.

Gaps

incompleteThe article asserts AI agents need different API design but provides no concrete examples of an API that has successfully been redesigned for dual human/AI consumption. All recommendations are forward-looking prescriptions without case studies.
Read next: Look for case studies of companies that have added MCP server interfaces to existing API products and measured the impact on AI agent adoption.
closed byPresentation: APIs for Agents: Rethinking API Programs in the MCP Era — That article asserts AI agents need redesigned APIs but gives no concrete example of one successfully redesigned for dual human/AI consumption. Morgan Stanley's Trades API — exposed simultaneously via REST, an MCP server, and an A2A adapter, all generated from the same CALM architecture and patterns, with working governance controls — is exactly this case study.
incompleteThe multi-protocol recommendation (REST + gRPC + MCP + A2A + webhooks) is presented without addressing the engineering cost, maintenance burden, or consistency challenges of maintaining multiple protocol surfaces for the same product.
Read next: Look for experience reports on multi-protocol API management — how companies like Google handle protocol parity and version drift across surfaces.
closed byPresentation: APIs for Agents: Rethinking API Programs in the MCP Era — That gap flags the multi-protocol recommendation (REST/gRPC/MCP/A2A/webhooks) as never addressing engineering cost or maintenance burden. This talk answers it concretely: CALM's composite patterns let the MCP/A2A architecture reference — not duplicate — the underlying REST service pattern, and CALM template/CALM Hub propagate changes to every protocol adapter from one place.
incompleteThe monetization discussion identifies the problem (per-call pricing is inadequate for AI) but the proposed alternatives — outcome-based pricing, dynamic pricing, agent payment protocols — are all nascent. No practical implementation guidance is offered.
Read next: Track AP2 and ACP protocol development; look for early adopter reports on outcome-based API pricing implementations.
unacknowledgedThe article does not address security and trust implications of AI agents as API consumers — authentication, authorization, rate limiting, abuse detection, and liability when an agent makes erroneous or harmful API calls.
Read next: Look for work on AI agent authentication patterns, agent identity standards, and liability frameworks for autonomous API consumption.
closed byAI Model Context Protocol Adds Centralised Auth for Enterprise — Supplies the agent-consumer authentication/authorization model that piece left unaddressed, enterprise-managed, identity-provider-centered connection-level authorization, while explicitly noting it does not cover per-action runtime authorization, rate limiting, or abuse detection.
unacknowledgedThe panel's advice is entirely provider-centric. The consumer perspective — what developers and AI agent builders actually want from API products — is not represented with data or research.
Read next: Look for developer surveys or agent-builder interviews about API product preferences and pain points.

Building API Products in the AI Era

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents