FRM Regulatory Pulse- May 2026

A new category of software company has emerged—one that builds its products not from raw code alone, but on top of foundation models created by others. These AI application layer companies span search and knowledge engines, enterprise AI middleware platforms, coding assistants, design tools, and autonomous agent frameworks. They represent some of the fastest-growing software businesses in history: multiple companies in this category have reached $100 million in annual recurring revenue within 12–18 months of launch, growth trajectories that took traditional SaaS companies five to seven years to achieve.

These companies provide proprietary search, summarization, or question-answering engines powered by one or more foundation models. The user submits a query; the platform retrieves relevant information from the web or proprietary sources, invokes one or more foundation models for synthesis, and delivers a curated answer—often with citations, follow-up suggestions, and a conversational interface. Revenue is typically subscription-based (consumer or enterprise tiers), sometimes with usage caps or overage charges. The platform’s value proposition is the quality of the retrieval, synthesis, and presentation layer—not the raw model capability. The foundation model is an ingredient, not the product.

Examples: Perplexity (AI-native search) and similar AI-powered answer engines

These companies sit between an enterprise’s proprietary data ecosystem and one or more foundation models, providing connectors, retrieval-augmented generation (RAG) pipelines, permissions and access control layers, semantic search, and conversational interfaces over internal knowledge. They are the “glue” that makes foundation models useful within the enterprise. An emerging pattern is “BYOD-AI” (Bring Your Own Data — AI), where the customer provides proprietary data and the vendor provides the orchestration, model access, and interface layers. The customer’s data is the primary input; the vendor’s platform transforms it into AI-powered outputs.

Examples: Glean (enterprise AI search and knowledge), Moveworks (enterprise AI platform)

These companies build coding assistants, design automation tools, writing aids, or workflow automation platforms on top of foundation models. The user interacts with the application, which makes API (software interface) calls to one or more models behind the scenes. A rapidly emerging sub-category is agentic AI platforms — systems that can autonomously plan multi-step workflows, invoke external tools, and execute actions to achieve a defined goal without continuous human direction. These platforms introduce additional accounting complexity because the cost per customer outcome is unpredictable — each autonomous task may require a variable number of foundation model calls, tool invocations, and reasoning steps, creating cost variability that traditional per-token pricing models do not capture.

Revenue models vary widely—from pure subscription to consumption-based (priced per token, generation, or action) to hybrid subscription-plus-usage. Annual Recurring Revenue (ARR) is the standard growth metric in this category. This archetype has seen the most explosive growth, with several coding and design tools reaching $100–200 million in ARR within 12–18 months. It also presents the most complex accounting questions, particularly around gross-vs-net determination and the classification of foundation model API costs.

Examples: Cursor (AI Coding assistant), Jasper (AI content platform)

Archetype A: Principal vs. Agent

The company delivers a fully integrated output — a synthesized search result, summary, or answer — built from foundation model inference combined with proprietary retrieval, ranking, and citation logic. The transformative relationship between the proprietary layer and the foundation model typically results in a single performance obligation. The primary judgment is whether the company controls the integrated output before transfer — a principal-vs-agent determination. While the principal conclusion is generally supportable given the depth of proprietary transformation, the relatively high API cost as a percentage of revenue (30–50%) means the economics warrant careful analysis and documentation.

Archetype B: Integrated Service Delivery

The platform integrates connectors, RAG pipelines, model access, permissions, and security layers into a unified enterprise service. These components are highly interdependent — the connectors have no value without the AI layer, and the AI layer has no data to operate on without the connectors — resulting in a transformative relationship and typically a single performance obligation. The principal-vs-agent determination applies but generally resolves more clearly, given the deep orchestration layer typically supporting a principal stance.

Archetype C: Multiple Complexities

The hybrid subscription + consumption pricing model creates layered challenges: (1) the distinctiveness question — whether the proprietary transformation layer and foundation model access form a single or multiple performance obligations, which varies more widely across products in this category; (2) gross-vs-net presentation, because the degree of proprietary transformation over raw model output varies by product and may yield different conclusions for different obligations; and (3) variable consideration estimation, because the consumption-based component introduces pricing variability that must be estimated and constrained.

Across all three archetypes, the nature of the promise is typically a stand-ready obligation — the AI platform is continuously available to process customer requests on demand rather than delivering a specified quantity of outputs. However, usage caps (Archetype A), seat or data volume limits (Archetype B), and per-token or per-action pricing (Archetype C) may introduce specified-quantity characteristics that affect the measure of progress and the applicability of series guidance. This determination is critical for revenue recognition timing and the assessment of whether contracts represent series of distinct performance obligations or unified stand-ready arrangements.

Under ASC 606-10-32-24, the entity assesses whether it obtains control of the customer’s contributed data — in most BYOD-AI arrangements it does not, as the data remains the customer’s asset subject to contractual return or deletion obligations. Whether the promise is to process the customer’s data or to provide continuous platform access affects recognition timing. This determination shapes the performance obligation structure and may result in different revenue recognition patterns depending on the specific contractual language and data handling responsibilities.