Selling Agents as a Service

In early 2026 the most common conversation I have with founders is around selling agents as a service¹. It is pretty clear that lots of businesses are going to transition to a more agent-first way of using software, and that there is money to be made during that transition. What is much less clear is what the playbook looks like if you're aiming for venture-scale returns. We are sitting in an uneasy phase where the B2B SaaS playbooks are seemingly no longer fit for purpose² but we haven't quite worked out what to replace them with. The core mistake founders are making is treating this as a pricing problem when it is actually a question of what kind of value they are creating.

Why the obvious analogy might be unhelpful

Agents have the potential to fundamentally change how a business runs because, in theory, you can automate inefficient processes currently performed by people. A lower or more scalable opex will lead to an adjustment to the underlying cost model of the business which will flow directly to the bottom line. This type of transformation doesn't map cleanly onto existing tech business models. Squint and it looks a bit like a software licence. Squint a bit harder and it looks like a plain old consultancy business. Once you buy into the idea that the thing being sold is an operating model change rather than just a software tool, the tendency is to head straight to The Palantir Analogy³. It's the poster-child of the category. Forward deployed engineers, strategic accounts, enormous contracts, lots of talk about transformation, very little talk about per-seat licenses. Great stuff.

However...

Pause for a second and consider what probably needs to be true for your customer engagement to be an actual Palantir-style opportunity:

If those conditions are not present, forward deployment degrades into implementation work surprisingly fast. At that point you have not built the next Palantir. You've built a consultancy with unusually high market demand and a sweet platform retainer. There are worse businesses to build. Plenty of consultancies make good money. It just helps to know that is what you are building before the margins quietly leave the room.

None of this means forward deployed engineers are a bad idea. It just means "be Palantir" is not a category strategy most people can adopt. It's an answer to a narrower set of problems than people want to admit. Most companies are not selling transformation. They are selling productivity and pricing it like transformation.

Value model first. Pricing model second.

Before you decide how to price agents, you need to decide what kind of value you are actually creating. Most of the confusion in this space comes from people mixing these up. There are really only three value models on the table:

1. Productivity gains: You help existing teams do the same work faster or cheaper. This is classic SaaS territory. The natural pricing models are seats, usage, or some hybrid of the two.
2. Labour substitution: You replace human effort with software. This looks like BPO with better margins. Pricing often gravitates toward a discounted version of human cost.
3. Operating model transformation: You change how the work itself is done. The system becomes the unit of execution, not the individual worker. Value is measured in cost-per-outcome, throughput, and capacity.

These are not interchangeable. They imply different buyers, budgets, and ceilings.

The SaaS instinct is to make agents look a bit like seats and a bit like usage, because that is legible and everybody knows how to talk about it. The problem is that classic B2B SaaS was built around land-and-expand. You land in one team, and then grow from there. I don't think that maps cleanly when the thing being sold is a changed operating process that removes people dependency. By definition, if it works it makes per-seat expansion less likely.

The agency instinct is the opposite. Since this is services-heavy, price it like services: time and materials plus margin. At least that is honest. The trouble is that if you stop there, you are basically admitting that you are an agency. Again, not a mortal sin. It just is what it is - probably not venture scale.

Then there is the version which is BPO wearing agentic clothing. The outsourced task currently requires humans, agents are a substitute for people, so the customer should pay some discounted fraction of the per-employee cost. What fraction? Tomasz Tunguz recently said "we are seeing agents command 75%, 85%, even 100% of a human equivalent salary".⁴ Essentially the argument is that where labour is constrained, you get to recover the value of that labour. Wowza! So let's just agree that agents are a better human worker for the price of a human worker and charge on that basis. Job done. Meh. I don't buy it. My instinct is that this is at best a transitional sales technique rather than the durable way the category will be understood. At the end of the day, people just don't value software that way. They value it less than hardware and I get the feeling that they'll value it a lot less than wetware. Software is expected to be deflationary. It replaces labour cost in a non-equivalent value frame. I just can't see mature buyers sitting there forever doing pseudo-headcount maths⁵.

Outcome pricing is more interesting, and in some cases is the right approach - pay per business outcome delivered, regardless of input costs. But it is also easy to make it sound more achievable than it really is. Do customers really want to pay in this way? Can suppliers really handle a scenario where delivery costs show up first and the value proof-point (and the payment) arrives later? I increasingly think the strongest commercial shape for this type of pricing will need to be a paid transformation programme that funds the work up front, followed by platform fees and then maybe usage or outcome-linked pricing once the thing is actually working. None of that is especially neat. It just feels more practical and honest.

The most attractive version of this is to price as a share of transformational value. If you reduce operating cost by a measurable percentage, you take a cut. In theory, this is the holy grail. It shifts software spend into operating budgets, which are much larger. In practice, it is harder to sustain than it looks. Customers will tolerate value-based pricing while the system is novel or irreplaceable. Over time, they will look for ways to internalise the capability or introduce competition. Unless you have a deep, defensible dependency in the system itself, you should assume that pure value-share models will compress.

The mistake is to treat this as a pricing problem. It isn’t. It is a value-definition problem.

If you are selling productivity, price like software. If you are selling labour substitution, price like services. If you are changing how the work itself gets done, you are selling a new operating model, and the commercial model will follow from that.

Most of the confusion around agents comes from trying to price the third like it is the first. The companies that win will be the ones that are honest about the value they are enabling.

The really hard part is organizational change. Plus ça change.

If you are in the third category, operating model transformation, then pricing is not the hardest part. Organizational change is. The question you need to answer is: which functional leader owns an important outcome, feels enough pain to care, and has enough mandate to push a change through?

Enterprise buyers (at least at the C-suite level) "will be brutally rational"⁶ about how to realise the bottom-line benefits of AI. We're starting to see the signs of it today. But at the same time, the organisations below those executives will not be particularly keen to drive through organizational change that impacts them and their fiefdoms directly.

The finance function is a bit of a special case because they typically care a lot about operational efficiency, but usually don’t control the IT budgets needed to automate or the people budgets they would be replacing. I suspect they may become an unusually useful wedge into companies for agentic transformation. Bear in mind though that they don't own substantial operating cost lines themselves so I foresee a bunch of political battles as these transformations roll out.

I also anticipate that a number of agent deployments are going to fail for organizational reasons long before they fail for software reasons. If you ask a workforce to write down the rubric that replaces them, you should not be shocked if the process self-sabotages. That is why I increasingly think staged rollout is not a compromise, it is the only strategy that will actually work. It puts a bit of a spanner in the works for the "share of transformational value" business case, when it has to be rolled out slowly and carefully but a realistic rollout will probably end up looking like this: first, make the human workflow better, particularly by automating stuff that people hate to do. Then, layer agentic decision-recommendation into that existing process so that human decision-making is informed by a rubric (i.e. a copilot). Finally, push toward fuller automation and replacement of humans-in-the-loop⁷. That sequence is not there because copilots are some glorious middle state. I actually think copilots, taken as a product category, kinda suck. The point is organizational change. You need people to surface the real rubric, trust the system enough to use it, and gradually accept that the locus of decision-making is moving. If you try to jump straight to full autonomy in a politically sensitive workflow, good luck with that.

This also points to a role I think matters far more than most people realize: a rubric champion. Not just a commercial sponsor. Not just a C-suite person who wants the cost line to go down. Somebody inside the function has to own the definition of what good looks like and feel personal responsibility for getting the rubric right. Without that, a surprising number of these projects will die in a swamp of missing requirements, passive resistance, and "funny how nobody mentioned that until handover."

The playbook

So the rough playbook, as I currently see it:

The pricing model that wins a 2026 deal is unlikely to be the one that defines the category. Headcount replacement is a useful temporary bridge, but over time, agents will be understood less as software pretending to be labour and more as the operating substrate for certain kinds of work. The companies that build venture scale returns will be the ones that correctly identify which value model they are actually delivering and build pricing, GTM and delivery around that core proposition.

---

1. Shall we call it SaaaS? Probably not... but its better than calling it AaaS, which sounds like the wrong kind of thought leadership. ↩↩
2. To mis-quote Mark Twain, the reports of the death of SaaS are greatly exaggerated.↩
3. If I had a pound for every VC encouraging their portfolio founders to adopt Palantir-style Forward Deployed Engineers...↩
4. Tomasz Tunguz, post on X. His exact line was that "we are seeing agents command 75%, 85%, even 100% of a human equivalent salary."↩
5. It also doesn't fit my expectation of how these systems will actually work. If agents mature in the way people hope, I doubt we end up with a neat one-to-one human replacement model. We probably end up with either swarms of narrow agents coordinating in odd ways, or with some absurdly capable mono-agent doing many things in parallel. Essentially a barbell. Modeling agentic value as a direct 1:1 replacement for human staffing feels like choosing an arbitrary point halfway along that barbell graph and then pretending nature selected it for you.↩
6. Ben Thompson, Enterprise Philosophy and the First Wave of AI. He argues enterprise buyers "will be brutally rational about how to achieve that" and that "services and integration teams will also make a comeback."↩
7. I'm not saying I endorse this. I'm just saying this is what will probably work best. You gotta get those turkeys to vote for Christmas somehow.↩