The AI-Native Services Playbook

The Emergence Team

4:00 pm

PDT

March 30, 2026

4 MIN READ

Image:

Spring 2026 Edition

At Emergence, we believe AI-Native Services will be a defining business model of the AI era (read why here). But there's no playbook for it yet. The idea of selling a service powered primarily by AI wasn't possible until 2023. Founders building in this space are figuring out foundational elements of this new business model as they go.

We aim to be the most diligent students of this emerging business model. We're working with the early pioneers of the category, both within and outside our portfolio, to document the lessons on how to build. Many of these lessons look quite different than how to build a successful software company. Some are counterintuitive. All of them are still evolving.

This playbook is for founders and operators building (or considering) AI-native services companies. We'll update it every six months to capture the latest in how to build in AINS. If you're building here and have lessons to share, we want to hear from you.

I. Team

Domain expertise is a must have. In traditional SaaS, you're selling a product. In AI-native services, you're selling yourself. Domain credibility isn't just important; it's existential.

Early customers need to believe in your ability to deliver results, and established credibility goes a long way towards building that trust. They evaluate services by the reputation or perceived credibility and expertise of the person/people providing it. Past performance is a reliable predictor of future performance. 

Industry experience is especially helpful in customer-facing team members; so much of this is about trust. You want the buyer to recognize the places your team has worked, ideally trusted brands from legacy service providers.

This domain expertise doesn't have to come from the co-founders; it can emerge as you build the team in the early days.

  • Mechanical Orchard: CEO Rob Mee (who previously ran Pivotal) brought instant credibility with enterprise buyers plus access to the Pivotal Labs talent network.
  • Harper and Pace: Both Dakotah Rice (Harper) and Jamie Cuffe (Pace) grew up in insurance families, giving them authentic domain credibility from day one. Harper's co-founder Tushar Nair brought the engineering depth; together they've served over 5,000 businesses in 13 months.
  • Hanover Park: Hired senior people from Standish and other established players in fund administration, which helped legitimize their offering while they built their AI-native approach from the ground up.
  • Crosby Legal: CEO Ryan Daniels was a top rising lawyer at a leading firm focused on the same practice areas Crosby is.

Domain authority also unlocks access to high-quality talent channels, which enables the rapid staffing you may need while your AI is still maturing.

Hire a product leader earlier than you think. Many AINS founders delay hiring a product leader since the customer rarely interacts with the software directly. This is a mistake. The complexity of AINS businesses requires a strong bridge between engineering and deployment. Without it, the product roadmap gets driven by whoever is shouting loudest rather than by a deliberate strategy for productization.

Your sales process must include someone who has a deep understanding of the service to be delivered. An AINS failure mode we've seen is where a seller who isn't intimately familiar with delivery overpromises on timelines, putting the delivery team in a bind. Involving a sales engineer or other technical resource ensures the complexity of the deployment is fully understood, and the engagement is scoped to succeed.

II. Product-Market Fit

Mirage PMF: The illusion of product-market fit created by revenue growth that's powered by human labor rather than AI leverage.

Beware Mirage PMF. PMF is a different beast in AI-native services. Strong revenue growth and net dollar retention can mask a lack of true AI enablement.

Unlike SaaS, revenue growth and strong logo retention don't prove product-market fit. You only truly have it when AI is doing a material share of the work at a high gross margin and delivering superior customer outcomes. Otherwise, you've built a good services firm financed with the wrong kind of capital.

Real PMF requires proving you can scale non-linearly relative to your costs. To get there, your AI must drive measurable improvements in cost, quality, or speed, or ideally, all three.

How do you know if you have Mirage PMF? Watch for these early warning signs:

  • Gross margin is flat or declining even as revenue grows. If AI were doing more of the work, margins should be expanding. Be honest about what's in COGS: inference costs, model API spend, and human-in-the-loop labor all belong there. Too many founders offload labor costs to operating expenses, but since this is a service, they are absolutely COGS.
  • Revenue per employee (ARR/FTE) isn't improving. This is the simplest test of whether AI is pulling its weight. More granularly, you could isolate service-relevant FTEs to understand AI leverage over time.
  • Delivery is still human-heavy. If your team is growing linearly with your customer base, you're scaling like a traditional services firm.
  • Bespoke work is expanding. If each new customer requires significant custom engineering, you're not productizing.
  • You can't point to a north star product metric that's improving. Every AINS company needs a single number that captures how much of the work AI is actually doing. We talk more about specific effective metrics we’ve seen in the Metrics section of this playbook.

Be sharp about your ICP. AINS founders need to be extremely precise about their ideal customer profile. It can be harder for services businesses than software businesses to unwind from the wrong client engagements. A mismatched enterprise customer can consume enormous delivery resources, distract from productization, and create custom requirements that don't transfer to your broader customer base.

In some cases, it's actually easier for AINS businesses to productize by starting downmarket:

  • More homogeneity and fewer "out of the box" requests from smaller customers compared to the enterprise
  • Lower ACVs force you to productize because you can't afford to throw human labor at each engagement
  • Simpler, more standardized workflows mean fewer edge cases for your AI to handle, which means you can demonstrate real AI leverage faster

Harper's focus on Main Street businesses (daycares, manufacturers, restaurants) rather than Fortune 500 accounts is a deliberate choice that illustrates all three of these dynamics.

But focusing downmarket doesn’t always correlate with easier productization in AINS. In some cases, larger enterprises may have more developed practices and repeatable requests. The most important thing is to be sharp about which ICP you’re focused on and why.

Focus on one or two jobs to be done. The more jobs you take on, the harder it becomes to productize your AI. Every new workflow requires new training data, new edge cases, new human oversight. Premature breadth is one of the fastest paths to Mirage PMF. You can always expand later. Strala exemplifies this discipline: they're focused specifically on claims processing for insurance carriers, captives, and MGAs. That narrow focus lets them build deep automation for a repeatable workflow. 

III. Delivery

In SaaS, a customer buys your product and implements it. In AINS, you ARE the implementation. Delivery isn't a support function; it's the core of what you sell. That makes the practices around how you deliver, learn from delivery, and scale delivery the single most operationally important part of the business. Implementation/onboarding must be a core competency. Get this wrong and you'll scale headcount, not AI.

Staff pilots with a dedicated team. Have a specialized group that runs pilots so they become experts at managing extreme uncertainty, rather than having the pilot team roll on to the full project. The pilot team should be your SEAL team. The project team, which takes over after pilot success, should be better at integrating AI into steady-state delivery. Some continuity between the two is helpful, but the skill sets are different.

Sleep at your customer’s office. That may sound crazy, but the Hanover Park CEO makes this commitment (and follows through!) to ensure successful migration/implementation. The hardest part of AINS isn’t the AI; it’s the handoff from the legacy process. Over-invest in migration at a level that may seem absurd. It’ll pay off. 

Sit doers next to builders. In AINS, the goal is to productize as much of the delivery process as possible over time. To do that, ensure you rotate people between product and delivery so learnings flow into the product. At Crosby Law, lawyers sit next to coders in pairs, creating real-time feedback between the people doing the work and the people building the AI. Crosby used to run evals in big batches, but switched to a model where lawyers give engineers feedback every few hours, allowing the engineers to tweak system prompts in real time. The system improved meaningfully after this switch. 

That said, ensure the builders are given enough space to improve, not just replicate, existing processes. Domain experts can be focused on rebuilding what currently exists. The product and eng team needs to take in that feedback but think first principles on what the new/better AI-enabled way should be. 

Start every board meeting with customer health. There's so much nuance in delivery that surfacing and problem-solving around customer learnings is even more important in AINS than in software companies.

IV. Product Roadmap

Every AINS company faces the same fundamental tension: customers are paying you for delivery today, but the entire venture thesis depends on what you build for tomorrow. Your product roadmap is where that tension either gets resolved or destroys you.

Navigate the important vs. urgent tradeoff.
Customer demands are loud and immediate. Internal platform investments are quiet and compounding. The failure mode is to become a traditional services business by neglecting platform development while responding to urgent client requests.

“The hardest tradeoff to make for an AINS in a competitive market is sacrificing distribution (onboarding another customer) to focus on AI leverage. As a rule of thumb, we started to see patterns when we got to about 80 clients. Before that, we didn't know what client preferences were rules or exceptions. That’s when we felt comfortable starting to say no to customer requests.”

Ryan Daniels, CEO of Crosby Legal

You have to balance three forces: what customers want, what's best for productization of your services, and how hard the product element is to build. The founders who get this right learn to say no to customer requests that don't map to their productization roadmap, even when the revenue is tempting. The best AINS companies find ways to prioritize the important work: they automate, they productize, and their margins expand. Those that fall prey to the urgent don't automate and don't find margin expansion.

Automate tasks, not people. This is a humbling realization for techie founders who want to fully eliminate a role. Think on a task basis instead. People can do more tasks when AI handles the repetitive ones. This framing is both more realistic and more palatable to customers nervous about AI replacing their teams. Thinking on a task basis also is the best way to build evals, which leads to faster productization.

“Focus on automtating tasks, not people. This means process-oriented and pragmatic engineers are important to prioritize when hiring in AINS.”

Timon Gregg, CEO of Strala

Set a north star product metric that tracks the impact of AI improvements on service delivery across cost, speed, and/or quality. The specific metric will vary by business, but every AINS company needs one. (We introduced Crosby's "HURT" metric in the PMF section) Over time, product investments need to tie to measurable improvements in gross margin.

V. Go-to-Market

It's the demo, stupid! In SaaS, demos showcase product value. In AI-native services, the art of the demo has been forgotten. Founders default to pitch decks and talk tracks. This is understandable since the AI product isn't used directly by the customer; the service provider wields the magic internally to deliver outcomes.

But it's a huge mistake. Without a demo, it can be hard for a buyer to visualize what makes you different from every other service provider with a similar pitch. And if you're a startup competing with established, trusted services brands, it's even more critical to showcase your magic. Don't hide it behind the curtain.

We've seen AI-native services companies halve their sales cycles just by adding a demo. Mechanical Orchard started demoing the power of their product, which is effectively Cursor for COBOL, and saw sales cycles cut by more than half. The customer will never directly use this system. But seeing the AI in action converts skeptics into believers far faster than any slide deck. So stop telling prospects about your AI. Show 'em.

Develop partnerships early; they can be a key growth accelerator. Partnerships with incumbents can be a major accelerant for AINS. Incumbents offer immediate market credibility, established distribution, and access to proprietary datasets, which can be crucial in the early days while your data corpus is small.

The partnership models that work go well beyond traditional revenue-share approaches. Some startups are exploring equity share relationships with incumbents. Others are acquiring existing service providers. Prosper AI's partnership with Firstsource (a leading revenue cycle services provider) provides immediate distribution and deal flow that would take years to build independently. There's also a growing trend of incumbents actively seeking AI-native partners because they can't build the capabilities themselves fast enough.

Tactical partnership lessons from our portfolio:

  • Find a mid-sized incumbent services provider that's incentivized to care and where you have real top-level influence. Deprioritize the biggest legacy incumbents initially; they'll move slowly, even though the relationship feels validating.
  • Ensure you maintain the end customer relationship. Don't get disintermediated. Losing the direct customer relationship means losing the data flywheel.

You'll need to train partners to do the heaviest-lift human tasks that your AI isn't currently able to do. This division of labor will change over time as your AI improves, which is exactly why maintaining the relationship matters.

VI. Pricing

The entire technology industry is moving toward outcomes-based pricing. Software companies are starting to explore it, but they face real challenges: attribution is hard (how much value did the software add vs. the human using it?), and the line between copilot and autopilot remains blurry.

AI-native services are uniquely well positioned. By definition, an AINS company is providing all of the value: the customer hires you to deliver an outcome, and you're accountable for getting it done. There is no attribution problem. The service IS the outcome. This makes AINS the most natural home for outcome-based pricing in the entire AI economy.

How to structure outcome-based pricing in practice depends on the nature of the work:

  • Discrete, large-scope work: If each engagement is a well-defined project (e.g., migrating a mainframe, processing a complex insurance claim), you can price the specific piece of work directly. The outcome is clear, the scope is bounded, and the customer understands what they're paying for.
  • Continuous, variable work: If the work is ongoing and each task varies in complexity and value (e.g., handling a stream of customer service requests, processing a flow of insurance submissions), a credits-based model can work well. Credits let you normalize across tasks of different sizes while still tying price to output rather than hours. The key is that the credit unit should map to something the customer intuitively understands as a unit of work.

The practical path: Many founders will need to start with the market norm (typically labor-based pricing) while they're learning to deliver efficiently. This is fine. But set a clear timeline to transition to outcome-based pricing as your AI matures and your delivery model stabilizes. The companies that stay on labor-based pricing too long end up cannibalizing their own growth as automation increases.

Embed recurring revenue where possible. Some AINS businesses operate in industries where multi-year contracts and long-term service are the natural norm. Hanover Park, as an AI-native fund administrator, benefits from this: fund admin relationships typically last years. If your business or industry doesn't have that built-in stickiness, you can still create it. Palantir did this effectively by delivering customized analyses for clients and then charging for the leave-behind software on a recurring basis.

VII. Defensibility and Moats

Build the data flywheel from day one. In SaaS, the product generates data as a byproduct. In AINS, the data generated by doing the work IS the product advantage. Every engagement should make your AI better, your delivery faster, and your outcomes more predictable. To that end, ensure your MSA/engagement letters give you the ability to use the data from your service to imporve your service. 

Harper illustrates this well. Every lead, call, email, and policy generates data that feeds their AI, improving matching between businesses and underwriters and driving higher conversion rates over time. This is the hallmark of a great AINS business: the work compounds into a durable advantage. If you're not building this flywheel from day one, you're just a services company that uses AI tools.

One underappreciated form of data leverage: AINS companies can use AI to optimally match a client with the best internal service provider suited to serve them, understanding style, expertise, capacity, and other factors. This matching improves with every engagement.

Brand is a powerful and underappreciated moat. AINS is fundamentally about selling outcomes, which requires the customer to extend a lot of trust. In professional services, brand has always mattered (it's why the Big 4 command premiums despite often delivering mediocre work). How can AI-native startups address the cold start problem with respect to brand? Early on, you need to borrow credibility, either by hiring respected service providers or partnering with branded incumbents. Over time, the higher quality/speed of your work should enable you to build your own brand reputation.

Scope and depth of the work create switching costs. Some AINS businesses don't just deliver a service; they take on so much of the customer's core operations that switching becomes prohibitively difficult. Hanover Park has built the system of record (an ERP) and runs all of the customer's data through this customized system. When you become the infrastructure layer and not just the service layer, when your customer's entire data history and operational workflow runs through your system, the magnitude of that data and the depth of that integration make switching enormously painful. This is a qualitatively different moat than a simple API integration.

VIII. Metrics

Traditional SaaS metrics don't capture whether an AINS company is actually achieving AI leverage. Growth rate and retention aren't sufficient given the Mirage PMF problem. We think about AINS metrics in two categories: leading indicators that tell you whether your AI productization is working, and lagging indicators that confirm it's showing up in the financials.

Leading Indicators (Is AI actually doing the work?)

North Star Product Metric: The single number that captures how much of the work AI is actually doing.
  • Set a north star product metric that tracks the impact of AI improvements on your service delivery. The specific metric will vary by business, but every AINS company needs one. Crosby Law's version is "HURT" (Human Review Time): the minutes of human labor required per document after the AI processes it, without sacrificing quality. As HURT approaches zero, margins approach software margins. Every AINS company should define their own version.

Lagging Indicators (Is it showing up in the business?)

Revenue per Employee: The simplest test of whether AI is actually doing the work at scale.
  • Revenue per employee is a critical, underappreciated metric. It's the simplest test of whether AI is actually doing the work at scale. If this number isn't meaningfully higher than legacy service providers in your space, your AI isn't pulling its weight. More granularly, you could isolate service-relevant FTEs to understand AI leverage over time.
  • Per-customer margin breakdown. Understand what actions drive gross margin on a per-customer basis. This granularity is essential for identifying which customers are on a path to AI leverage and which are stuck in labor-intensive delivery.

One important nuance: define gross margin honestly. Some AINS companies bury meaningful inference/compute costs in opex rather than COGS, which artificially inflates margins. Inference costs, and any human-in-the-loop labor all belong in COGS.

Emergence is compiling the first benchmarking analysis for AINS companies. We plan to release it in summer 2026.

IX. M&A

Consider acquisitions, but time them right. Some AINS companies will eventually need to acquire legacy service providers to scale revenue rapidly, access customer relationships, or bring in domain expertise. But timing matters enormously.

Don't acquire too early. It can distract from the buildout of your core AI platform, which is the entire reason you're venture-backable in the first place. Get your product and delivery model working first. Also, ensure your AI-first culture is solidified before pursuing M&A, so that when industry veterans join you, they conform to your way (and not vice versa). Behavior changes is hard.

Once the platform is mature and you've proven AI leverage, acquisitions can be a powerful accelerant for growth. Before that, they risk turning you into a conventional services firm with a venture balance sheet.

What Comes Next

AI-native services succeed because they collapse software and services into one integrated system, delivering the full outcome the customer wants. By owning the full stack, they can guarantee the quality of the output. That structural advantage is why this model can deliver 5-10x improvements in speed or throughput while operating at 50%+ gross margins, and why the opportunity extends far beyond the categories that have gotten early attention.

Every vertical services market with high-volume, repeatable workflows is a candidate for AI-native disruption: insurance claims and brokerage, fund administration, customs brokerage, revenue cycle management, KYC compliance, supply chain operations, and many more. The BPO market alone represents enormous opportunity, particularly in areas with heavy "stitch work" across multiple systems.

The founders who will build generational companies here share a few qualities: they pick a focused vertical where they have genuine domain credibility, they build AI leverage from day one rather than hoping to add it later, they resist the seduction of bespoke revenue, and they measure themselves honestly on whether the AI is actually doing the work.

If you're building an AI-native services company, we'd love to learn alongside you. Share your thoughts, pushback, or examples. We host regular pricing workshops and founder working sessions in San Francisco, and we're building a benchmarking dataset for AINS companies to help the community develop shared metrics and best practices.

Go to our hub for AI-Native Services companies.

Special thanks to the founders and CEOs who have shared their learnings with us and informed this playbook: Rob Mee (Mechanical Orchard), Dakotah Rice (Harper), Chris Hladczuk (Hanover Park), Jamie Cuffe (Pace), Ryan Daniels (Crosby), Timon Gregg (Strala) and Xavi de Gracia (Prosper AI). Thanks also to Madhavan Ramanujam for the pricing framework, and our teammates at Emergence for their contributions to our ongoing research.

Spring 2026 Edition. Next update: Fall 2026.
No items found.
No items found.
No items found.
Recent Content

Building something iconic?

We’d love to meet you. In the meantime, subscribe to our newsletter to stay in the loop with the latest from Emergence.