From Playbooks to Executable Skills

Most companies have a version of the same problem. They know what good looks like. They just cannot make it happen consistently.

The sales leader knows how a strong discovery conversation should be prepared for. The experienced manager knows how to assess a deal. Marketing knows how the company should position itself. Customer Success knows which questions should be asked before a renewal.

So the organisation tries to transfer that knowledge. It creates a playbook. Runs training. Builds templates. Adds fields to CRM. Creates checklists. Managers coach employees. Over time, the organisation develops increasingly sophisticated descriptions of how work should be performed.

Then reality intervenes.

The playbook is twenty pages long. The salesperson has six meetings today. The account does not look quite like the examples from training. Relevant information sits across four systems. The process has changed since the document was written. The strongest employee has developed a better method that nobody has documented.

The work happens anyway. Sometimes brilliantly. Sometimes not. This gap between how an organisation intends work to happen and how work actually happens is one of the persistent problems of operating a company.

AI creates the possibility of narrowing it. Not by writing better playbooks. By changing what a playbook can become.

The playbook was written for a human execution environment

A traditional playbook is a set of instructions. Research the account. Identify the persona. Review previous engagement. Understand the customer’s priorities. Prepare discovery questions. Confirm next steps.

The instructions may be excellent. But the playbook itself does nothing. A person has to interpret it. They need to know when it applies, find the relevant information, understand the instructions, adapt them to the situation, use the necessary tools and produce the outcome.

This is why the quality of a process depends so heavily on the person executing it. The playbook is only one input. Experience matters. Attention matters. Time matters. Access to information matters. Interpretation matters. The employee is the execution environment.

For most of the software era, there was no realistic alternative. We could encode simple deterministic workflows into software, but complex commercial work was too contextual to reduce to fixed rules.

So organisations separated the method from the execution. The method lived in documentation. The execution lived in people. AI begins to collapse that separation.

A Skill is a method for performing work

Suppose we want an organisation to possess a Meeting Preparation capability. Live State can tell us what is currently true about the account, people and opportunity. Memory can provide the company’s relevant knowledge: its positioning, personas, product, sales process and understanding of what a successful meeting should accomplish.

But neither tells the system exactly how to prepare for this meeting. It needs a method. Which context should be inspected? How should previous conversations be considered? Which unresolved commitments matter? How should stakeholder relationships affect preparation? When should competitive information be included? How should the objective change depending on the current deal state? What should the final briefing contain?

That method is a Skill.

A Skill defines how a recognisable piece of work should be performed using available State, organisational Memory and tools. This is different from knowledge.

“An Economic Buyer has authority over the financial decision” might be part of Memory. “Assess whether an Economic Buyer has been meaningfully engaged and identify the evidence supporting that assessment” is part of a Skill.

Memory tells the system something about the world. A Skill tells the system what to do with that knowledge in pursuit of an outcome.

A Skill is not a prompt

It would be easy to reduce this idea to prompt engineering. Write a detailed instruction. Give it to a model. Save it. Call it a Skill. That may be a useful starting point, but it misses the architecture.

A robust Skill may contain instructions, but it can also contain: required inputs, relevant Memory, tools, decision criteria, conditional paths, output requirements, evaluation criteria, permissions, escalation rules, and relationships with other Skills.

Consider Deal Assessment. A simple prompt might say: “Review this opportunity and assess its health using MEDDPICC.”

A company-specific Deal Assessment Skill is more demanding. It needs to know which evidence should be considered authoritative. How the company defines each qualification concept. How to treat missing evidence. Whether an unanswered question should reduce confidence or create risk. Which changes since the previous assessment matter. When contradictory evidence should be escalated. What level of confidence is required. Which findings should affect forecast. What the output should contain. And perhaps when a manager must review the judgement.

The Skill is not simply prose sent to a model. It is an executable method. The model provides intelligence inside that method.

Skills sit between judgement and action

This gives Skills a specific position in the operating model. Live State represents the commercial environment. Memory represents the organisation’s accumulated knowledge and judgement. Skills define methods for applying that judgement to the environment. Capabilities compose those methods into useful organisational outcomes. Agents coordinate execution.

This distinction matters because otherwise AI systems tend to collapse everything into one large instruction. “Here is everything we know. Here is everything you should do. Now perform the task.” That may work for a prototype. It becomes difficult to govern, reuse and improve at organisational scale.

Separating Memory from Skills creates modularity. The company’s definition of a strong champion can exist once in Memory. Deal Assessment can use it. Meeting Preparation can use it. Pipeline Review can use it. Coaching can use it. If the definition changes, the organisation updates the underlying Memory rather than editing four separate prompts.

Similarly, a Skill can be reused by multiple capabilities. Account Research may support Account Prioritisation, Meeting Preparation and Territory Planning. The architecture becomes compositional. That is important for both consistency and learning.

Good work is contextual

There is a reason traditional playbooks often fail in practice. They are written as general instructions, while commercial work happens in specific situations. A first discovery meeting is not a late-stage procurement conversation. A £20,000 opportunity is not a seven-figure strategic deal. A newly appointed CRO at a target account is not an anonymous website visitor. A customer with declining usage six months before renewal is not the same as a customer with declining usage two weeks before renewal.

The method needs to respond to state. This is where Skills differ from static process. The organisation can define what good work looks like without requiring the exact path to be predetermined.

A Meeting Preparation Skill can behave differently depending on: meeting type, deal stage, stakeholders, previous interactions, open risks, company objectives, available evidence, and uncertainty.

The objective remains stable.

The execution adapts.

This sits between two older models of software. It is more flexible than a deterministic workflow. It is more governed than giving an unconstrained agent an objective and hoping it behaves appropriately. That middle ground is important. Much of organisational work requires bounded judgement.

Bounded judgement may be the real enterprise pattern

There is a tendency in AI discussions to frame autonomy as a spectrum from human work to fully autonomous agents. I think this misses how many organisations actually operate. Companies already constrain human judgement.

A salesperson has discretion, but within pricing policy. A manager can change forecast, but within a defined process. A CSM can intervene with a customer, but within contractual and commercial boundaries. A finance employee can approve certain expenditure, but not unlimited expenditure. Organisations are systems of bounded autonomy.

AI-native work will likely develop similarly. A Skill can define the boundaries within which intelligence operates. Use these sources. Apply these definitions. Follow these principles. Use these tools. Do not take this action without approval. Escalate when confidence falls below this threshold. Produce this evidence before reaching this conclusion.

The system can still reason. It can still adapt. It can still handle situations the Skill author did not enumerate explicitly. But it does so inside an organisationally defined method.

This may be more important than maximising autonomy. The objective is not to remove constraints from intelligence. It is to encode the right ones.

Skills make tacit craft more explicit

The most interesting Skills may not begin as documented processes at all. Consider an exceptional sales manager preparing for a pipeline review. They may inspect the same CRM data as everyone else, but their method is different.

They notice which opportunities have remained in the same stage too long. They compare the rep’s confidence with actual customer evidence. They pay attention to whether the champion is creating internal movement. They recognise when a close date has become an organisational fiction. They know which deals deserve five minutes and which deserve thirty.

Ask the manager to document this process and some of the method will appear. Much will remain tacit.

But an AI-native system has another source of evidence. It can observe the work. Which deals does the manager inspect first? Which questions do they repeatedly ask? Which system recommendations do they override? Which evidence changes their judgement? Which interventions subsequently improve outcomes?

Over time, the organisation can begin extracting more of the method behind exceptional performance. This does not mean copying every behaviour of the highest performer.

Some behaviour is idiosyncratic. Some success is contextual. Some patterns will not generalise.

But the system can help identify candidate operating logic that would previously have remained trapped in individual craft. Skills therefore create another path through which tacit capability can become organisational capability.

Skills should be versioned

Once a Skill affects how work is performed, changing it becomes consequential. Suppose the company changes its Deal Assessment Skill. Previously, lack of Economic Buyer engagement created moderate risk. Historical outcomes now suggest it should carry substantially more weight for enterprise opportunities. The Skill changes.

That change may affect: deal assessments, management attention, forecast, coaching, and potentially agent actions.

The organisation should know that this happened. Which version of the Skill produced a particular assessment? Who approved the change? Why was it changed? Did the new version perform better? Should it be rolled back?

This is why Skills should increasingly be treated like versioned operational assets. Software teams would not silently modify production code and then forget which version executed. AI-native organisations should develop similar discipline around the logic through which consequential work is performed.

This does not mean every prompt edit requires enterprise bureaucracy. Governance should be proportional to consequence. But the principle matters: If changing a Skill changes organisational behaviour, the change should be observable.

Skills need evaluation

Traditional playbooks are rarely evaluated directly. A sales methodology might remain in place for years. People may believe it works. Managers may like it. Training may reinforce it. But separating the quality of the method from the quality of the people applying it is difficult.

Executable Skills create a new possibility. The Skill produces work repeatedly. That work creates traces. The organisation observes outcomes. We can begin asking: Did this Skill improve the quality of Meeting Preparation? Does this Account Prioritisation method identify accounts that convert at higher rates? Does this Deal Assessment Skill identify risk earlier? Does this Coaching Skill produce interventions associated with improved performance? Which version performs better? Where do humans repeatedly override it? Where does it fail?

This moves organisational process closer to software. Not because commercial work becomes deterministic. Because the method itself becomes observable. That is a major change.

Evaluation should happen at several levels

There is a danger in evaluating Skills only against final business outcomes. Revenue is noisy. Deals are lost for many reasons. Customers churn despite good intervention. A well-prepared meeting can still go badly. So Skill evaluation needs layers.

First, we can evaluate the output itself. Was the briefing accurate? Did the assessment cite relevant evidence? Were important risks missed? Was the recommendation consistent with company logic?

Then we can evaluate behaviour. Did the user accept the recommendation? Did they override it? Did they edit it substantially? Did the capability invoke the right Skill at the right time?

Finally, we can evaluate downstream outcomes. Did the deal progress? Did the forecast become more accurate? Did the account respond? Did the customer renew?

None of these signals is perfect. Together they create evidence. The important change is that organisations can begin connecting how work was performed with what happened afterwards. That connection is weak in most companies today.

Human overrides become valuable data

This creates a different interpretation of disagreement with AI. Suppose a manager rejects a Deal Assessment. In a simple AI system, that may be recorded as a thumbs down. In an AI-native operating model, the disagreement can be much more informative.

Was State incomplete? Was relevant Memory missing? Did the Skill apply the wrong method? Did the model reason poorly? Was the manager using tacit knowledge the system does not yet possess? Or was the manager wrong?

The override becomes an investigation point. Repeated overrides create a pattern. Perhaps managers consistently disagree when procurement enters unusually early. The organisation may discover that its Skill does not account for something experienced managers already understand.

A human correction is no longer merely feedback on an output. It can reveal a deficiency in the operating system. This is how people move from supervising individual AI outputs toward training the organisation’s capabilities.

Skills can improve from outcomes

Now the loop becomes more interesting. A Skill is created. It performs work. Its decisions and outputs are traced. Humans interact with it. Outcomes occur. The system observes patterns.

Perhaps one step in the method appears unnecessary. Perhaps an additional signal improves accuracy. Perhaps the Skill works well for SMB opportunities but poorly for enterprise. Perhaps experienced users repeatedly add the same question. Perhaps a particular source of evidence creates false confidence.

The system can propose an improvement. A human reviews it. A new version is released. Future work uses the upgraded Skill.

This is very different from a static playbook. The playbook was written, distributed and periodically revised. The Skill participates in a feedback loop.

Method → execution → trace → outcome → evaluation → upgrade.

The method itself can learn.

This changes process improvement

Most companies improve processes periodically. A problem becomes visible. Someone investigates. A working group meets. The process is redesigned. Documentation changes. Training happens. Software configuration follows. Eventually the organisation adopts the new approach.

This can take weeks or months. Sometimes years. Part of the delay exists because the operating system has very little direct visibility into its own effectiveness.

Processes are spread across people and software. The organisation sees outcomes but often struggles to connect them back to the exact method that produced them.

Executable Skills make process more legible. If the system knows which Skill version ran, which State it operated on, which Memory it used, what decisions were made and what outcome followed, process improvement becomes much more empirical.

This does not eliminate human judgement from process design. It gives that judgement better evidence. The company can increasingly ask not merely: “What process should we have?” but: “What is our current method learning?”

Skills create consistency without requiring uniformity

This point is worth protecting. The goal of executable Skills is not to make every employee behave identically. That would misunderstand both people and commercial work.

A great salesperson should still adapt. A manager should still disagree. A strategic account should still receive different treatment. Novel situations should still create exceptions. The objective is to remove unnecessary variance.

Two employees should not produce radically different account research simply because one remembered to read the ICP document and the other did not. Two managers should not apply different definitions of a champion because they were trained by different leaders. A CSM should not miss an established risk pattern because the person who learned it left the company six months earlier.

Skills provide a shared method. Intelligence adapts the method to the situation. Humans intervene where their judgement adds value. Consistency exists at the level of operating logic, not identical outputs.

Skills change onboarding too

A new employee joining a company has traditionally had to learn both what the company knows and how the company works. Read the documents. Watch recordings. Shadow colleagues. Learn the tools. Practise the process. Receive coaching. Gradually internalise the organisation’s methods.

This remains valuable. People need understanding, not simply instructions. But executable Skills change the dependency. The employee can begin operating inside methods that already contain more of the organisation’s accumulated practice.

Meeting Preparation does not depend entirely on whether they remembered every part of onboarding. Account Research already applies the current ICP and persona logic. Deal Assessment already brings the company’s qualification method into the work. The employee learns while operating inside the system.

This creates an interesting reversal. Historically, the company trained the person so the person could execute the process. Increasingly, the company can also encode the process so the system helps train the person. The Skill becomes both execution infrastructure and a distribution mechanism for organisational craft.

Skills and agents should not be confused

As agents become more visible, this distinction becomes particularly important. An agent is an actor. A Skill is a method.

The same agent can use many Skills. The same Skill can be used by many agents. A Prospecting Agent might use Account Research, Contact Research and Message Creation Skills. A Meeting Agent might use Account Research and Meeting Preparation. A Manager Agent might use Deal Assessment and Pipeline Review.

This separation is useful because the organisation should not need to duplicate its method every time it creates another agent. If the Account Research Skill improves, every agent and capability that uses it can inherit the improvement.

That is how the architecture compounds. The organisation builds reusable methods rather than a growing collection of isolated autonomous agents.

Skills can cross human and machine work

There is another reason to separate Skills from agents. A Skill does not have to be machine-only. Consider Deal Strategy.

Part of the Skill may be performed autonomously. The system assembles evidence. Identifies changes. Applies qualification logic. Generates possible paths.

Another part may require a manager and AE to make the final judgement together. The Skill can structure that collaboration. It can bring the right evidence into the discussion. Highlight uncertainty. Preserve the decision. Trigger the appropriate follow-up afterwards.

This is important because many high-value organisational capabilities will remain hybrid for a long time. The choice is not: human or agent.

The more useful question is: Which parts of the Skill should be performed by software, which require human judgement, and how should the two interact? This makes Skills a useful unit for designing the human-machine boundary.

The Skill library becomes part of the company

Once an organisation starts encoding Skills, a new kind of asset emerges. Imagine a company has developed high-quality Skills for: Account Research. Account Prioritisation. Meeting Preparation. Discovery. Deal Assessment. Pipeline Review. Forecasting. Coaching. Customer Risk. Renewal Planning.

Each Skill reflects the organisation’s knowledge, experience and preferred methods. Each has been used repeatedly. Each has traces. Each has been reviewed by people. Each has improved against outcomes.

This is no longer a folder of playbooks. It is an executable representation of how the organisation performs recurring work. And because Skills are composable, they can become building blocks for increasingly sophisticated capabilities.

A Pipeline Review capability can combine Deal Assessment, Change Detection and Prioritisation Skills. A Forecasting capability can build on Pipeline Review and deal-level Skills. A Renewal Planning capability can combine Customer Health, Stakeholder Analysis and Commercial Planning. The Skill library becomes part of the architecture through which the organisation operates.

External knowledge can become executable too

There is a further implication. Not every valuable Skill needs to originate inside the company. Organisations already buy external expertise. Consulting methodologies. Sales frameworks. Management systems. Industry benchmarks. Training. Research.

Today that knowledge is usually consumed by humans. Read the book. Attend the course. Hire the consultant. Download the template. Then attempt to translate the external knowledge into company behaviour.

Executable Skills create another distribution model. An expert methodology can potentially become a Skill that operates against the company’s own State and Memory.

A sales methodology does not merely live in a training deck. It participates in Deal Assessment. An industry framework does not simply sit in a report. It becomes available when the relevant capability runs.

External knowledge becomes composable with internal context. This suggests the possibility of an ecosystem around organisational Skills.

The best methods from outside the company can become executable inside it, while remaining adapted to the company’s own judgement and environment. That is a much more interesting form of knowledge transfer than another content library.

The company begins accumulating methods

For most of organisational history, companies accumulated expertise primarily by accumulating experienced people. Those people created processes. Some processes became documents. Some became software workflows. But much of the method remained inseparable from the humans performing it.

AI allows another form of accumulation. A company can increasingly retain not only what it knows, but how it has learned to perform recurring work.

Those methods can be shared. Executed. Evaluated. Versioned. Combined. Improved. And distributed across both people and agents.

This changes the nature of process. A playbook describes how work should happen. A workflow automates a predetermined path. A Skill encodes a method that intelligence can apply to changing situations.

That distinction is small linguistically.

Architecturally, it is large.

Because once methods become executable, the organisation can begin observing not only whether work happened, but how it was performed and whether the method itself should change.

The company no longer has to treat process as static instructions surrounding the software. Process can become part of the software. And eventually, part of what the software learns to improve.