The AI-Native Operating Model

Over the last few years, we started with a relatively straightforward question: what does a GTM organisation look like when AI becomes native to how it operates?

The obvious answers were around productivity. Research accounts faster. Write better emails. Summarise calls. Update CRM automatically. Prepare forecasts. Give every rep an assistant and every team a collection of agents. All of those things are happening. Increasingly, they will become expected.

But the further we followed the question, the less it looked like a productivity problem. The more interesting change was underneath the work.

For most of the software era, companies have digitised records, workflows and communication while leaving much of the understanding, judgement, coordination and learning required to operate the company inside people. AI changes that division of labour.

It means we can start asking a different question. Not simply what work can AI perform, but what parts of the operating model can now exist inside the system itself?

GTM is an unusually useful place to explore that question. Commercial organisations contain large amounts of changing information, unstructured conversations, distributed knowledge, repeated processes and judgement-heavy decisions. They also produce relatively observable outcomes.

An account changes. A customer says something important. A deal deteriorates. A competitor appears. A champion leaves. A prospect responds. A customer churns. The organisation needs to notice the change, understand what it means, decide what to do and coordinate a response. Then, ideally, it learns.

Once you look at GTM this way, the transition from SaaS to AI-native systems starts to look much larger than adding intelligence to existing software. It starts to look like a new operating model.

The operating model we inherited

Every generation of enterprise technology has moved another part of the company into software. Databases digitised records. ERP systems encoded core business processes. CRM created structured representations of customers, opportunities and activity. Cloud software made specialised applications inexpensive enough to spread across almost every function.

The modern GTM stack was built during this period. Salesforce could represent an opportunity. Outreach could execute a sequence. Gong could capture a conversation. Zendesk could represent a support case. Gainsight could organise customer activity. BI tools could aggregate the resulting data into reports.

This architecture was enormously productive, and it made sense given the capabilities of the technology. Traditional software was very good at storing structured information, applying explicit rules and executing predetermined workflows. It was much less capable of interpreting ambiguous language, combining incomplete evidence or exercising judgement when the correct answer depended on context.

Humans had the complementary capability.

A CRM could tell you that an opportunity was in Stage 3, worth £100,000 and expected to close this quarter. An experienced sales manager could listen to the latest conversation and realise that the supposed champion had become less engaged, procurement had arrived unexpectedly and the customer’s language around timing had subtly changed.

The database contained facts.

The manager understood what they meant.

That division of labour became embedded in the architecture of enterprise software. Applications maintained increasingly sophisticated representations of individual parts of the business, while people connected those representations into an understanding of the whole. The application became the dominant unit of software. The human became the operating layer between them.

The hidden coordination layer

You can see this architecture on almost any Monday morning. An AE preparing for a pipeline review opens Salesforce. The opportunity is there, along with its stage, value, close date, activity and whatever qualification fields have been completed.

But those fields rarely contain enough information to understand what is actually happening. So the AE opens Gong and revisits the latest customer conversation. They search Slack for the discussion that followed it. They check email for an outstanding commitment and perhaps open a pricing document or notes from an earlier meeting.

Then they combine those fragments with information that may exist nowhere except their own memory. The champion still seems supportive, but hasn’t brought the economic buyer into the process. Security has introduced another review. The implementation date remains vague. A competitor appeared in the last conversation. The customer has missed a commitment.

The close date in Salesforce hasn’t changed.

The AE has done something more important than prepare for a meeting. They have reconstructed the current state of the deal. The manager repeats some version of this across the team. RevOps does it across systems. Eventually the CRO receives a compressed representation through a forecast, dashboard or management conversation.

The same mechanism exists elsewhere. An SDR assembles company information, leadership changes, market signals, previous engagement and an understanding of the ICP before deciding whether an account deserves attention. A customer success manager combines product usage, support activity, sentiment, stakeholder behaviour and commercial history before deciding whether an account is healthy. A sales manager combines calls, activity, results and previous coaching conversations before deciding how to help a rep.

The software contains pieces of the evidence. People continuously turn those pieces into context. They find information, resolve contradictions, remember previous decisions, interpret changes, apply company-specific judgement and coordinate the next action. When reality changes, they do it again.

This is easy to dismiss as administrative work. I think it is more fundamental than that.

Human coordination is part of the architecture of the modern software company.

Forecast meetings, pipeline reviews, one-to-ones, CRM hygiene, internal messages, dashboards and countless spreadsheets are not merely habits surrounding the software. Many of them are mechanisms through which an organisation reconstructs state, transfers context and reconciles different interpretations of reality.

For most of the software era, this was unavoidable. The interesting question is what happens when it isn’t.

AI is initially being added to the old architecture

The first wave of enterprise AI has largely appeared at the points where humans already perform work. Write this email. Summarise this call. Research this company. Update this opportunity. Generate this sequence. Explain this dashboard.

These capabilities are useful, and models will continue to make them dramatically better. But there is an important distinction between making work faster and changing the system through which the work happens.

Imagine an SDR previously spent twenty minutes assembling the context required to research an account and write a relevant email. An AI assistant can reduce part of that process to seconds. That is valuable.

But if the assistant still needs someone to determine which account matters, assemble the relevant context, decide which signals are meaningful, provide the company’s positioning and judge whether the resulting action is appropriate, much of the underlying operating model remains unchanged. The same applies to sales.

An AI assistant can produce an excellent summary of a customer conversation while the organisation still lacks a maintained understanding of the deal. It can write a forecast narrative while the inputs depend on twenty salespeople reconstructing their opportunities beforehand. This creates a distinction that I think matters:

A company can become extensively AI-assisted without becoming meaningfully more intelligent as an organisation.

Individual production increases while organisational coordination remains largely human.

There is even a scenario in which the problem becomes worse. When generating research, content, analysis and automated actions becomes inexpensive, companies can create far more output than people can sensibly evaluate. More agents acting on fragmented context do not necessarily create a coherent system. They can create faster fragmentation.

The constraint moves.

Producing the next piece of work matters less. Maintaining the right understanding of reality, making that understanding available to every relevant decision and learning from what happens next matters more. This is where the architecture begins to change.

State becomes a primitive

Before an intelligent system can decide what to do, it needs some representation of what is true. This sounds obvious, but it is different from having access to data.

Consider a sales opportunity. Its CRM record might contain the company, contacts, stage, amount, expected close date, activity and qualification fields. Gong contains conversations. Email contains commitments and correspondence. Slack contains internal judgement. Product systems may contain usage. Billing or legal systems contain another part of the commercial relationship.

Those are sources of evidence. They are not, individually or collectively, the state of the deal. The state is the system’s maintained representation of what those pieces of evidence currently mean together.

We call this Live State.

A Live State for a deal might represent the stakeholders involved, the strength of the champion, evidence of an economic buyer, agreed outcomes, unresolved risks, competitive position, commitments, qualification confidence and the changes that have occurred since the previous interaction.

Some of that state is directly observed. A new stakeholder attended the meeting. A security review was requested. The customer moved the proposed implementation date.

Other state is derived. Champion strength is deteriorating. Forecast confidence has fallen. Competitive risk has increased. The opportunity no longer satisfies part of the organisation’s qualification criteria.

That distinction matters because commercial organisations operate on both facts and interpretations of facts. A useful system therefore needs to maintain not only what it has observed, but what it currently believes those observations mean, the evidence supporting that interpretation and, where appropriate, its uncertainty.

And state is temporal. Commercial reality is constantly changing. A new conversation happens. Someone leaves the company. A support issue escalates. Usage falls. A prospect visits the pricing page. A commitment is missed.

The important question is often not simply: What is the state?

It is: What changed?

A change in state can trigger a new interpretation, which can change the appropriate action. This creates another useful consequence. Once a system can continuously understand changes in commercial state, it can help determine where scarce human attention should go.

A manager does not need to inspect every deal every morning. They need to know which deals changed in a way that warrants their judgement. A CRO does not need another dashboard containing every pipeline metric. They need to know which changes materially affect the company’s commercial position. An SDR does not need another database of 10,000 accounts. They need to know which accounts became meaningfully more relevant and why.

Maintaining state and allocating attention are closely connected. This is a very different role for software.

State is not enough

A perfect representation of reality still does not tell an organisation what to do. Two companies can observe exactly the same account and reach different conclusions.

One considers a 500-person software company an ideal customer. Another doesn’t. One sales organisation considers a verbal supporter a champion. Another requires evidence that the person can mobilise the organisation internally. One company treats a particular usage pattern as healthy. Another knows from experience that it frequently precedes churn.

This difference is judgement. Every company contains an enormous amount of it. It exists in strategy, positioning, ICP definitions, qualification methodologies, pricing principles, customer processes and competitive knowledge. It also exists less formally in the experience of founders, managers and high-performing employees.

Much of this knowledge has historically been difficult to operationalise consistently. We write documents. Create playbooks. Run training. Hold meetings. Coach employees. Build CRM validation rules. Create workflows. And rely on culture and management to carry the rest.

The result is inevitably uneven. Knowledge becomes stale. People interpret playbooks differently. Experienced employees develop judgement that never becomes explicit. New employees relearn lessons the company has already paid to discover.

AI-native systems make another transition possible. Organisational knowledge can increasingly become explicit, shared, executable and improvable.

We call this Memory.

Memory is not simply a collection of documents retrieved by a model. It is the accumulated context and operating judgement the system can apply when interpreting situations and performing work.

What does this company believe about its market? What constitutes a strong account? What does a real champion look like? How should we position against this competitor? Which evidence is required before we call a deal qualified? What have previous wins and losses taught us?

Once that judgement becomes available to the system, intelligence stops being generic. The system can reason from the way this particular organisation operates.

From knowledge to capability

Knowing how the organisation thinks still does not perform the work. Companies contain thousands of recurring activities that combine context and judgement into recognisable outcomes.

Research an account. Assess a deal. Prepare a pipeline review. Coach a rep. Plan a renewal. Investigate churn.

Today these activities are usually distributed across people, processes and applications. A person knows which tools to open, which information matters, which process to follow and what a good output looks like. We can increasingly encode those methods too.

We call them Skills.

A Skill describes how a particular piece of work should be performed using the organisation’s context and judgement. This leads to a more important concept: the capability.

Consider Deal Risk. Deal Risk is not an application and it should not necessarily be an agent.

It is something the organisation needs to be capable of doing reliably.

To assess deal risk, the system might combine the Live State of the opportunity, the company’s qualification Memory, historical outcomes, a Deal Risk Skill and access to relevant tools. It may use one agent or several. It may ask a human when uncertainty crosses a threshold.

The important thing from the organisation’s perspective is not how many agents ran. It is that the organisation possesses the capability to assess deal risk.

The same is true of Account Research, Pipeline Review, Forecasting, Renewal Planning or Rep Coaching. This suggests a more fundamental change in enterprise software.

For decades, software has largely been organised around applications. CRM, sales engagement, conversation intelligence, forecasting and customer success each became categories with their own data, workflows, logic and interfaces.

AI-native systems allow us to organise more of the operating model around capabilities instead.

Capabilities can cross application boundaries because the work itself crosses application boundaries. That may turn out to be one of the more consequential changes in enterprise software.

What agents are actually for

Agents are an important part of this architecture, but I think the current discussion sometimes gives them too much conceptual weight. An agent without persistent state, organisational knowledge or reliable capabilities is simply a more autonomous actor operating with incomplete context.

The useful question is not how many agents a company has. It is what those agents understand, what capabilities they can invoke, which tools they can use, what constraints they operate within and how the organisation knows whether their decisions were good.

Within an AI-native operating model, agents become coordinators and actors. An agent can observe a change in state, determine whether it matters, invoke an appropriate Skill, use external tools and either take action or involve a human.

That distinction also creates a more sensible model for autonomy. Not every commercial decision should be automated.

A system might autonomously update an account state, draft research or classify a routine interaction. It may recommend an action when confidence is lower. A strategically important negotiation might remain deeply human. The objective is not maximum autonomy.

It is to put intelligence and judgement at the right point in the system, with an appropriate relationship between machines and people.

The operating model in practice

Consider a simple prospecting event. A new CRO joins a target company.

In the traditional model, the signal enters a data provider. It may appear in CRM or a prospecting tool. A salesperson notices it, researches the company, checks previous engagement, considers whether the account fits the ICP, thinks about why a new CRO might matter and constructs an appropriate message.

With AI assistance, several of those steps happen faster. The research can be generated. The email can be written. The account can be enriched. But the structure of the process remains recognisable.

In an AI-native model, the event changes the state of an account the system already understands. The system knows the company, previous engagement, ICP, relevant personas, positioning and commercial history. It can interpret the leadership change against that context, determine whether the account has become more relevant and invoke the appropriate prospecting capability.

The resulting action may be automated or routed to a salesperson because their judgement or relationship matters. Either way, the organisation did not begin by reconstructing the account.

It began from maintained state. Now consider a sales deal.

A customer conversation introduces a new security requirement, the economic buyer becomes less engaged and implementation timing moves. The individual facts may exist across several systems. The operating model treats them as changes to the state of the opportunity.

Those changes can trigger a Deal Risk capability. The system applies the organisation’s qualification logic, compares the new evidence with what it previously believed, identifies where confidence has deteriorated and determines whether management attention is required.

The manager does not need to inspect every deal to discover the change. The system can bring the changed deal to the manager.

Customer success follows the same architecture. A customer’s product usage remains healthy, but executive engagement falls, several support issues remain unresolved and the original economic buyer leaves the company.

No individual signal necessarily means the account is at risk. Their relationship may.

A maintained customer state allows a Renewal Risk capability to interpret those changes together and apply the organisation’s knowledge of what historically matters. Prospecting, sales and customer success appear to be different software categories. At this level they start to look like different sets of capabilities operating on the same underlying architecture.

Decisions become observable

As more judgement moves into the system, another requirement becomes important. We need to know why.

Traditional enterprise software was largely deterministic. If a workflow updated a field because a rule evaluated to true, the causal path was relatively straightforward.

AI systems operate differently. They interpret evidence. They make probabilistic judgements. They choose between actions. And increasingly, they act.

An organisation therefore needs more than logs showing that an agent ran. It needs a record of the decision.

What did the system understand at that point in time? What evidence did it use? What did it believe? Which organisational judgement did it apply? What action did it choose? And what happened afterwards?

We call these Decision Traces.

This is partly an observability problem, but it becomes something larger as machines participate more deeply in operating the company. Decision Traces create the connection between action, governance and learning.

A manager can inspect why the system considered a deal risky. RevOps can understand why an account was prioritised. The organisation can identify where a recommendation depended on missing or weak evidence.

And, critically, an outcome can eventually be connected back to the state and judgement that produced it. That is how the loop begins to close.

From automation to learning

Most business software does not meaningfully improve because it performed more work. The hundredth CRM update does not make the system better at understanding the next opportunity. The thousandth workflow execution does not improve the workflow.

An AI-native operating model creates the possibility of something different. Suppose the system repeatedly identifies certain deals as healthy and those deals subsequently slip. There are several possible explanations.

Perhaps important evidence was missing from Live State. Perhaps the organisation’s qualification Memory is incomplete. Perhaps the Deal Risk Skill gives too little weight to a particular signal. Perhaps the agent lacks access to an important tool. Perhaps the underlying ontology does not represent a concept that experienced managers use intuitively.

Or perhaps the organisation itself has been wrong about what predicts a healthy deal. Decision Traces and outcomes allow those questions to become inspectable.

The important feedback loop is therefore not merely: AI performs work → human approves work.

It becomes: The organisation performs work → outcomes reveal where the operating model is weak → the system improves how future work is performed.

Memory can be updated. Skills can improve. Missing context can be identified. New tools can be connected. Repeated exceptions can become explicit operating logic. A capability the organisation repeatedly performs manually can be proposed for encoding.

At first, humans will govern much of this improvement. Over time, systems will increasingly be able to identify and propose their own upgrades. This is the point where AI-native architecture becomes compounding.

The application is no longer the whole system

This architecture does not make existing software disappear. Companies still need authoritative records. They need communication infrastructure, billing, support, product analytics, security and specialised systems. But the role of those applications begins to change.

The SaaS era bundled several forms of value inside the application. It stored the data. It contained the business logic. It executed the workflow. It provided the interface through which people performed the work.

An AI-native operating layer begins to separate those functions. Salesforce can remain an important system of record while a capability reasons across Salesforce, Gong, Slack, billing and support data.

Gong can remain an important source of conversational evidence without being the place where every sales decision happens. Agents can use applications as tools.

Users can consume capabilities through Slack, Teams, CRM, chat, briefings or new interfaces that have not yet become standard. The applications remain valuable.

But they increasingly participate in a broader system. This changes the question from:

Which application does this work belong in?

to: What capability does the organisation need, what context does it require, and where should the result appear?

That is a very different way to design enterprise software.

The organisation changes with the software

Software architecture and organisational architecture have always influenced each other. If the operating model changes, roles change with it. RevOps is perhaps the clearest example.

Modern RevOps teams spend a considerable amount of time making fragmented commercial systems behave like one coherent system. They administer applications, connect data, configure workflows, define process, create reporting and reconcile differences between how teams actually work and how software represents that work.

In an AI-native organisation, much of that responsibility moves upward in abstraction. RevOps becomes increasingly responsible for designing the commercial system itself.

What should the organisation know? How should commercial state be represented? Which judgement belongs in Memory? Which recurring work should become a Skill? Which capabilities should exist? Where can agents act autonomously? Where must humans remain involved? What should be traced? Which outcomes should improve the system?

This is closer to architecture than administration.

Managers change too. A meaningful part of management today involves information collection and reconciliation. What happened? Which deals changed? Why did the number move? Has the rep done the next step?

When the system maintains more of that state, managers can spend proportionally more time on judgement, coaching, exceptions, resource allocation and improving the operating system their team works within.

Reps experience the other side of the same transition. Less time reconstructing context, transferring information between applications and executing routine process. More time on high-value human interaction, novel situations, relationships, negotiation and decisions where uncertainty remains meaningful.

Leaders move from consuming periodically reconstructed representations of the organisation towards inspecting a more continuously maintained commercial state. The goal is not to remove humans from GTM. It is to stop requiring humans to be the middleware that makes the GTM stack coherent.

The economics are larger than productivity

The easiest AI business case to understand is production cost. A task took an hour. Now it takes ten minutes.

That matters, but I suspect it captures only part of the economic change. Companies also incur enormous coordination costs.

People find information, attend status meetings, reconcile systems, transfer context, explain previous decisions, chase updates and rebuild understanding after handoffs. There is also decision latency: the time between reality changing and the organisation noticing, interpreting and responding to the change.

A deal deteriorates on Tuesday. The manager discovers it during Friday’s pipeline review. A customer’s behaviour changes this month. The risk becomes visible during the quarterly business review. An ideal prospect becomes relevant today. Someone researches them three weeks later.

Maintained state reduces that latency. There is variance too.

Two salespeople interpret the same qualification criteria differently. Two managers identify risk differently. Two CSMs respond differently to the same customer pattern. Some human variance is valuable. Novel situations require judgement.

But much of it is simply the consequence of company knowledge being unevenly distributed. Shared Memory and executable Skills allow organisations to reduce unnecessary variance while escalating situations where human judgement creates value.

And finally there is the learning rate. If every commercial outcome creates evidence that improves how future work is performed, the economic effect is no longer limited to doing today’s work more cheaply.

The organisation is accumulating an asset.

The operating model becomes an asset

Companies already understand that their data has value. The more interesting asset may be the accumulated representation of how the company knows how to operate.

Its understanding of its market. Its interpretation of customers. Its definitions of quality. Its commercial judgement. Its methods for performing recurring work. Its history of decisions. The relationship between those decisions and their outcomes.

Today much of that asset exists implicitly. It is distributed between employees, documents, applications, workflows and organisational habits. It degrades when people leave and often has to be taught repeatedly as companies grow.

An AI-native operating model makes more of it explicit and executable. That creates an unusual feedback loop.

Better State improves decisions. Better decisions produce better actions. Actions create traces. Outcomes improve Memory and Skills. Better Memory and Skills improve future capabilities. Those capabilities produce more outcomes from which the organisation can learn.

The system becomes more valuable not simply because more people use it, but because the organisation becomes better represented inside it. Experience starts becoming infrastructure.

A maturity curve

This transition will not happen at once. Most organisations today remain predominantly SaaS-native. Applications store evidence and execute workflows while people reconstruct context, apply judgement and coordinate action. The next stage is AI-assisted. Models accelerate individual work within that architecture. Research, writing, summarisation, analysis and administration become dramatically faster.

The more significant transition is AI-native. The system begins maintaining commercial state. Organisational knowledge becomes executable. Capabilities operate from shared context. Agents coordinate action across tools. Decisions become observable and outcomes feed back into the system.

And beyond that is a fourth stage we are only beginning to explore. The self-upgrading organisation.

Here the system does not simply execute the operating model. It increasingly observes where that operating model is deficient.

It identifies missing context. Weak Skills. Repeated exceptions. Contradictory Memory. Missing tools. Capabilities the organisation repeatedly performs but has never encoded.

It can recommend improvements and, within appropriate governance, eventually make some of those improvements itself. The progression is therefore not simply from less AI to more AI. It is a movement from software supporting human coordination, through AI accelerating human coordination, towards systems assuming more responsibility for maintaining and improving the operating model itself.

The company as a learning system

This brings us back to the original question. What does a GTM organisation look like when AI becomes native to how it operates? Increasingly, I think the answer is not a conventional software stack with more intelligent features.

It looks like a system. It maintains a representation of commercial reality. It understands the objectives the organisation is trying to achieve. It contains accumulated knowledge and judgement. It possesses capabilities for performing recognisable work. It coordinates those capabilities through agents and tools. It preserves traces of important decisions. It observes outcomes. And it uses those outcomes to improve how the system operates.

In other words:

State → Judgement → Capability → Action → Trace → Outcome → Upgrade.

GTM is where we are building and observing this model today. But there is little about the underlying loop that is inherently limited to sales or customer success.

Companies themselves sense changes in their environment, interpret those changes, make decisions, coordinate action and learn from the consequences.

Historically, software participated heavily at the edges of that loop. It recorded what happened and executed processes that people had already defined. Humans carried much of the state, interpretation, judgement and learning required to connect everything together.

AI allows software to move further into the loop. That is why I think the distinction between model intelligence and organisational intelligence will become increasingly important.

Giving every employee access to a highly capable model does not automatically create an intelligent organisation. The organisation still needs a shared representation of reality, accumulated judgement, reliable capabilities, governance and feedback loops through which experience can improve future decisions.

The interesting frontier is therefore not simply more capable models or more autonomous agents. It is the architecture that turns intelligence into organisational capability.

We spent the software era progressively digitising the records, processes and work of the company. We are now beginning to encode something deeper: how the company understands its environment, how it decides what matters, how it acts and how it learns.

That is the AI-native operating model. And we are only beginning to discover what happens when the system itself can improve.