Why do we need a runtime?

Enablement work is highly stateful. Most enablement systems are not.

For years, the practitioner has closed that gap.

The most valuable person in the room was often the one who knew where everything lived, which leader really owned the metric, what “adoption” meant inside this company rather than inside a framework, which dashboard people trusted, and why the sensible-looking program from six months ago quietly failed.

Across customer, partner, sales, and internal enablement, the same dependency appears in different forms. We call it experience, which is fair. Increasingly, I think we were also asking that person to function as the runtime for the organization’s performance work.

Customer onboarding makes the problem easy to see.

The request rarely names the performance problem

A business asks enablement to improve onboarding because customers are taking too long to reach value. It sounds like a program request. It is not yet a performance diagnosis. Before anyone builds a course or updates the academy, a good practitioner starts resolving everything hidden inside it.

What does “onboarded” mean here? Is the customer onboarded after implementation, after the first critical product task succeeds, after enough users become active, or after the customer reaches a business outcome? Which roles need to produce what? Which parts belong to Customer Success, Professional Services, Product, Support, or Enablement? Which evidence would tell us that any of this is improving?

None of that lives neatly in one place. The practitioner connects the definitions, owners, conditions, evidence, and decisions.

Then the evidence changes our understanding of the problem. Implementation data shows that configuration is not the bottleneck. Customer interviews suggest the problem appears after handoff. Product telemetry shows that customers rarely complete one critical product task. Customer Success believes customers need more training. Product believes the task itself is too difficult to complete.

By that point, the work is no longer “build better onboarding.” It is a performance-improvement challenge with competing explanations, evidence from several systems, and decisions that matter to whatever happens next.

The state moves between meetings, documents, dashboards, messages, systems, and people. Then we add an AI assistant and do something slightly absurd: explain the company again, explain the journey again, upload the evidence again, and explain which source to trust.

The practitioner has been the runtime

A runtime externalizes and governs the context that practitioners currently carry between systems and episodes. That makes a new operating model possible: a governed synthetic peer working alongside the practitioner. In LXNow, I call that peer the Practitioner Twin. It carries context and proposes work; the practitioner retains judgment and authority.

This is one reason I chose Stateless as the name of this publication.

The work itself is highly stateful, but the operating environment mostly is not. A request arrives. Evidence reframes the performance problem. An assumption fails. A leader changes the priority. The product changes. An intervention ships. Results come back. Three months later, somebody asks a related question that only makes sense if the reasoning survived.

Systems remember activity: a course was completed, a field changed, a call occurred, a product-use event fired. The practitioner remembers why those events mattered, what they could support, what contradicted them, and what remained unresolved.

Human Performance Technology (HPT) begins from a different premise: a request is a signal, not a diagnosis. Before selecting an intervention, the practitioner clarifies the required output, its standard, the conditions around it, possible causes of the gap, and the evidence that would distinguish one explanation from another.

LXNow makes that definition explicit as a Performance Contract: the required business result, performer output, standard, operating conditions, authority, and evidence for one repeatable area of performance.

That is why training completion cannot stand in for performance. It is evidence that someone encountered an intervention. Whether the required performance changed is a different question.

The practitioner has been carrying that distinction from episode to episode. The practitioner’s memory and judgment became the integration layer.

Memory is not enough

For a while, I thought this was mainly a persistence problem. Keep the context, evidence, decisions, and history, and much of the friction disappears.

That helps, but it only solves half the problem. Once the information persists, we still have to ask what any of it means.

If a dashboard says time to value is 38 days, what starts the clock and what stops it? If a manager says sales-methodology adoption is poor, what evidence would distinguish poor knowledge from poor execution? If the LMS says a seller completed training, what performance should that completion predict? If a customer completed onboarding, what became possible that was not possible before?

Companies do not lack information. They have an absurd amount of it. What they often lack is a durable model of the meaning that connects it.

This is where ontology became practical for me. An ontology is an explicit model of the things that exist in a domain, what they mean, and how they relate. An experienced practitioner carries an implicit working ontology. A runtime makes the relevant parts explicit, governable, and reusable.

Imagine a company using a documented value-based selling methodology. Knowing the methodology exists is context. Knowing how it connects to seller roles, required discovery performance, opportunity stages, manager coaching, CRM evidence, and commercial outcomes is the work.

The useful model is not simply:

Methodology → course → completion

It is closer to:

Seller → discovery situation → required output → standard → tasks and method → operating conditions → evidence → commercial result

Now a weak adoption signal can be investigated as a knowledge problem, an execution problem, a reinforcement problem, a process problem, an instrumentation problem, or even a methodology that no longer fits the current motion.

What I mean by runtime

A repository stores the material. A chatbot retrieves and discusses it. A runtime assembles the governed context required to diagnose and act on one performance episode.

It connects roles, required performance, business outcomes, products, processes, obstacles, interventions, evidence, and results—only to the extent needed for the episode in front of the practitioner.

Not the whole enterprise. That would be unnecessary and probably impossible to maintain well. Just enough of it.

That is why I keep returning to three operating lenses in LXNow: Business × Performance × Product.

Business defines the result that must change, its stakes, constraints, and ownership. Performance defines what people must produce, under which conditions, and to which standard. Product defines the capabilities, user tasks, and changing source material involved in the episode.

For onboarding, the useful model is not “customer → onboarding course → completion.” It might be “customer role → onboarding stage → required output → critical product task → adoption milestone → obstacle → intervention → evidence → time to value.”

Once those relationships are explicit, the environment can orient the Twin around the relevant slice of work instead of asking a model to carry the entire company inside one enormous prompt.

The Twin can propose and reason. The practitioner and designated business owners retain judgment, correction, acceptance, and release.

The existing systems do not need to disappear

I do not think enablement needs another system claiming to become the source of truth for everything.

CRM records selected commercial state. The LMS records learning activity. Product analytics records product-use events. A content system records what was published. A call recording preserves what was said. A manager contributes what they observed.

Those systems should keep doing what they are good at. The runtime has a different design target: preserve where each claim came from, what that source can support, and enough provenance for the practitioner to judge its weight inside the same performance episode.

In onboarding, telemetry may show that a customer completed a critical product task. The academy may show that administrators completed training. Customer Success notes may show that the customer still does not know who should own the process internally.

Those are different signals about the same episode. None is automatically the diagnosis.

When authorized sources are connected, the runtime should help assemble that evidence without flattening it into one synthetic truth. It should make the relationships visible while preserving the practitioner’s responsibility to interpret them.

The execution layer can be thin

The Twin does not need to contain the company, every framework, every document, every previous project, and every policy inside one giant prompt. The governed environment should carry that.

If the practitioner is working on a sales-methodology challenge, the runtime should assemble the relevant method, role expectations, process, evidence, outcomes, and accepted previous decisions. If the work concerns onboarding, it should assemble the journey, product milestones, roles, interventions, sources, and prior learning that the practitioner has authorized.

The Twin reasons over that bounded slice. The product direction is a governed sequence:

LXNow’s current foundation is the governed structure for this work: definitions and eligible knowledge, Briefs, scoped context, human approvals and proposals, audit, and run records. The product direction is to connect more authorized evidence sources, assemble richer performance context, and follow outcomes across episodes.

I am testing that direction through real work, not claiming that the complete loop is finished.

The intelligence can change. The model provider can change. The interface can change. The company should not have to reconstruct itself every time they do.

Experience does not become less valuable. Its leverage moves.

A great deal of seniority in enablement comes from accumulated organizational context. That is real value, and I do not expect AI to erase it. It is also a bottleneck when every complex performance-improvement challenge requires one of the few people who can reconstruct the whole environment from memory.

If more of that structure can live in a governed runtime, an earlier-career practitioner can begin from something better than a blank page. Someone moving from Sales Operations may contribute deep knowledge of pipeline, CRM, and manager cadence. Someone from Customer Success may understand adoption better than a traditional learning specialist. Someone from Product may see that the apparent training problem is actually task or environmental friction.

The runtime does not make someone magically competent. It widens who can contribute by making the architecture around the work inspectable. Accountable practitioners still qualify the diagnosis and release the work.

For experienced practitioners, the leverage moves upward. They can define standards, shape the ontology, ratify what becomes accepted knowledge, review difficult diagnoses, and design better interventions instead of manually carrying every piece of context.

Over time, I can imagine experienced practitioners consulting across separately governed company Charters, with company data and memory isolated unless explicit authority permits otherwise. Their experience becomes a way to improve several governed environments—not a reason they must personally operate every one.

The emerging operating model is not one practitioner using more disconnected copilots. It is a practitioner working with a governed synthetic enablement peer that can investigate, analyze, design, coordinate, evaluate, and preserve continuity across performance episodes.

So why do we need a runtime?

Because the practitioner is doing too much invisible systems work today.

We carry state between tools, translate between business and performance language, remember what things mean, reconnect evidence, apply methods, decide what matters, preserve history, and rebuild the company around each new request.

That has made experienced practitioners extraordinarily valuable. It has also made the work difficult to scale and difficult to enter.

Customer, partner, sales, and internal enablement do not become the same discipline. They converge on the same operating model: a practitioner, a governed synthetic peer, and a runtime that carries the context, Performance Contracts, evidence, and memory neither should have to rebuild.

A runtime gives that invisible architecture somewhere else to live. The ontology makes the relationships explicit. The Charter sets the Twin’s identity, mandate, rules, and authority. A Performance Contract defines the required business result, output, standard, conditions, and evidence. The Brief activates that contract for one performance episode. The Harness compiles the authorized context and capabilities. The Twin proposes and reasons across that slice. The Vault preserves accepted evidence, decisions, and learning for the next episode.

The practitioner judges, corrects, accepts, and releases.

The practitioner has been the runtime.

I am interested in what happens when they finally get one.