Vertical Agent Malls Roundup — B2B Procurement, Travel, Grocery, Healthcare, and the Verticals Worth Building Next.

Why verticals matter — and where smaller operators win.

Generic horizontal platforms compete on developer experience, global payments infrastructure, and uptime SLAs. A vertical agent mall competes on a completely different dimension: knowing that a grocery order requires real-time substitution rules tuned to brand loyalty; that a B2B purchase requires a multi-level corporate approval chain before a single dollar moves; that a pet-prescription purchase requires a VCPR gate that no agent can bypass. None of this domain knowledge ships with Stripe, Shopify, or AWS. It has to be built — and the operator who builds it first, builds it deepest, and structures it as machine-readable Layer 1 data owns the discovery surface in that vertical.

The incumbent advantages in every vertical are real: network effects (buyers and sellers both present because the other is already there), deep workflow integrations into buyers' existing ERP or POS systems, and entrenched switching costs measured in years of purchasing-team habit. But those advantages come with three structurally exploitable blind spots:

Survey: where each vertical stands on the 4-Layer readiness scale.

1. Restaurants + Local Delivery

The restaurant vertical is aggregator-dominated. DoorDash (15–30% delivery commission — Basic 15% / Plus 25% / Premier 30%, re-verify before launch), UberEats (Lite 20% / Plus 25% / Premium 30%, re-verify before launch), and Grubhub hold the dominant discovery and fulfillment surfaces in the US. For most AI agents querying "pad thai near me," the answer surfaces from aggregator catalogs — the restaurant's own website is secondary at best.

The agent-commerce structure divides into two paths. The aggregator-embedded path treats the platform as the agent commerce layer — commission applies to every order, and the restaurant's Layer 1 data is whatever the aggregator has on file. The restaurant-direct path wraps the POS API in an MCP server, eliminating the commission middleman but requiring the restaurant to own its structured data, API access, and delivery dispatch. Toast (dominant in full-service restaurants; Partner Connect costs approximately $25/month, sandbox access in beta as of this writing — re-verify before launch) is the most-used POS in full-service; Square is the most developer-accessible (standard OAuth 2.0 merchant flow); Clover provides REST API access via OAuth. Layer 1 has a specific problem here: Schema.org has no native modifier schema — every POS exposes modifier groups differently, and agents querying a menu cannot reason about modifiers without custom implementation. See the Restaurants deep-dive for the full endpoint-by-endpoint analysis.

2. B2B Procurement

B2B procurement is structurally incompatible with consumer shopping-agent assumptions at every layer. Price is quoted per buyer, not listed. Payment is net-30/60/90, not due at checkout. Purchases route through multi-level approval chains before committing funds. The buyer is the procurement agent operating under corporate spending policy — what the AgentMall framework designates the CFO-agent persona. Layer 4 (UCP) changes most drastically: a multi-step approval chain replaces the single-step consumer checkout, and the EDI document cycle (850 PO → 855 ACK → 810 Invoice → 820 Payment) is the execution rail for every committed transaction. EDI is not the decision layer — the agent decides; EDI transmits the paperwork.

The platforms that matter: SAP Ariba (largest network; supplier fees Bronze $50/yr through Platinum $5,500/yr + 0.155% transaction fee + $20,000 USD annual cap per NA buyer relationship; OAuth 2.0 via https://api.ariba.com/v2/oauth/token — re-verify all before launch), Coupa (X-COUPA-API-KEY header authentication), Oracle Procurement Cloud (REST API, approximately $650/user/month Sourcing — re-verify), JAGGAER, and Tradeshift ($0.30–$0.80/transaction tiered — re-verify). Layer 3 requires two MCP tool surfaces: a merchant-side set (get_quote, check_credit_terms, get_lead_time, submit_po, check_po_status, submit_invoice) and a buyer-side set (approve_purchase, set_spending_cap, request_quote_comparison, escalate_to_human). See the B2B Procurement deep-dive for the complete EDI 850 example and RFQ workflow.

3. Travel + Hospitality

Travel is the most agent-mature vertical in commerce history — human travel agents have operated as literal purchasing agents for more than 50 years, and the GDS infrastructure built for them effectively implements Layers 1 through 3 of the 4-Layer Model already. Amadeus (400+ airlines via REST Self-Service at developers.amadeus.com; Enterprise adds AA, Delta, BA, and NDC content), Sabre (420+ airlines; proprietary MCP server announced September 2025), and Travelport (470+ airlines; TripServices REST API migrating from legacy SOAP uAPI) together cover the bulk of airline inventory. NDC (IATA New Distribution Capability) is the airline-direct channel for dynamic per-session pricing and richer ancillary merchandising — American Airlines is the most aggressive US NDC proponent; Delta the most cautious. Duffel aggregates 30+ airlines via a single API and handles IATA/ARC accreditation on the seller's behalf, which solves a critical gating problem: Amadeus Self-Service users cannot issue tickets without a consolidator agreement. Self-Service creates the PNR; a BSP/ARC-accredited consolidator issues the ticket.

Layer 4 (UCP) has a wrinkle unique to travel: loyalty-credential delegation. An agent acting on a user's behalf must carry the user's Marriott Bonvoy, Hilton Honors, IHG One Rewards, and World of Hyatt membership numbers into every booking — or the stay does not earn points. OTA-routed bookings typically do not qualify for chain loyalty points; direct-channel API bookings do. This has no analog in most other verticals and must be designed into the UCP contract explicitly. See the Travel deep-dive for GDS booking fee tables (Lufthansa Group DCC: €18.00 Amadeus / €22.50 Sabre / €23.00 Travelport, effective Jan 2026 — re-verify), PNR mechanics, and the full OTA landscape.

4. Pet Products

Pet products combine high purchase frequency, strong brand loyalty, and deep subscription penetration — the structural conditions that make agent-mediated recurring commerce most valuable. Three buyer segments drive structurally different agent behaviors: Routine Resupply (fully autonomous; agent monitors stock and executes Autoship); New-Pet Concierge (guided assembly for breed-appropriate starter kit); and Grief/Recent Loss (ethics-flagged; agent suppresses upsell logic, caps options at three, acknowledges context). Chewy dominates routine and prescription resupply — but Chewy does not expose a public consumer or merchant API for third-party agents. The Rithum Commerce Suite (DSCO) integration is a B2B EDI/API path for vendor brands managing drop-ship inventory — it is not a consumer API path. Independent sellers building agent-commerce storefronts must run on Shopify (Selling Plans API), WooCommerce (Subscriptions plugin), BigCommerce, or Etsy (memorial path). See the Pet Products deep-dive for the full prescription VCPR gate flow, grief-purchase ethics layer, and schema pattern.

5. Grocery — Emerging

Grocery is the emerging vertical most structurally suited to agent commerce — recurring spend, predictable preferences, substitution logic — and the one most constrained by real-time inventory volatility. The three dominant platforms offer no fully open consumer-agent ordering API.

Walmart Grocery's developer API (developer.walmart.com) is primarily a Marketplace API for third-party sellers — it is not a consumer grocery ordering API. Amazon Fresh has no public consumer-facing API for third-party agents (Amazon's SP-API covers seller-side operations, not consumer ordering). The most structurally challenging problem in grocery is not platform access — it is substitution logic. If a shopper's first-choice item is out of stock, the agent needs per-item and per-category substitution preferences encoded in Layer 1 buyer profile data, and a Layer 4 UCP contract that specifies whether the agent can autonomously substitute, must surface the option to the buyer, or must cancel and report. Without that preference structure, every out-of-stock event requires human confirmation — defeating the value of agent mediation entirely. The pattern is directly analogous to the 86'd-item problem in restaurant agent commerce.

6. Healthcare — Emerging

Healthcare has the highest potential value for agent commerce and the highest regulatory barrier of any vertical in this survey. Every data exchange, prescriber interaction, appointment booking, and prescription delivery that touches Protected Health Information (PHI) is subject to HIPAA's Security Rule.

HL7 FHIR (Fast Healthcare Interoperability Resources) is the modern standard for clinical data exchange — RESTful APIs, JSON/XML, resource-oriented architecture with standardized containers (Patient, Condition, Observation, Medication, Appointment). The 21st Century Cures Act accelerates FHIR adoption by requiring EHR vendors to expose FHIR APIs for patient data access. Legacy HL7 v2.x (delimiter-based, real-time hospital messaging) remains dominant in existing hospital systems; FHIR is the forward path for new integrations and AI agent data access. For telehealth booking: Doxy.me (HIPAA + GDPR + SOC 2 certified; free BAA included; embeddable SDK and session webhooks available) is not a self-service booking API — it handles the video session layer. Amwell and Teladoc each offer BAA agreements and enterprise integration paths, but as of this writing, neither exposes a publicly documented, self-service API for third-party agent appointment booking. Full provider scheduling via API typically runs through EHR FHIR APIs (Epic, Cerner) using Appointment resources or through practice management systems with open booking APIs. DEA controlled-substance rules and state Board of Pharmacy regulations add an additional layer on top of HIPAA for any prescription-adjacent workflow.

Four verticals with structural agent-commerce fit and open building windows.

Beauty and Cosmetics

The agent-commerce opportunity in beauty is color-matching, ingredient-allergen filtering, and subscription replenishment — three problems structurally suited to agent mediation because they require filtering large catalogs against personal biological constraints (shade, undertone, allergens, skin type). AR virtual try-on tools (Perfect Corp, Revieve) and skin diagnostic platforms address the discovery layer but stop short of the end-to-end commerce loop: shade match → routine assembly → recurring replenishment with intelligent substitution when a product is discontinued. Ulta Beauty and Sephora each have personalization apps; neither exposes a public developer API for agent ordering. Independent beauty brands on Shopify are immediately agent-accessible via standard Shopify APIs — the structural advantage a well-curated indie catalog of 200 SKUs with complete allergen and shade metadata holds over a large retailer's thousands of sparse SKUs is the same data-quality asymmetry that applies in pet products and grocery.

Home Services

Booking professional services — plumbing, electrical, HVAC, cleaning, landscaping — is an agent task by nature: availability matching, geographic proximity, credential verification, and price comparison, all parallelizable. Thumbtack is already embedded directly into ChatGPT for home services booking (October 2025) via a ChatGPT Operator integration, and operates a Partner Platform at developers.thumbtack.com. Angi has no publicly documented API for third-party agent booking as of this writing (re-verify before launch). GoodHire and Checkr provide background-check APIs for contractor verification. The agent-commerce wedge is a vertical agent mall specialized in a single service category — HVAC in a specific metro, for instance — with pre-vetted professionals, structured availability data, and same-day booking confirmation. That specificity beats the generic marketplace on trust and speed, which are the two variables home-service buyers optimize on.

Automotive Parts and Service

The automotive parts vertical has a natural agent-fit problem: fitment disambiguation. Every parts query requires year/make/model/submodel/engine resolution before a part number means anything. Advance Auto Parts and AutoZone support VIN-based lookups via their consumer apps but do not publish self-serve developer APIs for third-party agent ordering as of this writing (re-verify before launch). RockAuto operates a catalog-query model accessible to integration partners. The near-term opportunity is a buyer-side agent that takes a VIN, identifies the needed part, queries multiple supplier APIs for pricing and in-store availability, and dispatches a BOPIS order or a service appointment. Service appointment booking (dealerships, independent shops using NAPA AutoCare, Tekmetric, or Mitchell1 shop management software) has no standardized API — most do not expose public booking endpoints. The parts layer is buildable now; the service scheduling layer requires either platform partnerships or standardized booking APIs that do not yet widely exist.

Education

Education's agent-commerce opportunity spans course enrollment, material purchase, and tutor or tutoring-service matching. Coursera and edX expose course catalog APIs for discovery; actual enrollment requires user authentication on the platform. Textbook purchase is largely commoditized with standard e-commerce API access. The under-built opportunity is agent-mediated tutor matching: matching a student's subject, level, schedule, and learning style against a tutor catalog, negotiating price, and scheduling sessions. Tutor marketplace platforms (Wyzant, Tutor.com, Varsity Tutors) do not expose public agent-friendly booking APIs as of this writing (re-verify before launch). For accredited course enrollment, FERPA applies to student records — the same structural regulatory-prerequisite logic as HIPAA in healthcare. The compliance architecture must be designed in from day one.

Picking your vertical — the table and the three non-table rules.

Market size is the worst input for vertical selection in agent commerce. A large market with a closed incumbent API is not an opportunity — it is a market to observe until the API opens. A smaller market with a well-documented, accessible API is buildable today. Start with API access, not TAM.

The Three Non-Table Decision Rules

Build for agent commerce first if: the buyer's purchasing behavior is recurring and predictable (grocery, pet food, B2B reorders); the product selection requires multi-attribute filtering against buyer constraints (beauty, pet products, B2B specs); or the workflow involves multi-step coordination that humans currently execute by phone or email (travel itineraries, home service booking, B2B procurement approvals). Verticals where the answer is yes to at least one of these conditions are structurally suited to agent mediation. Verticals where the answer is no — impulse purchases, low-frequency one-time buys without research complexity — have weaker agent-mediation value propositions, regardless of market size.

Avoid without regulatory preparation if: HIPAA (healthcare), VCPR/DEA (prescription products), FERPA (student data), or PCI DSS (payment card data in certain flows) applies to your core transaction. These are structural prerequisites, not compliance checkboxes to defer. If HIPAA applies, the BAA requirement flows to every vendor touching ePHI — including your MCP server host, database, logging service, and monitoring tool. Design the vendor stack for compliance before writing the first API call.

Look at API access first, not market size. A large market with a closed incumbent API is not an opportunity for an independent developer — it is a market to observe until the API opens or until a niche subset of that market is accessible via an open-platform layer. A smaller market with a well-documented, accessible API is buildable today. The exercise is: find one API endpoint in your target vertical that allows a complete production transaction. If you cannot identify that endpoint with a real URL and auth method, you are not yet ready to scope engineering work. Frame every closed incumbent as a pointer toward where the opportunity will emerge, not a wall in front of it.

The 4-Layer Model across all six verticals — terse, link-out for depth.

Each cell below gives the terse vertical-specific implementation. Full implementation detail lives in the deep-dive for each vertical. The layers are consistent; the implementations are not.

Where to go from here — all 4 deep-dives and the full AgentMall spoke library.

The Four Vertical Deep-Dives

Foundation Spokes — Protocol and Model

Market and Stack Spokes

Platform Retrofit Spokes

Discovery Spokes

Eight ways vertical agent-commerce projects fail before launch.

1. Picking a vertical based on market size, not API availability

A large market with a closed incumbent API is a research project, not a buildable opportunity. If the only path to production is a formal partnership negotiation with a dominant incumbent, your go-live timeline is that incumbent's partnership review queue. The grocery vertical has a US market measured in hundreds of billions of dollars — and no public consumer-agent ordering API from any of the three dominant platforms. Market size tells you what could be valuable; API availability tells you what you can build. Evaluate in that order. Find one accessible API path to a complete production transaction before scoping any engineering work.

2. Treating incumbent lock-in as a wall rather than a direction sign

DoorDash's 15–30% commission is not a barrier for a restaurant agent-commerce operator — it is the reason restaurant-direct agent commerce has a margin story. Every incumbent with a closed API and high fees is implicitly defining the value proposition for the alternative. The operator who builds the direct-channel agent path earns the commission the aggregator was capturing. Frame every closed incumbent as a pointer toward where the opportunity is, not a wall in front of it.

3. Building Layer 3 (MCP) before completing Layer 1 (Structured Data)

An MCP tool that calls an API whose underlying product data is incomplete — missing species tags, no price-break tiers, no modifier groups — returns garbage structured outputs. Agents reason over Layer 1 data; a polished MCP surface cannot compensate for sparse structured data beneath it. Audit and complete structured data for every SKU or service entity before deploying any MCP tools. Use the vertical-specific Layer 1 schema requirements from the deep-dives or from the scorecard table above as a checklist.

4. Ignoring the regulatory burden of "emerging" verticals

Healthcare requires HIPAA. Pet prescriptions require VCPR. Student data requires FERPA. B2B healthcare procurement overlaps all three. These are not details to revisit after MVP — they determine architecture, vendor selection, and go-live timing from day one. If HIPAA applies, the BAA requirement flows to your MCP server host, database provider, logging service, and monitoring tool. If you have not executed BAAs with every vendor touching ePHI before the first patient interaction, you are already in violation.

5. Conflating the Instacart Developer Platform with a grocery ordering API

The Instacart Developer Platform enables shopping list creation, recipe page creation, product discovery, and cart building — checkout routes through Instacart's own flow. A third-party agent cannot place a grocery delivery order directly on a consumer's behalf via the IDP API. Instacart Connect APIs are for retailer partners with signed agreements, not independent developers. Verify the current IDP capability set at docs.instacart.com/developer_platform_api before scoping. Build the shopping-list and cart-creation flow now; design the architecture to plug in direct order placement when that capability becomes available.

6. Skipping the substitution-rule layer in grocery

Real-time inventory volatility means a grocery agent will regularly encounter out-of-stock items. An agent that silently substitutes without explicit buyer preference rules delivers the wrong product. An agent that silently fails abandons the cart. Neither outcome is acceptable for a recurring grocery workflow. Build substitution preference capture into the buyer profile at Layer 1 before deploying any grocery agent: per-item brand-loyal vs. flexible, per-attribute organic-required vs. optional, per-category no-substitution vs. any-brand-OK.

7. Building travel agent infrastructure without a consolidator path

Amadeus Self-Service lets any developer create PNRs without IATA/ARC accreditation — but those PNRs cannot be ticketed without a consolidator agreement. An agent that creates PNRs and presents them to users as confirmed bookings without a verified ticketing path has built a liability. Identify a consolidator partnership or an NDC aggregator like Duffel (which handles IATA/ARC accreditation on your behalf for 30+ airlines) before building the issue_ticket tool. Test the full PNR-to-ticket lifecycle in sandbox before any production booking.

8. Applying a one-size consumer-checkout UCP contract across verticals

A pet-products UCP contract for the grief segment (one-time only, no upsell) is structurally different from a B2B procurement UCP contract (multi-step approval chain, net-30 terms) and from a travel UCP contract (payment at booking, loyalty-credential delegation). Applying a generic consumer checkout UCP template to any non-retail-consumer vertical creates transaction failures that are hard to diagnose because they appear to succeed at the API layer. Design UCP contracts from the buyer-persona description outward. Cross-reference the UCP spoke for persona-specific contract patterns.

Frequently asked questions.

How to pick and validate your vertical — in five steps.

Each step mirrors the HowTo JSON-LD at the top of this page word for word. This is the process for vertical selection and validation, not per-vertical implementation — follow the deep-dive links for implementation specifics once your vertical is chosen and validated.

Step 1 — Map the buyer-behavior pattern in your target vertical

Before evaluating API access or competitive landscape, describe the target buyer's behavior in one sentence. Does the purchase recur on a predictable cadence (grocery, pet food, B2B reorders)? Does it require multi-attribute constraint matching (beauty shades, pet allergens, B2B compliance certifications)? Does it involve multi-step coordination that currently happens by phone or email (home services, travel itineraries, B2B approvals)? Verticals where the answer is yes to at least one of these questions are structurally suited to agent mediation. Verticals where the answer is no (impulse purchases, low-frequency one-time buys without research complexity) have weaker agent-mediation value propositions.

Step 2 — Identify one accessible API path to a production transaction

Find one API endpoint in your target vertical that allows a complete transaction (or as close as possible) in production. "Self-serve developer access" means an API key is available without a formal partnership approval. "Gated access" means you need a signed agreement or certification before production use. "No public API" means you build on top of an existing open-platform layer (Shopify for pet products, Etsy for memorials) or wait for the incumbent to open access. Document the specific endpoint, authentication method, and any gating steps required. If you cannot complete this exercise with a real URL and auth method, you are not yet ready to scope engineering work.

Step 3 — Identify the regulatory framework and build compliance into the architecture from day one

For healthcare: HIPAA, BAA with every vendor. For prescription products: VCPR/DEA. For student data: FERPA. For consumer health data in Washington state: MHMDA. For EU consumers: GDPR. These are not post-launch additions. If you are building in a regulated vertical, your database vendor, logging service, and MCP server host all need BAA or equivalent agreements before your first transaction. Design your data model to collect the minimum necessary fields and implement a retention policy before launch.

Step 4 — Build and complete your Layer 1 schema before writing any MCP tool code

For every product or service entity in your catalog, audit the vertical-specific schema requirements from the relevant deep-dive (or from the Layer 1 column in the Capability Scorecard table in this document). Add every missing field. For a grocery product, that means real-time inventory availability, nutrition data, brand attributes, and substitution eligibility. For a B2B product, that means contract-specific pricing, MOQ, lead time, and payment terms. An incomplete Layer 1 schema will not cause a build failure — it will cause subtle agent errors at the product selection stage that are hard to debug.

Step 5 — Test the full end-to-end agent transaction in a sandbox environment before launch

Every vertical in this survey has at least one sandbox or test environment: DoorDash Drive sandbox; Amadeus Self-Service test environment; Square Catalog sandbox; Ariba Network developer sandbox; Instacart IDP development API keys. Use them. Run the complete agent flow — product/service discovery, availability check, transaction initiation, confirmation, status tracking — in sandbox before any production traffic. Instrument every step with logging at the API response level, not just the UI level. A silent failure at Layer 2 (e.g., an order accepted by the API but not routed to the fulfillment system) will not surface in a UI test but will cause real-world errors. Verify the full transaction cycle end-to-end, including the cancellation and error paths.

Next stops — the four deep-dives and the full roadmap.