In 2024, Emergence Capital put a name on something that had been happening quietly for a couple of years: AI-native services, or AINS. The pitch sounds simple. Instead of selling a tool and letting the customer do the work, you sell the finished result and you stay accountable for it. No dashboard to learn, no seat to onboard, no "here's how you'd use our API to solve this yourself." The customer hands you the job. You hand back the outcome.
By 2026 this isn't a VC thesis anymore. It's a live decision every founder building with AI has to make, usually without realizing they're making it. Are you building a tool someone operates, or a service that operates itself? The two look similar in a demo. They are completely different businesses to run, price, and sell. Getting this wrong costs you a year.
What's the actual difference between an AI-native service and AI-powered SaaS?
AI-powered SaaS is still software. The AI makes it faster or smarter, but the customer is still the one doing the work: uploading the data, reviewing the output, deciding what to do with it. You're selling capability. The value only shows up once someone on the customer's team learns to use it well.
An AI-native service skips that step entirely. The vendor owns the outcome, not just the tool that might produce one. A claims-processing AINS company doesn't sell you claims software, it processes the claims. A bookkeeping AINS company doesn't sell you a smarter ledger, it closes your books. If the job doesn't get done, that's the vendor's problem, not a support ticket.
This is why outcome-based pricing works for AINS in a way it never quite worked for SaaS. Software vendors have spent a decade trying to tie price to value and running into attribution problems: how much of the customer's win was the tool, and how much was the customer's own effort? An AI-native service doesn't have that problem. The service is the outcome. You can price per claim processed, per account reconciled, per call converted to a booking, because there's nothing else in the value chain to argue about.
Why are AI-native services taking off now?
The honest answer is spend, not novelty. Pear VC has been explicit about the numbers driving their AINS bets: legal services spend runs roughly 40x legal software spend. Finance is around 26x. Recruiting is close to 38x. That gap is the whole opportunity. It means the budget already exists, it's already being spent on humans doing the work by hand, and nobody has to be convinced to open a new line item. You're not selling a new tool into a flat budget. You're offering to do the same job the client already pays for, faster and for less.
That only works in certain kinds of work, though. The pattern holds where the job is high-volume and repeatable, where the logic is rules-driven rather than genuinely judgment-heavy, and where "did this get done correctly" is something you can actually measure. Insurance claims, fund administration, KYC checks, medical coding and revenue cycle management, customs brokerage: these show up constantly in AINS deal flow because they're all, underneath the paperwork, the same shape of problem. A lot of volume, clear rules, a checkable result.
Four questions before you decide what you're building
If you're a founder trying to work out whether your idea is a tool or a service, these are the questions that actually separate the two:
Is the work rules-driven or judgment-heavy? AINS wins on the first kind. If every case genuinely requires senior human judgment with no repeatable pattern underneath it, you're building a decision-support tool, not a service that replaces the decision-maker.
Can you actually measure the outcome? Not "the customer seems happier," but a number: claim processed correctly, account reconciled, call converted to a booking. If you can't measure it cleanly, you can't price it as an outcome, and you're back to selling software.
Does the budget already exist? The best AINS ideas displace an existing line item (a team, an outsourced vendor, a manual process) rather than asking a customer to find new budget for a category they've never bought before.
Will every engagement make the system better? A real AINS company builds a data flywheel from day one, where each case handled improves the next one. If your delivery doesn't compound like that, you're running a services business with an AI feature, which is a fine business, just not this one.
What is "mirage PMF" and how do you avoid it?
The most useful warning in this space isn't about market size, it's about self-deception. Emergence calls it "mirage PMF": revenue and logo growth that looks like proof the AI is working, when actually a team of humans is quietly doing the work behind the interface. It's an easy trap to fall into, because the customer doesn't care how the sausage gets made as long as the outcome shows up, and early revenue always makes a founder more confident than the underlying leverage justifies.
The tell is in the unit economics, not the top line. If cost per case handled isn't dropping as volume grows, you don't have an AI-native service. You have a services business wearing an AI logo, and the moment a well-capitalized competitor automates the same workflow for real, that gap becomes very visible very fast.
There's a second cost people underweight too: owning the outcome means owning the liability when the AI gets something wrong. That's a different risk profile than shipping code and handing off a tool for someone else to operate. It's worth pricing that risk in from the start, not after the first bad claim or the first missed compliance deadline.
Where we've felt this ourselves
We didn't set out to write a think piece about AINS. We noticed the pattern because we'd already half-built into it with Callen AI, the AI receptionist we built and run for clinics. Callen doesn't sell a dashboard. It answers the phone, books the appointment, and puts it on the calendar. The clinic isn't operating a tool, they're getting calls answered.
And yet we currently price and package Callen like SaaS: a flat monthly fee, tiered by call volume, the way you'd price any subscription product. That's the exact tension this whole category is about. The ROI math we published on Callen, a clinic recovering somewhere around €1,000 a month in bookings against roughly €99 in monthly cost, is genuinely an outcome-based pitch even though the invoice looks like a software bill. We could price it per call answered or per appointment booked instead, and it would arguably be a more honest reflection of what the clinic is actually buying. We haven't made that switch yet, and we're not pretending the decision is obvious. It's the same tradeoff every founder building in this space is weighing: outcome pricing is more defensible, but it's also a heavier commitment, both operationally and legally, than a subscription line.
What building Callen did teach us, regardless of which pricing model wins, is that scope discipline matters more than the AI itself. The clinic-reception version of the product works because it does one job completely rather than trying to be a general-purpose voice agent. That's true whether you're building a tool or a service. Pick the narrowest version of the job, prove you can do it end to end, and only then decide how you want to charge for it.
The practical takeaway
If you're a pre-seed or seed founder deciding what to build next, the AINS question isn't academic, it changes your whole roadmap. A tool needs onboarding flows, documentation, and a self-serve funnel. A service needs delivery capacity, domain credibility, and pricing that survives an audit of your own unit economics. Building the wrong one doesn't fail loudly. It just grows slower than it should, for reasons that look like a go-to-market problem but are actually a business-model problem.
If you're working through that decision and want a second, technically honest opinion before you commit engineering time to one model or the other, that's exactly the kind of call we like to get on before anyone writes code.