When the Capability Becomes the Unit of Software

Ask someone what software their sales organisation uses and the answer will usually be a list of applications. Salesforce. Gong. Outreach. Clari. ZoomInfo.

Each name represents a category, a budget, a set of workflows and usually a distinct interface through which people perform part of their work.

Ask the same person what their sales organisation actually does and the answer looks very different. Find good accounts. Understand them. Identify the right people. Prepare for meetings. Progress opportunities. Assess deal risk. Review pipeline. Forecast revenue. Coach reps.

These are capabilities.

For most of the software era, the distinction did not matter very much. Work had to happen somewhere, and the application became the natural container for the data, logic, workflow and interface required to perform it.

AI starts to loosen that relationship. A Deal Risk capability may need CRM data, customer conversations, email, product usage, the company’s qualification methodology, historical outcomes and a manager’s current objectives.

None of those things necessarily belong to the same application. The work crosses the stack because the reality of the deal crosses the stack.

This leads to a question I think will become increasingly important in enterprise software: What happens when the application is no longer the natural boundary around the work?

Why the application became the unit of software

The application is such a familiar idea that it is easy to treat it as inevitable. It isn’t.

It is an architectural response to a set of technological and economic constraints. Software needed somewhere to store its data. It needed business logic that defined what users could do. It needed workflows that moved information through a process. And it needed an interface through which humans could operate those workflows.

Bundling these things together made sense. A CRM contained customer records, sales process, workflow automation, reporting and the screens through which salespeople interacted with all of them.

A support platform did the same for tickets. A marketing automation platform did it for campaigns. A customer success platform did it for accounts and health.

As cloud software made applications cheaper to build and distribute, specialisation accelerated. Instead of one enterprise system attempting to model the whole company, businesses could buy increasingly sophisticated applications for increasingly specific functions.

This created enormous value. A specialised conversation intelligence company could build a better model of sales conversations than a general CRM vendor. A specialised sales engagement company could build better sequencing workflows. A specialised data provider could build better account and contact intelligence.

The application became both a technical architecture and an economic unit. Companies bought applications. Software vendors sold applications. Teams learned applications. Categories formed around applications.

And work gradually adapted to their boundaries.

The company does not have application boundaries

The problem is that commercial reality is not organised the same way.

A deal does not know that one part of itself belongs in Salesforce and another belongs in Gong. A customer does not separate its support relationship from its commercial relationship because the company bought different software for each. An account does not distinguish between a leadership change, product usage, marketing engagement and previous sales conversations.

Those boundaries belong to the software architecture. Not the underlying system being represented.

Humans have historically solved this mismatch. When an AE prepares for an important meeting, they move between applications. When a manager assesses a deal, they combine evidence from different systems. When RevOps builds a forecast process, it reconciles multiple representations of commercial reality.

The human crosses the application boundary because the work requires it. This is another expression of the missing operating layer.

Applications specialised. People recomposed.

AI-native systems make it possible for the software to participate much more deeply in that recomposition.

Start with the work

Consider something as ordinary as Meeting Preparation. Where does Meeting Preparation belong?

CRM? Conversation intelligence? Calendar? Email? A sales enablement platform?

The question feels strangely difficult because Meeting Preparation is not naturally an application. It is a capability.

To prepare well, the organisation may need to understand: who is attending, what happened previously, the current state of the account or opportunity, outstanding commitments, relevant product information, stakeholder relationships, the company’s objectives, likely objections, competitive context, and what a successful outcome from the meeting would look like.

The capability requires context from several systems and organisational knowledge that may live in none of them.

Historically, the salesperson performed the integration. They opened the relevant applications and constructed the briefing mentally.

A new architecture can construct the capability directly. Live State provides the current commercial context. Memory provides the organisation’s relevant knowledge and judgement. Skills define how good Meeting Preparation should be performed. Agents can coordinate the work and use tools where required.

The result can appear wherever the person needs it. Slack. CRM. Email. Calendar. A workspace. A generated briefing.

The capability exists independently of any single application boundary. That is the important change.

Capabilities are recognisable work

We need to be precise about the term. A capability is not every action a system can perform.

“Search Salesforce” is a tool action. “Summarise transcript” is a task. “Call an API” is a function.

A capability is a recognisable piece of organisational work that produces a useful outcome. For Prospecting: Account Sourcing. Account Research. Account Prioritisation. Contact Sourcing. Contact Research. Message Creation. Sequence Planning.

For Sales: Meeting Preparation. Meeting Follow-up. Deal Assessment. Deal Strategy. Pipeline Review. Forecasting. Coaching.

For Customer Success: Customer Briefing. Health Assessment. Risk Detection. Renewal Planning. Expansion Identification.

These names matter because people already understand the work.

A VP Sales does not wake up wanting to “invoke an agent”. They need to understand which deals require attention.

A manager does not want another AI workflow. They need to prepare a pipeline review.

An SDR does not care how many models and tools ran behind the scenes. They need to know which accounts are worth pursuing and why.

Capabilities create a useful abstraction between the complexity of the system and the outcome the organisation needs.

The capability has an internal architecture

A capability may look simple to the person using it. Behind it, several primitives interact.

Take Deal Assessment. The system needs the current Live State of the opportunity.

Who is involved? What has changed? What commitments exist? What evidence supports qualification? What remains uncertain?

It needs Memory. What does this company consider a qualified opportunity? What constitutes a real champion? Which risks matter? What does the sales process require at this stage?

It needs a Skill. How should a deal be assessed? Which evidence should be considered? How should conflicting evidence be handled? What should the resulting assessment contain?

It may need tools. CRM. Conversation data. Email. Product usage. External information.

It may need agents to orchestrate these components. And the resulting judgement should create a Decision Trace so the organisation can later understand why the assessment was made and whether it proved useful.

The capability is therefore not synonymous with any individual primitive. It is the composition.

We can represent it roughly as: Capability = State + Memory + Skill + Tools + Orchestration + Governance

And when the capability makes a consequential judgement: Capability → Decision Trace → Outcome → Learning

This is why I think capability is a more useful unit for thinking about AI-native work than agent.

The agent describes part of the mechanism. The capability describes what the organisation can do.

The difference between a workflow and a capability

At first, this can sound like another name for workflow automation. There is an important difference.

Traditional workflows are generally defined around predetermined sequences. When X happens, do Y. Move this record. Send this notification. Create this task. Request this approval.

These workflows are powerful precisely because the path is known in advance. Capabilities operate in environments where the appropriate path depends on context.

Meeting Preparation for a first discovery conversation is different from Meeting Preparation for a late-stage security discussion. Deal Assessment for a £20,000 transactional sale is different from Deal Assessment for a seven-figure enterprise opportunity. Customer Risk may require different evidence depending on the product, customer segment, lifecycle stage and commercial history.

The objective remains stable. The path can vary.

That is where intelligence matters. A capability combines a defined organisational outcome with the ability to interpret the state in which the work occurs.

This makes it more adaptable than a workflow without making it completely unconstrained. The organisation still defines what good looks like. It still provides knowledge. It still defines methods. It still establishes permissions and governance.

Intelligence operates inside that structure.

Capabilities can compose

Once work is represented as capabilities, another property becomes important. Capabilities can build on other capabilities.

Account Research can inform Account Prioritisation. Account Prioritisation can inform Contact Sourcing. Contact Research can inform Message Creation. Meeting Preparation can use Account Research and Deal Assessment. Deal Assessment can inform Pipeline Review. Pipeline Review can inform Forecasting. Customer Health can inform Renewal Planning.

This begins to look less like a collection of independent applications and more like a capability graph.

Outputs from one capability become context for another. Shared State prevents each capability from reconstructing the same commercial reality independently. Shared Memory prevents each capability from inventing its own interpretation of company strategy.

Shared Skills give the organisation reusable methods. Decision Traces allow the organisation to observe how capabilities interact and which decisions produce useful outcomes.

The system becomes compositional. This is important because companies themselves are compositional.

A forecast depends on deals. Deals depend on meetings, stakeholders and commercial decisions. Prospecting creates opportunities. Opportunities become customers. Customer outcomes influence future positioning and targeting.

The application stack fragmented these relationships because software needed bounded domains. A capability graph can begin representing more of the relationships between the work itself.

The interface separates from the capability

The application model also created a close relationship between capability and interface. To use CRM functionality, open CRM. To use conversation intelligence, open the conversation platform. To use sales engagement, open the sales engagement platform.

The application owns both the capability and the surface. AI starts separating them.

A rep might receive Meeting Preparation in Slack. Ask a question about the account through chat. Inspect Deal State in CRM. Receive a risk alert by email. Review pipeline through a generated artefact. Approve an agent action from Teams.

The same underlying capability can appear through multiple surfaces. This changes how we should think about UX.

The objective is no longer necessarily to bring every user into one application. It may be to bring the relevant capability into the context where the user already works.

This is particularly important in GTM because the organisation contains very different roles. RevOps may need a workspace for building and governing the system. A manager may primarily consume briefings and exception views. An AE may interact through CRM, Slack and meeting workflows. A CRO may want a continuously maintained representation of commercial state rather than another operational interface.

One operating system. Different surfaces.

The capability persists underneath them.

The data layer separates too

The same unbundling occurs beneath the capability. Traditional SaaS applications often gained power from owning their own data model.

The data and application reinforced each other. More customer records made CRM more useful. More conversations made conversation intelligence more useful. More engagement activity made sales engagement more useful.

That relationship does not disappear. But an AI-native capability often needs to reason across multiple authoritative systems.

This means the operating layer does not necessarily need to replace every system of record. It needs to understand how those systems relate.

Salesforce can remain authoritative for opportunity fields. Gong can remain an important source of conversational evidence. A product database can remain authoritative for usage. A billing system can remain authoritative for contracts.

The capability operates across them. This suggests a different architecture:

Systems of record provide evidence. The operating layer maintains context and organisational logic. Capabilities perform work. Surfaces deliver the result.

These layers can be supplied by different systems. The SaaS application bundled them. AI-native architecture can increasingly separate them.

What happens to SaaS?

The temptation at this point is to conclude that applications disappear. I don’t think that follows.

Some applications become more important. Systems that own authoritative data, critical transactions, specialised infrastructure or regulated workflows can remain deeply valuable.

A billing system still needs to bill. A CRM may remain the authoritative store for important commercial records. A support platform still needs to route and manage support interactions.

The more interesting question is where incremental value accrues.

In the SaaS era, a vendor could own a workflow by owning the interface through which a person performed it. If an AI-native capability can operate across systems and appear through different surfaces, interface ownership becomes less synonymous with workflow ownership.

Similarly, specialised application logic may increasingly become accessible as tools to a broader operating layer.

The application does not necessarily disappear. Its position in the value chain changes.

Some systems become sources. Some become tools. Some remain systems of record. Some become surfaces.

Some continue to bundle all of these things because the bundle remains economically useful. The architecture becomes more fluid.

This is why I am sceptical of both extremes in the current AI software debate.

“AI is just another feature” underestimates the architectural change. “Agents replace SaaS” underestimates why applications exist and the durable value many of them provide.

The more interesting possibility sits between them. The application stops being the only meaningful boundary around software value.

This changes how software categories form

Software categories have historically mapped closely to applications. CRM. Sales Engagement. Conversation Intelligence. Revenue Intelligence. Customer Success.

Each category describes a software market and, indirectly, a boundary around a set of workflows. Capabilities create different boundaries.

Meeting Preparation overlaps CRM, conversation intelligence, email, calendar, enablement and account research. Deal Assessment overlaps CRM, conversation intelligence, forecasting, methodology and product usage. Account Prioritisation overlaps data providers, intent, CRM, marketing engagement and company strategy.

If customers increasingly buy or build around outcomes rather than application boundaries, category lines become less stable.

This does not mean “one platform replaces everything”. It may mean the opposite.

Specialised infrastructure can continue underneath while the user experiences a more coherent capability above it. The market can simultaneously become more modular at the infrastructure layer and more integrated at the operating layer.

That is an important distinction.

Capabilities change how AI is evaluated

There is another benefit to this abstraction. AI systems are often evaluated at the task level.

Was the summary good? Was the email relevant? Did the model correctly classify the call?

These evaluations matter. But organisations ultimately care about capabilities.

Does Account Prioritisation identify better opportunities? Does Deal Assessment recognise risk earlier? Does Meeting Preparation improve customer conversations? Does Pipeline Review allocate management attention more effectively? Does Renewal Planning reduce churn?

This moves evaluation closer to business outcomes. A capability can contain many model calls and tool actions that are individually imperfect while still producing a valuable organisational result.

Conversely, every component can appear impressive in isolation while the overall capability performs poorly.

The capability therefore gives us a better unit for connecting AI performance to organisational performance.

And because the capability produces Decision Traces and outcomes, it can improve. The system can identify which part of the composition failed.

Was State incomplete? Was Memory wrong? Was the Skill weak? Did the agent choose the wrong tool? Was the output correct but the action poorly timed?

The capability becomes both the unit of work and a unit of learning.

Capabilities can become organisational assets

This creates an interesting economic consequence. Consider two companies using the same foundation model.

Both have access to similar CRM systems. Both can connect the same tools.

Why might one company’s AI-native GTM system become substantially better than the other’s? Because the model is only one input.

One company may have a richer representation of commercial State. Better Memory. More developed Skills. More useful Decision Traces. More historical outcomes. Better governance.

And capabilities that have been refined through repeated use. The advantage accumulates at the level of the operating system.

A Deal Assessment capability that has been applied to thousands of opportunities, reviewed by experienced managers and improved against actual outcomes is not the same asset as a generic prompt asking a frontier model whether a deal looks healthy.

The foundation model may commoditise. The organisational capability does not necessarily commoditise with it.

This is where AI-native software starts becoming interesting strategically. The company’s advantage can increasingly reside in the system around the intelligence, not simply access to intelligence itself.

RevOps moves up an abstraction layer

This also changes the role of the people building commercial systems. Today, a RevOps leader often thinks in applications and workflows.

Which CRM fields do we need? Which automation should fire? How should the sequence work? Which dashboard should we build? Which application owns this process?

Those questions remain relevant. But capabilities introduce another level.

What does the organisation need to be capable of doing?

What State does that capability require? Which organisational Memory should it use? Which Skills define how the work is performed? Which tools should be available? Where can an agent act? Where should a human intervene? How should the result be surfaced?

How will we know whether the capability is improving? This is a movement from configuring software toward architecting organisational capability.

The application becomes one component in the design rather than the starting point. That is a significantly different RevOps role.

A new way to map the organisation

There is a practical implication here that I think will become increasingly useful. Instead of beginning an AI transformation by mapping the software stack, map the capabilities of the organisation.

What does Prospecting need to be capable of doing? What does Sales need to be capable of doing? What does Customer Success need to be capable of doing?

Then, for each capability: What State is required? Which Memory informs it? Which Skills perform it? Which tools are required? Which decisions are involved? Where should autonomy sit? Which surfaces need the output? Which outcomes determine whether it worked?

This creates a very different transformation programme from buying copilots application by application. It starts with the operating model.

Technology follows.

That is how I increasingly think companies should approach AI-native GTM. Not: Where can we add AI to our stack?

But: What does our organisation need to be capable of doing, and what architecture would allow those capabilities to improve continuously?

From software stack to capability graph

The software stack will not disappear. But it may stop being the most useful representation of how an AI-native company operates.

A stack tells us which applications the company owns. A capability graph tells us what the company can do.

It shows how Account Research informs Prioritisation. How Meeting Preparation connects to Deal State. How Deal Assessment informs Pipeline Review. How customer outcomes update future judgement.

It connects work that traditional application boundaries separated. And underneath that graph sits a common architecture.

Live State represents the changing commercial world. Memory represents what the organisation knows and believes about that world. Skills encode methods for performing work. Agents orchestrate. Tools connect external systems. Decision Traces preserve important judgements. Outcomes create the possibility of improvement.

The result is not an application with AI added. It is an operating system composed of organisational capabilities.

For most of the software era, companies asked which application should own a workflow. The more interesting question now is which capabilities the organisation should possess, how those capabilities should be constructed and how they should improve.

That changes the unit we design around. It may eventually change the unit we buy around.

And it changes where the enduring value of enterprise software can accumulate.

The application organised the SaaS era. The capability may organise much more of the AI-native one.