The Delegation Threshold: When Buyers Stop Testing AI
By Vikas Malpani
A software company most people had not heard of two years ago just raised two billion dollars at a forty-eight billion dollar valuation. That part is not the interesting number. Valuations are opinions. The interesting number is underneath it: the company’s run-rate revenue went from about 492 million dollars in May to almost 900 million by September. Four months. Nearly double.
Revenue does not move like that because a product got cheaper or a demo got slicker. It moves like that when a specific thing happens inside the customer. The customer stops asking “does this work?” and starts asking “what do I do if this goes down?” That switch, from evaluating a tool to relying on it, is the whole game. I call the line where it happens the delegation threshold, and almost everything that matters about an AI business is decided by whether you cross it.
Here is the uncomfortable part. Most AI products never cross it. They get tried, they get talked about, and then they get quietly dropped. A small number cross it and their revenue bends upward in a way that looks impossible until you understand what changed. This post is about that line: why it exists, what it looks like in your own numbers, and how you build something that gets on the right side of it.
The churn wave nobody wants to name
Start with the number that gets buried under the funding headlines. In 2026, MIT’s NANDA initiative reviewed more than 300 publicly disclosed enterprise generative-AI deployments and found that 95 percent of them delivered zero measurable return. Not low return. Zero. Separately, industry analysts put the share of enterprise AI pilots that ever reach production at around 12 percent, which means roughly 88 percent die in the pilot stage. And the reason they die is rarely the model. It is operational: the pilot ran on clean data, skipped the real systems, and dodged the compliance and workflow constraints that govern actual work. The moment it touched the real environment, it fell over.
Now look at retention, because retention is where evaluation and dependence separate cleanly. Across 2026, AI-native software companies posted a median net revenue retention of about 48 percent, with gross retention near 40 percent. Traditional B2B software sits closer to 82 percent net retention. At the low end, AI products priced under 50 dollars a month retained even worse, with gross retention around 23 percent. Read that plainly: the typical AI product loses more than half its revenue base inside a year. People sign up, poke at it, and leave.
That is the churn wave. It is what “being tested” looks like at scale. A product that is being tested has a revenue base made of curiosity, and curiosity does not renew. You can raise a round on it, you can post a screenshot of a hockey-stick sign-up chart, and you can still be running a business that leaks out the bottom as fast as it fills at the top.
Against that backdrop, the companies whose revenue compounds are not just “better.” They are on the other side of a line. Snowflake reported net revenue retention around 125 percent in its most recent fiscal year. Datadog has run near 120 percent. These are consumption businesses where customers who depend on the product spend more every quarter without a new sales cycle. Same category of metric, opposite universe of outcome. The difference is not effort or spend. It is whether the customer crossed the threshold.
It helps to sit with how much money this churn represents. Estimates put global enterprise AI spending in 2026 at roughly 30 to 40 billion dollars, and the overwhelming majority of that produced no verifiable business value. That is not a story about bad technology. The models in those failed pilots were often the same models powering the products that compounded. The gap was not intelligence. It was whether the product got trusted with real work, and trust is not a model property. It is a relationship property, earned over time through behavior the buyer can predict.
This is why I stopped treating “does the demo impress people” as a meaningful question. Demos impress people at rung one and two of the ladder, and rung two customers churn. The question that predicts a business is narrower and less flattering: has anyone removed a human from the loop because of you, and left them removed? Most products, even well-funded ones with beautiful demos, cannot honestly answer yes. The ones that can are on a different curve entirely, and the curve is the tell.
The delegation threshold, defined
The delegation threshold is the point at which a buyer moves from using your product to run experiments to using your product to run the business. Below the line, your software is a thing someone checks. Above the line, it is a thing someone relies on and would have to actively replace to stop using.
The clue is in how people talk about you. Below the threshold, a customer says “we’re trying it out” or “we’re seeing what it can do.” Above the threshold, the same customer says “we can’t turn it off” or “our team would revolt.” That sentence, “we can’t turn it off,” is the most valuable sentence in software. It is a churn rate of near zero and an expansion engine in one phrase, and it is earned, not bought.
What makes this a threshold and not a gradient is that behavior changes discontinuously when you cross it. Before, the buyer keeps a fallback ready and mentally treats your product as optional. After, the buyer removes the fallback, reorganizes work around your product, and starts treating outages as emergencies. The moment the fallback goes away is the moment your revenue changes character. I unpack the related idea of whether a business can even be absorbed by a bigger model in the absorption test; the delegation threshold is the demand-side mirror of that supply-side question.
The trust ladder: five rungs and one line
Buyers do not jump straight to dependence. They climb. I map the climb as five rungs, with the delegation threshold sitting between the third and fourth. The diagram below is the whole model on one line, so read it before the words.
Rung one is curiosity. Someone signs up because your launch was loud or a friend mentioned you. They click around. This rung produces vanity metrics and nothing else. Rung two is trial: they run one real task and judge the output. Rung three is the pilot, which is where most AI products get stuck. A pilot is bounded on purpose. It runs on a safe slice of work, a human checks everything, and there is always a way back. Pilots feel like progress and generate almost no durable revenue, because the buyer has not given up anything yet.
The line sits right after the pilot. Crossing it means the buyer takes the training wheels off: removes the human double-check on every action, wires your product into the real workflow, and lets it own an outcome that matters. Rung four is delegation, where your product runs a live workflow with the buyer watching the results rather than every step. Rung five is dependence, where removing you would break something the business needs, and everyone knows it.
The reason this framing is useful is that it tells you what to measure. Sign-ups measure rung one. Activation measures rung two. Pilot count measures rung three, which is exactly the rung that fools founders into thinking they have traction. The only metrics that measure the threshold are the ones that show a fallback being removed and never coming back.
The revenue signature of trust
Here is a claim I will defend: you can tell whether a customer has crossed the delegation threshold without ever talking to them, just by looking at the shape of their revenue over time. Tested revenue and delegated revenue have different fingerprints.
Tested revenue spikes and decays. A launch or a sales push brings a wave of curious accounts, usage pops for a few weeks while people play, and then it fades as the novelty wears off and nothing forced anyone to keep coming back. On a chart it looks like a series of bumps that never compound. Delegated revenue does the opposite. It starts smaller and quieter, then bends upward and keeps bending, because each customer who depends on you uses you more, not less, and rarely leaves. The diagram makes the contrast concrete.
The table below turns the fingerprint into things you can actually check in a dashboard. If your numbers look like the left column, your customers are testing you. If they look like the right column, they have crossed over.
| Signal | Being tested (below the line) | Being trusted (above the line) |
|---|---|---|
| Net revenue retention | Under 100 percent, often far under | Over 100 percent, driven by usage |
| Contract shape | Month to month, easy to cancel | Multi-year, renews without a fight |
| Usage over time | Peaks at onboarding, then drifts down | Rises as more work is handed over |
| Who touches it | One curious champion | A whole team, plus a system of record |
| Outage reaction | Nobody notices for days | A ticket in minutes; it is an emergency |
| How customers describe you | “We’re trying it out” | “We can’t turn it off” |
The coding-agent companies are useful here precisely because their numbers are public and lopsided. Cursor’s parent went from roughly 100 million dollars of annualized revenue in early 2025 to about four billion by mid-2026, and its enterprise share climbed to around 60 percent as month-to-month individual seats got replaced by multi-year company contracts. That last detail is the delegation threshold showing up in the contract structure. Individuals were testing; companies started depending. The revenue shape follows the trust shape. If you want the pricing mechanics behind why usage-based revenue compounds when a product is depended on, I went deep on that in pricing under cheap inference.
Notice what the coding-agent numbers do not depend on. They do not depend on those companies having a secret model nobody else can reach; the underlying models are broadly available. They depend on the work being handed over. When an engineer lets an agent open pull requests that ship, or a bank lets Devin touch real repositories inside its own environment, the human has moved from doing the work to reviewing exceptions. That handover is the threshold, and the revenue curve is just its shadow. Read enough of these curves and you stop being impressed by growth and start asking a single question about any AI company: is this revenue delegated or merely tested? The answer predicts whether the curve continues or collapses.
Three preconditions for crossing
A buyer does not cross the threshold because your marketing convinced them. They cross it because three specific things became true at the same time. Miss any one and they stay in the pilot forever, no matter how good your average output looks.
One: a reliability floor at the worst case, not the average. This is the one founders get wrong most often. You optimize the average result because that is what demos show and benchmarks reward. But a buyer deciding whether to remove the fallback is not thinking about the average. They are thinking about the worst thing that can happen when no human is watching. Delegation is a bet on your tail, not your mean. A product that is brilliant 95 percent of the time and catastrophic 5 percent of the time cannot be delegated to, because the buyer has to keep a human ready for the 5 percent, and keeping that human ready means they never actually crossed. The reliability that matters is the floor. I wrote about why this tail problem sinks agents specifically in the AI agent reliability paradox.
Two: outcome ownership, not task assistance. There is a hard line between a product that helps someone do a job and a product that does the job. Assistance hands work back to a human at the end: here is a draft, here is a suggestion, you take it from here. Ownership closes the loop: the work is finished, filed, sent, or executed. You cannot depend on something that always hands the work back, because the dependence still lives in the human who finishes it. Crossing the threshold requires that your product own an outcome end to end, with the human moving to exception-handling rather than doing-the-thing. This is the same distinction that separates real service-as-software from dressed-up tooling, which I broke down in the service-as-software trap.
Three: embedding, so leaving is expensive. The third precondition is structural. For a buyer to depend on you, you have to be wired into their world: their data, their systems of record, their workflows, their permissions. Embedding is what turns “we could swap this out” into “swapping this out is a quarter-long project nobody wants to own.” This is not a trick to trap customers. It is the natural result of a product that actually runs a workflow, because running a workflow means holding state and context that would be painful to rebuild elsewhere. Embedding is also where switching cost and data advantage compound, a theme I explore in the data moat test.
| Precondition | What it means | Failure mode if missing | The test to run |
|---|---|---|---|
| Reliability floor | Trustworthy at the worst case, not the average | Buyer keeps a human ready for the bad case and never truly crosses | Measure your tail failure rate, not your benchmark score |
| Outcome ownership | Finishes the job instead of handing back a draft | Dependence stays lodged in the human who completes the work | Ask: does a human do the last step, or only handle exceptions? |
| Embedding | Wired into the data, systems, and workflow | “We could swap this out” stays true, so nobody commits | Count accounts with real system-of-record access vs sandboxes |
Put the three on two axes and you get a map of where products actually sit. The vertical axis is reliability at the worst case. The horizontal axis is whether you assist the task or own the outcome. Embedding is what lets a product live in the top-right and stay there.
The dangerous quadrant is the bottom-right, demo-ware. That is a product that markets itself as owning the outcome without the worst-case reliability to back it up. It wins pilots on a great demo and then blows up in production, which is exactly the operational failure mode behind that 88 percent pilot mortality rate. Demo-ware does not just fail to cross the threshold. It poisons the buyer’s willingness to try the whole category again. If you are going to claim you own an outcome, you have to earn the floor first.
Reading the threshold in your own metrics
Founders track the wrong dashboard because the wrong dashboard is flattering. Sign-ups, demo requests, pilot logos, and social mentions all measure the rungs below the line, and they all go up when you are being tested. You can have a great-looking top of funnel and a business that never crosses over. So here is a smaller, harsher set of numbers that actually track dependence.
The first is net revenue retention, cohorted by how long a customer has been live. If your oldest cohorts are spending more each quarter without a new sales motion, people are depending on you. If they decay, they were testing. The second is the fallback question, which you have to ask in interviews because it does not show up in product analytics: “if we disabled this tomorrow, what would you do?” A tested customer says “go back to how we did it before” without flinching. A crossed customer pauses, because the honest answer is that they have dismantled the old way and it would hurt. The third is usage depth over time within an account: are they handing you more kinds of work, or the same narrow slice they started with? Expansion of scope is the sound of trust growing.
One more thing about the fingerprint, because it saves you from a common self-deception. A single big logo is not evidence of crossing. Big companies run pilots constantly, and a famous customer name on a month-to-month pilot is testing economy revenue with good PR attached. What tells you the truth is not the size of the logo but the shape of its usage: a mid-size customer who has quietly routed live work through you for a year is worth more, as a signal, than a household name still poking at you in a sandbox. Judge accounts by depth of dependence, not by the size of the brand.
The single best proxy, if you only track one thing, is the ratio of your revenue that sits in multi-year or auto-renewing commitments where a human has stopped approving each unit of work. That is delegated revenue. Everything else is test revenue wearing a subscription costume. When I looked at what actually inverted in the last two years of company building, this shift from headcount-approved to system-owned work was the quiet center of it, which I traced through in the AI agent cost margin trap.
The threshold is reversible
Crossing the line is not a trophy you keep. It is a state you maintain, and you can be pushed back across it. The clearest public example is Klarna. In 2024 the company replaced roughly 700 customer-service roles with an AI assistant. It looked like a total crossing: the assistant handled about 2.3 million conversations in its first month and took over three-quarters of all chats. On the volume metrics, delegation had happened.
Then by May 2025 the CEO admitted the company had cut too far, quality had dropped, and it was rehiring humans for complex cases. What went wrong maps exactly onto the preconditions. The volume metrics the AI performed well on hid the worst-case failures on hard tickets, and the reliability floor on those tickets was below what customers would tolerate. So Klarna did not abandon AI. It rebalanced, keeping the assistant on the high-volume front line and bringing humans back for the value tier where the floor had not held. The buyer, in this case Klarna’s own operations team and its customers, un-delegated the part that had crossed on a false floor.
The lesson is not “AI cannot be trusted.” Plenty of AI is trusted, permanently, right now. The lesson is that the threshold is defended by the floor. If your worst case degrades, whether because the world shifted, the model changed under you, or you cut a corner to ship, the buyer feels it and quietly puts the fallback back. Every founder above the line is one bad month away from being pushed below it. This is why the reliability floor is not a launch requirement you satisfy once. It is a standard you hold.
Where this tells you to build
The delegation threshold is not just a diagnostic. It is a wedge for deciding what to build next. If most of the value in AI accrues to products that get depended on, then the best opportunities are the ones where crossing the threshold is both achievable and defensible.
The first place to look is work with a narrow, checkable outcome. Delegation is easier to earn where success is unambiguous, because a clear definition of done lets you build a reliability floor you can actually prove. “Reconcile these invoices” can be verified. “Be creative” cannot. Narrow, verifiable outcomes are where the floor is buildable, which is why the earliest durable delegation is happening in coding, support, reconciliation, and other domains with a right answer.
The second place is work that is high volume and low glory, the tasks humans are glad to hand off. Delegation faces less resistance where the human was never proud of doing the work anyway. Nobody defends their territory over expense categorization. The third is regulated or consequential work, but only if you can hold the floor, because that is where the fallback is most expensive to maintain and therefore where crossing the threshold creates the deepest dependence. That is a harder build and a bigger prize. The through-line is that you want a domain where owning the outcome is possible, the floor is provable, and the buyer badly wants to stop keeping a human on standby. For the fuller version of how to pick lanes like this, the parent playbook is the AI-native founder playbook, and the supply-side counterpart to this demand-side view is the inference shift.
The two economies inside one market
Step back and the AI market splits into two economies that share a name and almost nothing else. The first is the testing economy. It is enormous, loud, and mostly a churn machine. It is where the median 48 percent net retention lives, where pilots go to die, and where most of the venture money quietly evaporates. Products here compete on demos, launch splashes, and being first to wrap a new model. Growth is real but rented, because the customers are renting curiosity and curiosity has a short lease.
The second is the dependence economy. It is smaller in company count and vastly larger in durable value. It is where retention runs past 100 percent, where contracts stretch to years, and where a single customer’s spend climbs quarter after quarter because they keep handing over more work. Products here do not compete on demos. They compete on the reliability floor and on how deeply they are wired in. A better model down the street does not move these customers, because the cost of re-crossing the threshold is higher than the benefit of a marginally smarter tool.
Almost every strategic mistake I see comes from a founder who thinks they are in the second economy while their numbers say they are in the first. They raise on testing-economy growth, staff up as if the revenue is durable, and then get surprised when the base leaks. The delegation threshold is the border between the two economies, and knowing which side you are on is worth more than any growth-rate headline. You do not get to pick your economy by intention. You get sorted into it by whether customers depend on you.
The round is a lagging indicator
Now the part most people get backward. When a company raises a giant round on the back of doubling revenue, the story becomes the round. Investors are validating the model, the market is huge, the founders are geniuses. That framing treats the funding as the signal. It is not. The funding is a lagging indicator of a threshold that got crossed months earlier, inside customers, where nobody was looking.
The revenue doubled because buyers stopped testing and started delegating. The round is just capital chasing a curve that already bent. If you are a founder watching these announcements and drawing the lesson “raise a big round to win,” you are copying the receipt instead of the meal. The companies posting these numbers did not compound because they raised. They raised because they compounded, and they compounded because they got on the right side of the delegation threshold in a domain where the floor was buildable.
Here is the sharper version. Most commentary about AI winners fixates on model quality, as if the best model wins. But the retention data says otherwise. Products with excellent models and no path across the threshold still churn out at 48 percent net retention, while products in embedded, outcome-owning positions compound at 120 percent and up on models that are not meaningfully better. The model is table stakes. The threshold is the moat. And the threshold is not crossed by being smarter. It is crossed by being trustworthy at the worst case, owning the whole outcome, and being wired in so deeply that leaving hurts. If a competitor with a better model shows up, the customer who depends on you does not switch, because switching means re-crossing a line they already paid to cross once.
The counterview deserves its due. Someone will argue that in a market growing this fast, land-grab economics beat retention: get the logos now, fix the churn later, and let a rising tide and future model upgrades pull the tested cohort across the line eventually. That can work in a genuinely winner-take-most category with strong network effects. But the 2026 retention numbers are the argument against it. If sub-threshold revenue churns out faster than you can replace it, growth funded by acquisition alone is a treadmill, and the model upgrades that were supposed to rescue retention are available to every competitor at the same time. Land-grab wins only if you convert the land to dependence before the novelty budget runs out. The threshold is still the thing that matters; the debate is only about how long you can defer it.
Cohort your retention by tenure this week
Enough theory. Here is the concrete work, and none of it requires a new feature.
Cohort your retention by tenure this week. Pull net revenue retention split by how long customers have been live, not blended. Blended retention hides the truth because new sign-ups mask old churn. If your six-month-plus cohorts are below 100 percent, you are being tested, and no amount of top-of-funnel growth fixes a leaking base. This is the single most honest number in your business and most founders have never looked at it cleanly.
Ask ten customers the fallback question. Literally ask: “if we turned this off tomorrow, what would you actually do?” Write down the answers verbatim. Count how many have a painless answer versus how many wince. The ratio is your real position on the ladder. Do this yourself, not through a survey, because the pause before the answer tells you more than the words.
Find your worst case and measure it. Stop reporting average quality. Define the worst plausible failure when no human is watching, and measure how often it happens and how bad it is. That number, not your benchmark score, is what a buyer is really deciding on when they consider removing the fallback. If you do not know your tail, you do not know whether you can be delegated to.
Pick one outcome to own end to end. Identify a single task where you currently hand work back to the human, and ask what it would take to close the loop so the human only handles exceptions. You do not have to own everything. You have to own one thing completely, because one owned outcome crosses the threshold while ten assisted tasks never do.
Instrument embedding. Track how many of your accounts have connected their real system of record, granted real permissions, and routed live work through you, versus how many are running you in a sandbox. Sandbox accounts are pilots that will churn. Wired-in accounts are candidates for dependence. Move the second number and you move your retention. If dependence-first product decisions feel like they run against your instinct to keep everything optional and easy to leave, that instinct is worth examining, and I dug into that founder reflex in the initiative problem.
Frequently asked questions
What is the delegation threshold?
The delegation threshold is the point where a buyer stops using your AI product to run experiments and starts using it to run real work. Below the line the product is something a customer tests and can drop at any time. Above the line the customer has removed their fallback, wired the product into their workflow, and would have to actively replace it to stop. It is the moment “we’re trying it out” becomes “we can’t turn it off,” and it is where durable revenue begins.
How do I know if customers have crossed it?
Look at three things. First, net revenue retention cohorted by tenure: crossed customers spend more each quarter without a new sales cycle, so their retention runs above 100 percent, while tested customers decay. Second, the fallback question, asked directly: crossed customers wince when you imagine turning the product off because they dismantled the old way of working. Third, usage depth over time: crossed customers hand you more kinds of work, while tested ones stay in the narrow slice they started with. If your oldest cohorts are shrinking, you are still being tested.
Why do so many AI products fail to cross it?
Because they optimize the average result instead of the worst case. A buyer deciding whether to remove the human fallback is betting on the tail, not the mean. A product that is excellent most of the time and catastrophic occasionally cannot be delegated to, because the buyer has to keep a human ready for the bad case, which means they never truly crossed. Most AI products are stuck in the pilot stage for exactly this reason, which is why industry research puts the share of enterprise pilots that reach production at only about 12 percent.
Is the delegation threshold the same as product-market fit?
It is a sharper, later version of it. Classic product-market fit asks whether people want your product. The delegation threshold asks whether they depend on it. You can have people who like your product, use it happily, and still churn when the novelty fades, which is what a median net revenue retention near 48 percent for AI-native software describes. Crossing the threshold is the difference between being wanted and being needed, and only the second one compounds.
Can a customer cross back over the threshold?
Yes, and this is the part founders underestimate. The threshold is held by your reliability floor. If your worst case degrades, the buyer feels it and quietly puts the fallback back, un-delegating the work. Klarna is the public example: it moved most customer service to AI, then rebalanced in 2025 after quality on hard cases dropped, bringing humans back for complex tickets. Being above the line is a standard you maintain, not a milestone you bank.
Does a bigger funding round mean a company crossed the threshold?
The round is a lagging indicator, not the signal. When a company doubles revenue and then raises at a huge valuation, the revenue moved first because buyers started delegating, and the capital followed the curve that already bent. Copying the round is copying the receipt instead of the meal. The companies posting these numbers raised because they compounded, and they compounded because they got on the right side of the threshold in a domain where the reliability floor was buildable.
Where is delegation easiest to earn?
In work with a narrow, checkable outcome, because a clear definition of done lets you prove a reliability floor. It is also easier in high-volume, low-glory tasks that people are glad to hand off, and in consequential or regulated work where keeping a human on standby is expensive, provided you can hold the floor there. The pattern to look for is a domain where owning the outcome end to end is possible, the worst case is provable, and the buyer badly wants to stop supervising every unit of work.
What is the one metric that best tracks the threshold?
The share of your revenue sitting in multi-year or auto-renewing commitments where a human has stopped approving each unit of work. That is delegated revenue. It strips out the curious sign-ups and month-to-month accounts that look like traction but churn, and it isolates the customers who have actually handed over control. Everything else is test revenue wearing a subscription costume.
The delegation threshold is the quietest number in your business and the one that decides its future. Cross it in a domain where you can hold the floor, and revenue compounds. Stay below it, and you raise money to refill a bucket with a hole in the bottom.