The Missing Operating Layer

Most modern companies appear, from the outside, to run on software. Customers live in CRM. Conversations are captured in Gong. Marketing activity sits across automation and analytics platforms. Product usage flows into data warehouses. Customer issues live in support systems. Revenue appears in billing platforms. Internal decisions move through Slack, email and meetings.

Almost every important part of the company leaves a digital trace somewhere. Yet ask a simple question such as “What is actually happening with this deal?” and something interesting happens.

The answer rarely exists.

Pieces of it exist.

Salesforce knows the opportunity is in Stage 3. Gong knows what the customer said on Tuesday. Slack contains the concern raised afterwards. Email contains the commitment the buyer made. A product system may know whether the account is actually using the product. The AE remembers something that never made it into any system at all.

Someone has to assemble these fragments, decide which ones matter and turn them into a current interpretation of reality. We usually describe this as work.

Preparing for the pipeline meeting. Researching the account. Updating the forecast. Reviewing the customer. Getting a manager up to speed. I think it is more useful to see it as part of the architecture.

The software contains evidence. The organisation relies on people to continuously reconstruct what that evidence means. That is the missing operating layer.

The architecture underneath the software stack

It helps to understand why we ended up here. Enterprise software has historically been very good at representing bounded parts of a company.

A CRM represents accounts, contacts and opportunities. A support platform represents tickets. A billing system represents contracts and payments. A conversation intelligence platform represents calls. A sales engagement platform represents sequences and activity. Each application creates a useful model of its domain.

Over the SaaS era, we created more of these models and made them increasingly specialised. The average commercial organisation moved from a small number of large systems toward a stack of applications for almost every function and workflow. This was rational.

Traditional software worked best when information could be represented as structured objects and behaviour could be expressed through explicit rules. The more clearly a domain could be bounded, the easier it became to build specialised software around it.

Humans were good at almost exactly the things the software was not. We could move between domains. Interpret ambiguous language. Remember history. Combine weak signals. Understand exceptions. Decide that one fact mattered more than another. Carry context from one conversation into the next.

So a division of labour emerged. Software became responsible for maintaining increasingly sophisticated records of the company. People became responsible for maintaining coherence between them.

That second responsibility rarely appeared on an architecture diagram. It became part of the organisation instead.

Watch a company reconstruct itself

The pattern becomes easier to see when you watch ordinary commercial work closely. Imagine a sales manager preparing for a Monday pipeline review.

There are twenty opportunities across the team. The CRM provides a view of them, but the manager knows the fields are not the deals.

A £200,000 opportunity is still shown as Commit. The latest customer call was positive, but the economic buyer did not attend. A security review has appeared unexpectedly. The champion promised an internal meeting last week, but nobody knows whether it happened. The close date remains unchanged.

The manager opens the opportunity. Then the call. Then perhaps Slack. Then asks the AE.

The AE supplies context from memory and explains how they interpret the situation. The manager applies their own experience, perhaps reaches a different conclusion, and eventually decides whether the opportunity should remain in the forecast. Multiply this across the team and something becomes apparent.

The pipeline review is not simply reviewing pipeline. It is one of the mechanisms through which the organisation reconstructs its current commercial state.

The same thing happens in prospecting. A data provider identifies that a new CRO has joined an account. The signal itself does not tell the company what to do.

Someone needs to know whether the account fits the ICP, whether there has been previous engagement, why a leadership change matters, which persona is relevant, what the company is likely to care about and whether this particular change deserves attention now.

The signal becomes useful only after it passes through organisational context and judgement. Customer success follows the same pattern.

Product usage is healthy. Three support cases remain open. Executive engagement has fallen. The original buyer left six weeks ago. The renewal is four months away. None of those systems necessarily says that the customer is at risk.

An experienced CSM might.

Across each example, the visible work is different. Underneath it sits the same repeated process:

Find the evidence → reconstruct the context → apply judgement → decide what matters → coordinate the response.

Then reality changes, and the organisation does it again.

Coordination is not an edge case

Once you start looking for this layer, it appears almost everywhere. A new employee asks why the company qualifies deals a particular way.

A manager explains it. A CRO asks why forecast changed. Several people reconstruct the answer.

Marketing wants to know why a segment is underperforming. RevOps combines data from multiple systems and asks sales for qualitative context.

An account changes ownership. The outgoing rep writes a handover because the systems do not contain the relationship in a form the incoming rep can actually use.

A customer escalates. Support understands the tickets, Sales understands the commercial history and Customer Success understands the relationship. Someone brings those perspectives together.

Companies have developed an enormous number of mechanisms for performing this coordination.

Meetings. Dashboards. One-to-ones. CRM fields. Slack channels. Spreadsheets. Forecast calls. Handover documents. Business reviews. Stand-ups. Internal notes.

Many of these mechanisms are useful and will continue to be useful. The point is not that meetings or dashboards are bad. The more interesting observation is that a significant amount of organisational infrastructure exists because the state of the company is distributed across its people and software.

The company has data. What it repeatedly has to create is understanding.

The cost of reconstruction

This distinction changes how we think about productivity. Consider how much commercial work consists of reconstruction before the primary work can begin.

Before writing the account plan, understand the account. Before deciding how to progress the deal, reconstruct the deal. Before coaching the rep, understand their recent performance and previous coaching. Before reviewing the forecast, establish what changed across the opportunities. Before planning the renewal, reconstruct the customer relationship.

We tend to measure the visible activity that follows. How long did it take to write the email? How many calls did the rep make? How quickly was the report produced?

But the organisation also pays for the context required to make those activities useful. That cost appears in several forms.

There is the obvious cost of time. People search, read, ask, reconcile and prepare. There is a coordination cost. Information has to move between people and teams before action can occur. There is decision latency. Something changes on Tuesday and the person capable of interpreting it discovers the change during Friday’s review. There is information loss. Context becomes compressed as it moves from customer to rep, rep to manager, manager to leader. There is variance. Two people can assemble the same evidence and reach very different conclusions because the organisation’s judgement is distributed unevenly. And there is repetition. The same commercial reality may be reconstructed independently by the rep, manager, RevOps and leadership for different purposes.

None of these costs appears neatly as a line item in the software budget. They appear as the organisation.

More management. More meetings. More operations. More process. More reporting. More requests for CRM hygiene.

The cost of fragmented software is therefore not simply integration cost. It is human coordination cost.

Management is partly an information system

This leads to a slightly uncomfortable observation. A meaningful part of modern management exists to compensate for limitations in the information architecture of the company.

That is not all management does, nor is it an argument that managers disappear. Good managers provide judgement, coaching, motivation, conflict resolution, resource allocation and leadership. Those functions remain deeply important.

But management also moves information. A rep tells a manager what changed. The manager compares that account with others.

Managers tell directors. Directors tell executives. Executives receive a compressed representation of the organisation and make decisions from it.

Information moves upward. Objectives and decisions move downward. The hierarchy is partly a coordination network.

Software changed this network before. Dashboards reduced the need for some manual reporting. CRM gave managers direct visibility into information that once lived in notebooks or individual spreadsheets. Collaboration tools changed how context travelled between teams.

AI gives us reason to ask how much further this can move. If a system can maintain more of the current state of the organisation, identify meaningful changes and make the relevant context available when a decision occurs, some information-gathering functions of management begin to change.

The manager does not need to ask every rep what changed. They can begin with the changes.

That sounds like a small difference. At organisational scale, it is not.

The problem gets worse as the company grows

Human coordination works remarkably well at small scale. Ten people can carry a surprising amount of shared context.

They sit together. They speak frequently. The founder knows most customers. Important information travels informally. People understand not only the official process but why the process exists.

Growth changes this. The company adds people. Then teams. Then managers. Then specialised functions.

Information has to travel further. Context becomes compressed.

The person making a decision is increasingly separated from the event that produced the evidence. Software helps by making more information accessible, but accessibility does not necessarily produce shared understanding.

In fact, specialisation can create the opposite effect.

Sales sees the opportunity. Marketing sees engagement. Product sees usage. Support sees tickets. Finance sees the contract.

Each function develops better visibility into its part of the company while the relationships between those parts become harder to maintain. This creates a familiar scaling response.

More process. More systems. More reporting. More coordination. The organisation builds mechanisms to preserve coherence as complexity rises.

This is one reason RevOps emerged as such an important function in modern GTM. Someone had to make an increasingly fragmented commercial stack and increasingly specialised organisation behave more like one system.

Seen this way, RevOps is not simply the administrator of revenue software. It is partly the human response to a missing architectural layer.

AI can accelerate the coordination layer without removing it

This is where the current wave of AI becomes particularly interesting. Most companies are initially applying AI to the existing operating model.

Summarise the call. Research the account. Write the follow-up. Update CRM. Generate the forecast commentary. Create the customer briefing.

These capabilities reduce work, sometimes dramatically. But notice where many of them sit.

They accelerate individual steps inside the coordination layer. A rep no longer has to write the call summary, but someone still needs to determine what the conversation changed about the deal.

An AI assistant can research an account, but someone still needs to decide whether the account matters and why. A model can draft the forecast narrative, but the organisation may still rely on managers and reps to reconstruct the underlying opportunities beforehand.

We can therefore make the existing operating model considerably faster without fundamentally changing it. This is the distinction between AI-assisted and AI-native that matters to us.

AI-assisted organisations use intelligence to accelerate work performed within the existing architecture.

AI-native organisations begin moving parts of the architecture itself into the system.

The difference is not how many AI features or agents a company uses. It is where the responsibility for maintaining context, applying judgement and coordinating action sits.

More agents do not necessarily create a better system

This distinction becomes more important as agents become capable of taking action. Imagine ten agents operating across a commercial organisation.

One researches accounts. Another drafts outbound. Another assesses deals. Another updates CRM. Another prepares forecasts. Another reviews customer health.

If each agent reconstructs its own context, operates from different assumptions and has no persistent understanding of what the other agents have concluded, we have recreated the SaaS architecture with more autonomous components.

The organisation may become faster. It may not become more coherent.

In fact, autonomous action raises the cost of incoherence. When a human receives incomplete context, they can often recognise that something is missing. They ask a colleague, check another system or delay the decision.

An agent can act immediately. As the cost of action falls, the quality and consistency of the context behind action become more important.

The interesting enterprise AI problem therefore isn’t simply how to make agents more capable. It is how to create the organisational context in which capable agents can act coherently.

That requires something the SaaS stack was never designed to maintain.

From records to state

A company does not only need access to information. It needs a working representation of what is true now.

Consider the difference. A CRM contains the recorded attributes of a deal.

The state of the deal includes those attributes, but also the relationships between them, the evidence accumulated across systems, the organisation’s current interpretation and the changes that matter.

The economic buyer has stopped attending. The champion remains engaged but has failed to mobilise the organisation. Security has introduced an unexpected review. Implementation timing has become uncertain. Competitive risk has increased.

Some of these are observed facts. Others are interpretations.

Together they create a working representation against which the organisation can reason. This is what we mean by Live State.

The important word is not only “live”. It is “state”.

Real-time data gives the organisation faster evidence. Live State maintains an interpretation of what that evidence currently means.

Once that exists, a different operating model becomes possible. A new conversation changes the deal state. A leadership move changes the account state. A support escalation changes the customer state.

The system can compare the new state with the previous one and ask what matters. What changed? Why does it matter? Does the change require action? Who, human or machine, should act?

The organisation no longer needs to begin every important decision by reconstructing reality from scratch. It can begin from maintained state.

From coordination to attention

There is a further consequence. If the system can maintain state, it can begin helping the organisation decide where attention should go.

Attention is one of the genuinely scarce resources inside a company. A sales manager cannot deeply inspect every deal every day. A CRO cannot read every customer conversation. An SDR cannot research every account. A customer leader cannot manually investigate every change in usage or engagement.

The current operating model solves this partly through schedules. Monday pipeline review. Monthly account review. Quarterly business review. Weekly one-to-one.

We batch attention because continuously interpreting everything would be impossible for humans. A stateful system changes that constraint.

Instead of asking a manager to inspect twenty deals to discover the three that changed, the system can identify the changes and bring those three deals to the manager. Instead of asking an SDR to search a territory for relevant accounts, the system can continuously recognise when account state becomes more interesting. Instead of waiting for the next customer review, the system can recognise when a combination of changes warrants intervention.

This does not remove human attention. It makes attention more deliberate.

The system handles more observation and reconstruction so that people can spend proportionally more time where judgement, creativity, relationships or accountability matter. This may ultimately be a more important productivity mechanism than generating work faster.

What belongs in the operating layer?

Once the coordination problem becomes visible, the architecture starts to reveal itself.

A useful operating layer needs a representation of reality. State.

It needs the accumulated knowledge and judgement of the organisation. Memory.

It needs repeatable methods for performing work. Skills.

It needs the ability to coordinate those methods and act through existing systems. Agents and tools.

And as more decisions happen inside the system, the organisation needs to understand what the system knew, why it reached a conclusion, what it did and what happened afterwards. Decision Traces and outcomes.

These components are not interesting because they create a neat product taxonomy. They emerge from the requirements of the operating problem.

If a system is expected to help operate a company, it needs some representation of the world, some understanding of how the company thinks, some ability to perform work, some mechanism for acting and some way to learn whether its decisions were good. The architecture follows from the problem.

A different role for people

The implication is not a company without people. It is a company in which people occupy a different position in the system.

Humans are unusually valuable when the situation is novel, stakes are high, relationships matter, objectives are ambiguous or judgement cannot yet be reliably encoded. They are much less uniquely valuable as middleware.

Finding information in one system and moving it into another. Reconstructing the same account before every interaction. Repeating company knowledge because the system cannot remember it. Collecting status because there is no maintained state. Discovering an exception by manually inspecting everything else.

These activities became human work because software could not perform them reliably. That is a historical fact, not necessarily a permanent organisational design.

As the boundary moves, the roles around it move too. Reps can spend less time reconstructing and more time interacting. Managers can spend less time gathering state and more time applying judgement. Leaders can spend less time consuming compressed reports and more time allocating attention and setting objectives. RevOps can spend less time making applications cohere manually and more time designing the state, knowledge, capabilities and governance of the commercial system itself.

Humans move up the stack because more of the stack finally exists.

The missing layer becomes visible

For most of the SaaS era, the commercial stack was drawn as a collection of applications. CRM. Marketing automation. Sales engagement. Conversation intelligence. Customer success. Data. Analytics.

But this diagram omitted the thing making the applications function as an organisation. The people connecting them.

That omission mattered less when software could not plausibly assume the responsibility. Now it matters a great deal.

AI makes language interpretable, judgement increasingly computable and action increasingly inexpensive. Agents can operate software. Models can reason across information that previously required human interpretation. The constraint that produced the old architecture is moving.

That does not mean every judgement should move into software, or that organisations should automate everything they can. It means we can finally make an architectural choice that previously did not exist.

Which parts of understanding should the system maintain? Which organisational judgement should become explicit? Which recurring work should become executable? Which decisions should remain human? Where should autonomy increase? What needs to be observable? What should the organisation learn from?

Those questions are much more consequential than which team gets the next copilot. They describe the design of the operating model itself.

We spent the SaaS era building increasingly sophisticated systems for storing the evidence and coordinating the workflows of a company. Humans supplied much of the understanding required to turn those systems into an organisation.

AI allows us to start building the missing layer. Not another application for people to coordinate. A system that assumes more responsibility for the coordination itself.

That is where AI-native architecture begins.