For the better part of two decades, enterprise software procurement has followed a familiar rhythm: negotiate a per-seat licence, roll out to users, and measure ROI in adoption rates. It was imperfect, but it was predictable. That predictability is now under serious threat — not from a single disruptor, but from an architectural shift that is quietly rewiring what software is expected to do and how it should be priced.
Tools like Cursor, Devin, and Perplexity are not simply adding AI features. They are built around a fundamentally different premise: that software should deliver outcomes, not just functionality. You do not pay Devin per developer seat; you pay for tasks completed. You do not subscribe to Perplexity to access a search interface; you use it because it collapses hours of research into minutes. For senior leaders evaluating their software estates right now, this distinction matters enormously — because the platforms you have invested in most heavily may be the ones least equipped to compete in this new environment.
The Seat-Licensing Model Was Always a Proxy Metric
Seat licensing was never really about seats. It was a convenient proxy for value — a way for vendors to monetise reach when measuring actual business outcomes was too complex or too contested. The assumption baked into every enterprise licence agreement was that more users meant more value delivered. That assumption held as long as software was primarily a tool for human workers to operate manually.
Agentic AI breaks that assumption entirely. When an AI agent can autonomously complete a workflow — drafting a proposal, qualifying a lead, debugging a codebase, synthesising a research brief — the number of human users accessing the platform becomes almost irrelevant. The value is no longer in the seat; it is in the result. Vendors who have built multi-billion-pound revenue bases on seat counts are now facing a structural challenge: their pricing model is misaligned with the value their most advanced customers expect to extract. That is not a minor inconvenience. It is an existential pressure.
Why Retrofitting AI onto Legacy Architecture Is Harder Than It Looks
Salesforce, HubSpot, ServiceNow, and their peers are not standing still. Each has made significant investments in AI — Salesforce's Einstein and Agentforce initiatives, HubSpot's Breeze, ServiceNow's Now Assist. The marketing is confident and the roadmaps are ambitious. But there is a structural problem that press releases tend to gloss over: these platforms were architected in an era of relational databases, rigid data models, and synchronous user interactions. Bolting agentic AI onto that foundation is less like upgrading an engine and more like fitting a jet turbine to a canal boat.
The core tension is this: agentic AI requires fluid, context-rich data access, the ability to trigger multi-step actions across systems, and real-time feedback loops that inform the next action. Legacy CRM and ERP architectures were designed around discrete transactions and human-initiated workflows. Their APIs were built for integrations, not for agents making hundreds of autonomous decisions per minute. Several engineering teams within major SaaS vendors have acknowledged privately that their internal data models — some dating back fifteen years — create genuine bottlenecks when trying to implement truly autonomous AI behaviour. The result is AI that feels tacked on, because in many respects, it is.
The Challengers Being Built on Agentic Foundations from Day One
The more revealing contrast is not between today's incumbents and each other — it is between the incumbents and the wave of AI-native platforms that have never known a world without large language models. Companies like Cognosys, Lindy, and a growing cohort of vertical-specific AI platforms are building their entire product logic around agents: persistent, goal-directed processes that operate across tools, hold context over time, and report back on outcomes rather than activities.
In practical terms, this means their data architectures are designed for vector search and semantic retrieval from the outset, their workflow engines assume non-linear, conditional execution, and their pricing models are structured around consumption or outcomes rather than named users. A mid-market UK professional services firm we spoke with recently replaced a significant portion of its HubSpot usage with a combination of an AI-native CRM and an orchestration layer — reducing its per-outcome cost by over 60 per cent whilst increasing the volume of qualified pipeline activity. That is not an isolated anecdote. It reflects a repeatable pattern emerging across sectors where process automation and knowledge work intersect.
What This Means for Enterprise Software Strategy in 2025 and Beyond
For UK organisations, the strategic risk is twofold. The first is over-investing in AI feature upgrades from incumbent vendors without interrogating whether those features are architecturally sound or merely cosmetically impressive. A CRM that can generate a sales email via a generative AI button is not the same as a CRM whose data model and agent framework can autonomously manage pipeline health, flag at-risk accounts, and trigger multi-channel re-engagement without human initiation. The difference matters when you are trying to scale operations without scaling headcount.
The second risk is under-estimating the switching costs of moving away from entrenched platforms — and therefore delaying the strategic conversation until competitive pressure forces a reactive decision. Organisations that begin evaluating their software estate through an agentic lens now — asking not 'how many seats do we need?' but 'what outcomes do we need software to own end-to-end?' — will be in a materially stronger position in 18 to 24 months. That evaluation should include an honest assessment of where incumbent vendors are genuinely investing in architectural change versus where they are repackaging existing functionality with a generative AI wrapper.
The shift from seat-based to outcome-based software is not a future trend to monitor — it is a present-tense disruption that is already influencing procurement decisions, vendor roadmaps, and competitive dynamics across the UK enterprise market. The organisations that will navigate it best are not necessarily those with the largest technology budgets; they are those willing to ask harder questions about what their software estate is actually delivering, and whether the platforms they depend on are structurally capable of evolving fast enough.
If your organisation is mid-way through a major SaaS renewal cycle, or if you are beginning to sense that the AI capabilities your incumbent vendors are promoting do not quite match what you are seeing in practice, it is worth conducting a structured review before those contracts lock in for another three years. The gap between what AI-native platforms can deliver today and what retrofitted incumbents can credibly promise is widening, not narrowing. Understanding where that gap sits within your own stack is the most valuable piece of strategic intelligence you can act on right now.
What does 'outcome-based pricing' actually mean in SaaS, and how is it different from consumption-based pricing?
Outcome-based pricing ties the cost of software directly to a measurable business result — a lead qualified, a bug resolved, a research brief completed — rather than to usage volume or time spent. Consumption-based pricing, by contrast, charges for compute or API calls without guaranteeing a specific result. The distinction matters because outcome-based models align vendor incentives with customer value in a way that consumption models do not always achieve.
Is Salesforce's Agentforce genuinely agentic, or is it largely a marketing repositioning?
Agentforce represents a genuine engineering effort by Salesforce to introduce autonomous agent behaviour into its platform, and some capabilities — particularly around case resolution and sales task automation — are functionally useful. However, independent assessments suggest that the underlying data model constraints of the Salesforce platform limit the depth and fluidity of agent behaviour compared to tools built on agentic architectures from inception. It is best evaluated through a proof-of-concept against your specific workflows rather than accepted at face value.
Which UK sectors are seeing the fastest adoption of AI-native SaaS alternatives?
Professional services, financial services, and technology companies are leading adoption, largely because their core workflows — research, analysis, client communication, and code production — map well to current AI agent capabilities. Legal and accountancy firms in particular are exploring AI-native tools for document review, compliance checking, and client reporting, often as point solutions running alongside incumbent platforms before broader transitions are considered.
How should we evaluate whether an AI feature in our existing SaaS platform is architecturally genuine or cosmetic?
Ask the vendor three specific questions: whether the AI operates on live, contextual data or on snapshots; whether it can trigger multi-step actions autonomously without human confirmation at each step; and whether it maintains memory or context across separate sessions. If the answers are vague or the demos rely on highly curated data sets, the capability is likely a wrapper around a third-party model rather than a deeply integrated agent. Request a technical architecture briefing, not just a product demo.
What are the main risks of switching from an established platform like HubSpot to an AI-native alternative?
The primary risks are data migration complexity, loss of historical reporting continuity, and integration disruption with adjacent tools. AI-native platforms are often less mature in their ecosystem integrations and may lack the breadth of native connectors that established platforms have built over many years. A phased approach — running the new platform in parallel for a defined workflow before full transition — significantly reduces these risks and provides genuine comparative performance data.
How do agentic AI tools handle data privacy and UK GDPR compliance?
This varies significantly by vendor and is a critical due diligence area. Key questions include where data is processed and stored, whether the model is trained on customer data, and whether the vendor holds UK or EU data residency options. Many AI-native tools are US-headquartered and their default configurations may not meet UK GDPR requirements without explicit contractual and technical controls. Engage your data protection officer early in any evaluation process.
What is the realistic timeline for outcome-based pricing to become the dominant SaaS model?
Most analysts expect a transitional period of three to five years in which seat-based and outcome-based models coexist, with outcome-based pricing becoming dominant in AI-intensive workflows first. The transition will be uneven: high-volume, well-defined task categories like code generation and lead qualification will shift faster, while complex collaborative software — project management, document editing — will retain seat-like models longer. UK procurement teams should expect to manage hybrid pricing structures across their stacks for the foreseeable future.
Can smaller UK organisations realistically adopt AI-native SaaS tools, or are they primarily suited to enterprise scale?
Many AI-native tools are priced accessibly for SMEs, and the outcome-based model can actually favour smaller organisations because they pay proportionally to usage rather than committing to large seat counts upfront. The greater challenge for smaller teams is typically the implementation resource required to configure agents effectively and integrate them with existing systems. Engaging a specialist implementation partner for the initial configuration phase significantly reduces time-to-value.
How should we handle internal resistance from teams who rely heavily on incumbent platforms?
Resistance is usually rooted in workflow familiarity and concerns about retraining investment rather than attachment to specific software. Framing the evaluation around outcome improvement rather than cost reduction tends to generate more constructive engagement — most practitioners want tools that help them do their jobs better. Involving key users in proof-of-concept design, rather than presenting a concluded decision, also materially reduces adoption friction.
What role does bespoke software development play in an AI-native SaaS transition?
Bespoke development becomes particularly valuable at the orchestration layer — building the glue logic that connects AI-native point solutions to each other and to legacy systems that cannot be easily replaced. It is also relevant where no off-the-shelf AI-native tool adequately addresses a specific vertical workflow, making a purpose-built agent a more cost-effective and controllable option than adapting a generic platform. A well-scoped bespoke component can extend the value of commercial AI-native tools significantly.
Get in touch today
Book a call at a time to suit you, or fill out our enquiry form or get in touch using the contact details below