Live State

A salesperson finishes a customer call. Several things have changed.

The customer has introduced a new stakeholder. Security will now review the project. The champion remains supportive but sounds less certain about timing. An implementation date discussed two weeks ago is no longer mentioned. A competitor appears for the first time.

The call is recorded. A transcript is generated. CRM may be updated. An AI assistant can summarise what happened.

The organisation now has more data than it did an hour ago. But does it have a better understanding of the deal?

That depends on whether anything has connected the new evidence to what the organisation previously believed. Did the new stakeholder increase or decrease risk? Does the security review represent normal progress or an unexpected obstacle? Has champion strength changed? Is the implementation timeline still credible? Should forecast confidence move? Does anyone need to intervene?

These are not retrieval questions. They are questions about state.

As AI becomes capable of performing more commercial work, I think this distinction becomes increasingly important. The fundamental input to an intelligent commercial system is not simply data.

It is a maintained representation of reality against which the system can reason and act. We call this Live State.

The difference between data and state

Enterprise software has spent decades becoming better at collecting data. CRM contains accounts, contacts, opportunities and activity.

Conversation platforms contain calls. Marketing systems contain engagement. Product systems contain usage. Support systems contain tickets. Billing systems contain commercial relationships.

Data warehouses increasingly bring much of this information together. The resulting infrastructure can provide an extraordinarily rich record of what has happened.

But a record of what has happened is not necessarily an understanding of what is happening.

Consider a deal. The CRM says: £200,000 opportunity.
Stage 3.
Close date: 30 September.
Champion identified.
Next step scheduled.

Those facts may all be technically correct. At the same time, the last two conversations show that the supposed champion has stopped bringing other stakeholders into meetings. Procurement has appeared earlier than expected. The customer has missed a commitment. The implementation timeline has become less specific.

The data has not necessarily become false. The state has changed.

This distinction matters because organisations rarely make important decisions from isolated facts. They make decisions from interpretations of relationships between facts.

A customer having three open support tickets may mean very little. Three open support tickets combined with falling product usage, declining executive engagement and an approaching renewal may mean something very different.

State represents those relationships. It is the working model of reality the organisation uses to decide what happens next.

Companies already maintain state

Live State is not a new organisational requirement. Companies already maintain it. They just maintain much of it through people.

Ask an experienced account executive about an important opportunity and they rarely recite the CRM record. They carry a richer model.

They know who really has influence. Which stakeholder is enthusiastic but politically weak. Whether the champion’s confidence is increasing or deteriorating. Which objection is genuine and which is negotiation. Whether the customer’s stated timeline feels credible. Which internal commitment has not yet been fulfilled.

Some of this knowledge came from explicit evidence. Some came from interpretation.

Some may be difficult for the salesperson to explain precisely. But it affects how they behave.

The same is true for a strong manager looking across pipeline or an experienced CSM thinking about a customer. Humans continuously maintain internal representations of the systems they operate within.

We update those representations when new evidence arrives. We forget some information. We revise previous beliefs. We notice contradictions. We become more or less confident.

And we direct our attention towards changes that seem important. The problem is not that commercial organisations lack state.

It is that much of their most useful state has historically been distributed, ephemeral and human.

That worked when humans were responsible for most interpretation and action. It becomes a serious architectural constraint when machines begin participating in both.

Retrieval is not understanding

One response to fragmented enterprise information has been to make more of it available to AI. Connect the CRM. Index the call transcripts. Add Slack. Retrieve relevant documents. Give the model access to the warehouse.

This is necessary. It is not sufficient.

Imagine asking an AI assistant: “Is the Meridian deal healthy?”

The system retrieves the opportunity record, recent calls, emails and qualification methodology. It has access to the evidence. It can now reconstruct an answer.

That is useful, but notice what happened. We reproduced the human operating model inside the prompt.

Every time the question is asked, the system gathers information and attempts to reconstruct the current situation. The context is assembled at inference time. Then it disappears.

Ask another agent a slightly different question and it may retrieve different evidence, construct different context and reach a different conclusion.

Retrieval gives the model access to memory.

It does not necessarily give the organisation persistent state.

This distinction becomes increasingly important as the number of decisions and agents grows. If every agent independently reconstructs reality before acting, the company has not created a shared operating model.

It has created many intelligent observers of fragmented evidence. Live State is the attempt to make the interpretation itself persistent.

State contains observations and beliefs

To understand what this requires, it helps to separate two kinds of state. The first is observed state.

These are things the system has direct evidence for. A stakeholder joined the meeting. Product usage fell 18%. The customer requested a security review. A prospect visited the pricing page. The renewal date is 1 December. A new CRO joined the company.

Observed state should remain connected to its underlying evidence.

Then there is derived state. These are interpretations produced from one or more observations.

Champion strength is declining. Deal risk has increased. The account has become more relevant. Renewal confidence is lower. Competitive pressure is rising. The opportunity no longer satisfies part of the qualification criteria.

Commercial organisations depend heavily on derived state. “Healthy deal” is derived state. “High propensity account” is derived state. “Strong champion” is derived state. “Customer at risk” is derived state.

The mistake would be to treat those interpretations as ordinary database fields. They are beliefs.

A capable system should therefore be able to distinguish: what it observed, what it inferred, why it inferred it and how confident it is. That creates a much richer representation of commercial reality than simply writing another value into CRM.

State should contain uncertainty

Human commercial judgement is rarely binary. A manager may believe there is probably an economic buyer but recognise that the evidence is weak. A salesperson may believe the champion is strong while remaining uncertain about their ability to mobilise procurement. A CSM may suspect churn risk without having enough evidence to escalate yet.

Traditional enterprise software tends to compress this uncertainty. Champion: Yes. Economic Buyer: Identified. Health: Amber. Forecast: Commit.

Reality is usually messier. An AI-native system has an opportunity to preserve more of that uncertainty rather than hide it.

For example: Economic buyer identified: high confidence. Champion influence: medium confidence, declining. Implementation timing: low confidence. Security risk: medium confidence, newly elevated.

This matters for more than accuracy. Uncertainty should affect behaviour.

High-confidence, low-risk decisions may be automated. Low-confidence or high-consequence decisions may require human judgement.

The representation of state can therefore become part of the governance model. Autonomy does not have to be a global switch. It can depend on what the system knows and how confidently it knows it.

State has time

There is another property of commercial reality that most static records represent poorly. Time.

A deal is not simply a collection of attributes. It is a changing system.

Champion strength today matters. The direction of champion strength may matter more.

Product usage at 60% may be healthy for one customer. A decline from 90% to 60% over three weeks may be much more important.

Five engaged stakeholders may look positive. If there were eight last month, the interpretation changes.

This means the system needs more than current state. It needs some understanding of state transitions.

What was true? What happened? What became true afterwards?

This gives us a useful concept: Δ State. The change in state.

In many commercial situations, Δ State is more actionable than the absolute state itself.

The account was already a good ICP fit. Then a new CRO arrived. The deal was already moderately risky. Then the economic buyer stopped attending. The customer was already healthy. Then product usage fell while support volume increased.

Something changed.

The role of an intelligent system is not simply to record the event. It is to determine whether the event changed the meaning of the situation.

Not every change matters

This introduces another problem. Commercial systems generate enormous numbers of events.

An email opens. A webpage is visited. A contact changes job. A call occurs. Usage changes. A ticket closes. A stakeholder replies. A CRM field updates.

If every event becomes an alert, the system creates noise rather than intelligence. So Live State cannot simply mean “everything updated in real time”.

The system needs to distinguish between an event and a meaningful state transition.

A pricing-page visit from an unknown visitor may mean little. A pricing-page visit from the economic buyer of a late-stage opportunity after three weeks of inactivity may mean considerably more.

The event is similar. The state around it is different.

This is why context matters. Signals do not have fixed meaning. Their significance depends on the state in which they occur.

An intelligent commercial system therefore needs to ask: What happened? What did we previously believe? Does this evidence change that belief? How materially?

And does the change require attention or action? This is the point where state becomes operational.

State determines attention

One of the most valuable outputs of Live State may not be another piece of information. It may be attention.

Consider a sales manager with forty opportunities across a team. The traditional approach is periodic inspection.

Pipeline review on Monday. Forecast call on Thursday. One-to-ones throughout the week.

The manager repeatedly scans the system because the system cannot reliably tell them which changes matter. But the manager’s attention is scarce.

They should not spend equal time on forty deals. They should spend attention where something important has changed, where uncertainty is high, where the consequences are material or where human judgement can alter the outcome.

A stateful system can begin making that allocation explicit. Three deals deteriorated materially overnight. One strategic account produced a new buying signal. Two customers developed unusual combinations of usage and support behaviour. One rep has repeatedly overridden the same recommendation.

These are not simply notifications. They are attention decisions.

The system is determining which changes in commercial reality are significant enough to enter human cognition. That may become one of the most important roles of AI-native software.

As information and machine-generated work become abundant, attention becomes relatively more scarce. The best system is therefore not necessarily the one that generates the most intelligence. It may be the one that knows what the organisation does not need to think about.

State is relational

Commercial entities do not exist independently. An account contains people. People participate in opportunities. Opportunities contain conversations. Customers use products. Stakeholders move between companies. Products create support issues. Campaigns affect engagement. Deals become customers. Customers create expansion opportunities.

The meaning of one entity often depends on its relationship with another.

A person becoming CFO is interesting. That person becoming CFO at an account with which the company previously lost a deal may be more interesting.

A support escalation matters. A support escalation involving the executive sponsor six weeks before renewal matters differently.

This is why a useful commercial state increasingly looks less like a collection of isolated rows and more like a connected model of entities, relationships, events and beliefs.

The precise technical implementation can vary. The conceptual requirement does not.

The system needs enough structure to understand that commercial reality is relational. This also explains why ontology matters.

If the system does not understand concepts such as Account, Opportunity, Champion, Economic Buyer, Competitor, Renewal or Commitment, it cannot reliably reason about the relationships between them.

Better models do not remove the need to represent the world. They make richer representations useful.

State depends on organisational judgement

There is an important boundary here. State is not entirely objective.

Whether an account is “high fit” depends on how the company defines fit. Whether a champion is “strong” depends on what the organisation believes a champion must actually do. Whether a deal is “healthy” depends partly on the sales process, market, product and accumulated experience of that particular company.

So Live State cannot be separated completely from organisational knowledge.

The system may observe that a contact attended five meetings. That is evidence.

Whether those five meetings constitute evidence of a champion depends on judgement. One company may define a champion as an enthusiastic contact. Another may require evidence that the person has power, access and the willingness to sell internally.

The same observations produce different derived state.

This is why generic model intelligence is not enough. The system needs access to the company’s own operating logic.

State tells us what is happening. Memory tells us how this organisation interprets what is happening.

That is the next architectural layer.

State and capability are connected

Once state exists, work can begin from a fundamentally different starting point. Consider account research.

In the traditional model, research is an activity. Someone decides to investigate an account and then gathers the information required to understand it.

With Live State, much of the account understanding already exists. Research becomes continuous rather than episodic. New evidence updates the state.

A meaningful change can invoke a capability. The same is true of Deal Risk.

The organisation does not need to wait for Thursday’s pipeline review to ask whether the deal changed. A state transition can trigger the assessment.

Customer health does not need to be recomputed only when someone opens the customer success platform. Changes to relevant evidence can update the state continuously.

This changes the relationship between information and work. Traditional workflows often begin because a person starts them. AI-native capabilities can increasingly begin because the world changed.

That is a much more consequential shift than automating another workflow.

A different commercial rhythm

Much of modern GTM operates on schedules. Monday pipeline review. Tuesday prospecting block. Weekly forecast. Monthly account review. Quarterly business review.

Schedules are useful coordination mechanisms, but they are also a response to information constraints. Humans cannot continuously monitor everything. So we inspect reality periodically.

A stateful system makes another rhythm possible.

Event → state change → interpretation → attention → capability → action.

The organisation becomes more responsive to changes in the environment rather than relying entirely on predetermined review cycles.

This does not mean calendars disappear. Some work benefits from deliberate cadence, reflection and synchronous discussion.

But the relationship between scheduled work and event-driven work changes. A manager may still hold a weekly pipeline review.

The difference is that the review can begin with the deals whose state materially changed, the decisions made since the previous review and the exceptions requiring human judgement.

The meeting starts from shared state rather than spending half its time creating it. That changes the experience of the organisation.

State reduces decision latency

This has an economic consequence. Consider the interval between something changing in reality and the organisation responding.

A champion disengages on Tuesday. The rep notices gradually. The manager discovers it on Friday. The forecast changes the following Monday.

An intervention occurs several days after the underlying state changed. That interval is decision latency.

Some latency is unavoidable. Some decisions require evidence to accumulate. But much of it exists because organisations discover changes through periodic human reconstruction.

Live State can compress that interval. Evidence arrives. State updates. A material transition is recognised. The appropriate capability runs. Attention is allocated. A person or agent acts.

The economic value is not simply that each step became faster. The organisation became capable of responding closer to the moment reality changed.

In commercial systems, timing often affects outcomes. A customer risk discovered three months before renewal is different from the same risk discovered three weeks before renewal. A newly appointed executive contacted during their first weeks in role is different from the same executive contacted six months later. A deal risk identified before the next customer conversation is different from one identified during the post-mortem.

Decision latency is therefore not merely an operational metric. It can become a source of commercial advantage.

Shared state changes coordination

There is another consequence. When different people and agents operate from different representations of reality, coordination becomes expensive.

The rep thinks the deal is healthy. The manager thinks it is risky. CRM still says Commit. The forecast model uses stale information. An agent recommends a follow-up based on yesterday’s context. RevOps sees another version in the dashboard.

Before the organisation can act coherently, these representations have to be reconciled. Shared Live State reduces that problem.

It does not mean every person or agent must reach the same judgement. Disagreement can be useful.

But disagreement can happen about a shared representation of the evidence, rather than because everyone started from different information.

That distinction becomes particularly important in multi-agent systems. If a Prospecting Agent, Deal Agent, Forecast Agent and Manager Agent all reconstruct their own versions of the commercial world independently, coordination problems multiply.

A shared state provides a common environment against which specialised capabilities can operate.

The intelligence can be distributed. The reality should not be.

State must remain inspectable

There is an obvious danger in all of this. A system that maintains derived state can also maintain the wrong state.

It can misinterpret evidence. It can over-weight a signal. It can apply stale company logic. It can become confident about something that was never properly observed.

A human carrying an incorrect belief about one deal is a problem. A shared operating system propagating an incorrect belief across multiple capabilities can be a much larger one.

So Live State must not become an opaque layer of machine-generated truth. The organisation needs to inspect it.

Where did this state come from? Which evidence supports it? Which parts were observed? Which were inferred? How confident is the system? What changed the belief? Which company logic influenced the interpretation? When was it last updated?

This is one reason the relationship between State and Decision Traces becomes important.

AI-native systems need persistent understanding. They also need persistent accountability for how that understanding was formed.

The commercial system begins with a model of reality

For most of the SaaS era, applications became better at storing individual pieces of commercial reality. That was enough because humans supplied much of the interpretation between them.

As AI assumes more responsibility for deciding and acting, access to those fragments is no longer sufficient. The system needs a maintained model of the environment in which those decisions occur.

Not perfect knowledge. Not one immutable version of truth. A working representation containing evidence, relationships, interpretations, uncertainty and change. That is Live State.

It changes the starting point for commercial work. Instead of:

Find information → reconstruct context → decide → act

the organisation can increasingly begin with: State changed → interpret change → allocate attention → invoke capability → act

That difference appears subtle when viewed as another software feature. At the level of the operating model, it is fundamental.

Because once the system can maintain some understanding of what is true now, the next question becomes unavoidable.

How should it decide what that state means?

Every company answers that question differently. The answer lives in its accumulated knowledge, experience and judgement. And that is where Memory begins.