AI Isn’t The Product, Context Is
Today's AI performance depends less on the model and more on the context around it. Models are infrastructure, not the product, and what we call AI isn’t really intelligence, but it still has utility.
Introduction
Despite billions in investment, 95% of enterprise AI pilots fail to deliver measurable business impact (Challapally et al., 2025). The problem isn’t the models. AI models are infrastructure, like the internet. What differentiates organisations is what they build on top of it. As capabilities converge, advantage shifts from tool selection to the quality of context and how it’s integrated into workflows. The focus should move from choosing models to shaping the knowledge around them.
Svoyski is a three-tier skills framework for encoding and deploying that knowledge.
How We Make Sense of Things
A common failure mode in AI adoption has little to do with the technology and more to do with how human sensemaking works. When making sense of things, we usually first gather input from multiple sources, reading, discussing, and absorbing information. Then, ideally, we step away from input, creating the conditions for understanding to form. The divergent phase fills the tank. The convergent phase is where the engine runs and produces a spark.
In practice, most professional environments are optimised almost entirely for the divergent phase. There’s always another meeting, message, or task. Without space for convergence, input accumulates but rarely turns into understanding. Bertrand Russell would work intensely on a problem, abandon it deliberately, and return later to solve it. Research suggests that stepping away from a problem after absorbing complex information can improve the originality of solutions (Dijksterhuis and Meurs, 2006).
This pattern is not universal. Experienced practitioners often rely on rapid pattern recognition and act without deliberate incubation (Klein, 1998). For routine problems, this probably applies to all of us. But for novel or complex challenges, unstructured reflection remains critical.
AI introduces a new failure mode. It allows us to bypass the convergent phase entirely, moving directly from input to output. The result is often fluent but shallow, lacking the judgment that comes from genuine understanding. The model cannot compensate for missing expertise, it can only amplify what is already present.
This makes our self-awareness a practical requirement. To use AI effectively, we must be able to articulate what we know, how we work, and what good looks like in our domain. But this is difficult. Many people operate on tacit knowledge they've never externalised. Developing this capability requires deliberate practice, guidance, and the right conditions.
How AI Models Work
A large language model is a statistical system trained on vast amounts of text. What we interact with today is several layers removed from that base, shaped by techniques such as reinforcement learning from human feedback and instruction tuning. These systems are neither databases nor formal reasoning engines, but they're more than simple autocomplete.
They are effective at producing coherent, well-structured text that reflects how knowledgeable people write. However, they are unreliable when tasks require precise factual accuracy, formal logic, or up-to-date information. As Bender et al. (2021) argue, language models generate plausible language without grounding in meaning. The fluency is real, but the understanding isn't. Incorrect outputs arrive with the same confidence as correct ones, and humans tend to overtrust systems that appear reliable (Parasuraman and Riley, 1997). Domain expertise remains the necessary quality filter.
Interacting With a Model
Pre-training defines what the model is capable of. It provides general language ability and broad world knowledge, and is outside the control of most organisations.
Prompting is how we interact with the model in a given moment. The structure and clarity of a prompt strongly influence the response, to the point where two users of the same model can produce meaningfully different results. More context is not always better. Poorly structured or conflicting input degrades performance. Most organisations operate only at the prompting layer.
In practice, AI functions less as autonomous intelligence and more as an interface layer between humans and computing. It allows users to express intent in natural language without needing to write code or learn formal syntax. As the barrier to interaction collapses, the limiting factor becomes the quality of the knowledge brought into the conversation.
Most disappointing outcomes come from using AI generically. Without context, the model produces outputs that reflect an average across its training data, with no awareness of organisational standards, domain constraints, or prior decisions. The shift is from using AI as a search substitute to using it as a context-aware collaborator. Skills are the mechanism that enables that shift.
Skills introduce a third layer. They are structured, reusable context injected at prompt time, but persistent enough to function as a middle layer between capability and interaction. A skill is a document or set of instructions that defines who the user is, how they work, and what standards apply. It acts as a professional briefing, grounding the model in specific expertise rather than generic training.
The Svoyski Framework
Much of what makes an expert valuable can't be fully captured in formal documentation. It exists as accumulated judgment, the ability to recognise what's wrong before being able to explain why. Nonaka and Takeuchi (1995) describe this as tacit knowledge, knowledge that is difficult to articulate yet critical in practice. Organisations consistently undervalue it because it remains invisible until it's lost.
A skill is a structured document that surfaces a portion of tacit knowledge and makes it available to a model, conditioning AI outputs toward a specific standard of judgment rather than simply completing a task. Skills reduce ambiguity in the input space. They’re not only useful for the model, but also for the person creating it. They encode how work is approached, what constraints apply, and what good output looks like in a given domain. Unlike prompt templates or documentation, a skill doesn’t prescribe steps but instead defines perspective, making expertise explicit and portable.
Skills improve AI usefulness in three ways. They constrain the solution space, reducing irrelevant or generic outputs. They align results with organisational standards and domain expectations. They also compress large amounts of tacit knowledge into a form that can be used effectively. The framework consists of three types of skills, each operating at a different level of abstraction.
General Skills
General Skills define how a discipline operates within an organisation. They encode values, standards, and patterns that define what good practice looks like, how to approach trade-offs, and which failure modes to avoid. Their purpose is not to prescribe solutions, but to shape how decisions are made. Some General Skills capture how the discipline thinks, while others define conventions and standards for tools such as Miro, Excel, Confluence, PowerPoint. Both are necessary. One ensures consistency in thinking, the other in output. Without this layer, tools and processes are applied inconsistently, and output quality depends heavily on individual interpretation.
General Skills should be owned by discipline leads and treated as living standards, reviewed regularly. The act of writing them is itself valuable, as it forces the codification of knowledge that would otherwise remain implicit.
General Skill Example
General Skill for a Tool Example
Project Skills
Project Skills adapt General Skills to a specific context. They introduce the constraints that matter for a given engagement, like domain, technology, team structure, and stakeholder expectations.
If General Skills define values, Project Skills translate those values into principles that guide decisions in context. Project Skills do not eliminate trade-offs. They make them explicit. When different considerations conflict, the model can surface the tension, but resolution remains a human responsibility. Project Skills are owned by the project lead and evolve alongside the project. Their primary function is to ensure that anyone working within that context, human or model, operates with the same understanding from the outset.
Project Skill Example
Personal Skills
Personal Skills capture how an individual works in practice, reflecting habits, heuristics, and decision-making patterns developed through experience. While General and Project Skills define what matters, Personal Skills define how it's applied in practice. They are the most powerful and the most difficult to develop. In most cases, they emerge over time rather than being written fully formed.
Personal Skills are portable. They move with the individual across projects, allowing their way of working to remain consistent even as context changes. At the same time, they introduce diversity. Different individuals with the same role will encode different approaches, which is essential for avoiding uniform thinking. Borrowing another person’s skill can be a useful starting point, but it cannot replace the development of one’s own. A borrowed skill reflects someone else’s judgment and may propagate their blind spots if adopted uncritically. As Page (2007) argues, groups that bring diverse perspectives and problem-solving approaches tend to outperform more homogeneous ones, even when individual ability is held constant.
Personal Skill Example
How Skills Work Together
In a typical session, three skills are loaded into the same context window and read together by the model. Each operates at a different level. The General Skill establishes discipline-level values. The Project Skill introduces the constraints and principles specific to the engagement. The Personal Skill reflects how the individual works in practice. Together, they shape the response before the task is even considered.
This structure makes conflict visible. When different considerations pull in different directions, the tension is surfaced rather than resolved implicitly. A Project Skill may override a General Skill on specific decisions, but not on underlying values. The distinction lies in levels of abstraction, which allows the system to remain coherent even when trade-offs are present.
The specific combination of skills varies by individual. A product manager and a front-end engineer working on the same project share the same Project context but bring different General and Personal Skills. The result is alignment on what matters, combined with variation in how it's approached. Context isn't shared between sessions in real time, so consistency depends on the skills being maintained rather than on conversation history. The Project Skill acts as the connective layer, ensuring that different contributors operate with a compatible understanding of the same environment.
Skills provide the model with values, constraints, and standards, while the prompt defines the immediate objective, whether that's a specification, a bug report, or a design task. The model produces a first pass, which is then reviewed, tested, and refined by the human. What remains is the work that requires judgment, deciding whether the output fits the system, reflects user needs, and holds under constraints that the model cannot fully see.
The effect is a reduction in the distance between thinking and output. The model handles the translation from intent to draft, while the human focuses on meaning and correctness. The role shifts. What becomes more valuable is the ability to recognise what good looks like in context and to intervene where the model falls short.
Continuous Improvement
Skills are a practice, not a project. A skill that’s not maintained quickly becomes a liability, because it provides outdated context with a high degree of confidence. Knowledge evolves, projects change, and individuals develop new expertise. Skills need to be reviewed and updated over time in the same way a codebase is. When AI output degrades, the first question is not whether the model has changed, but whether the underlying skill is still current.
Maintenance happens at different levels. Personal Skills are revisited as individuals refine how they work or move between roles. General Skills evolve more slowly and reflect changes in discipline standards over time. Project Skills shift with the lifecycle of an engagement, adapting as context changes and eventually becoming a record of how the work was done.
Unlike traditional documentation, the cost of staleness becomes visible through use. When a skill is outdated, the quality of AI output deteriorates in ways that are difficult to ignore. This creates a feedback loop that encourages maintenance, although it doesn’t guarantee it. The system still depends on deliberate ownership and attention.
The framework doesn’t introduce a new layer of responsibility so much as it makes existing ones more explicit. Ownership remains with those already responsible for delivery quality and professional standards. Maintenance can be integrated into existing routines, rather than treated as a separate process.
For this to work in practice, three conditions need to be met. There must be infrastructure that makes skills easy to store, version, and load into AI interactions without friction. There must be guidance that helps individuals understand what a good skill looks like and how to develop one. There must also be time set aside for this work, treated as part of the job rather than an additional burden. The space for sensemaking. Small, regular updates are more sustainable than large, infrequent efforts, and organisations that succeed with this approach are likely to embed it quietly into existing practices rather than enforce it through heavy process.
The Extended Mind
In 1998, Andy Clark and David Chalmers argued that the boundary of the mind doesn't end at the skull. When we use external tools to store, process, or manipulate information, those tools become part of the cognitive system. Their example is a notebook. A person who consistently uses one to store and retrieve information isn't cognitively worse off than someone who remembers everything internally. The notebook performs memory functions. Writing something down is not just record-keeping, but part of the thinking process itself.
For a tool to qualify, occasional usefulness is not enough. It must be reliably available, easily accessible, and used with a degree of automatic trust. Clark later expanded this idea by arguing that tools become genuinely cognitive when they become transparent through habit, when we stop thinking about the tool and start thinking through it. A notebook that is consistently carried and used meets this standard.
This creates a constraint for the skills framework. A skill that must be remembered, manually loaded, or frequently questioned is a weak cognitive extension. If it's outdated or difficult to maintain, it loses its effectiveness. The framework doesn't avoid this problem. It depends on the conditions described earlier, where skills are accessible, maintained, and integrated into regular practice.
What This Means For AI
Unlike a notebook, a language model doesn’t just store information. It transforms what it’s given and applies it to new situations. Hutchins (1995) described this kind of system long before AI, where cognition is distributed across people and tools. A ship doesn’t navigate on its own. The crew, instruments, and shared context together form a system more capable than any one part.
A skills framework applies the same principle to knowledge work. When an engineer loads their Personal Skill, a relevant General Skill, and a Project Skill, they extend their professional mind into the tool. The result is a system more capable than either the person or the model alone.
Without that context, the model produces generic output. Using it is like working from someone else’s notebook. The information may be coherent, but it lacks relevance and grounding. The model isn’t the value. The knowledge that surrounds it is.
Conclusion
Most knowledge workers already externalise expertise into shared tools. Architecture decision records, onboarding guides, code review standards, internal wikis. The habit is already there. The skills framework is a more deliberate, AI-native version of the same behaviour, where what we write doesn’t just describe how we work, it works alongside us.
Most organisations will discover that the models aren't the differentiator. They might invest in the tools, see underwhelming results, and conclude the technology isn’t ready. The technology is ready. The question is whether the knowledge infrastructure around it is.
Domain expertise is the precondition for using AI well. A model can’t verify its own outputs, decide which problems are worth solving, or recognise when a plausible answer is actually wrong. The human in the loop isn’t a legacy cost to be eliminated, but the quality filter the system depends on.
The right historical parallel is the assembly line. It didn’t replace workers. It restructured what they did, removing the overhead of moving parts between stations so each person could focus on the work only they could do. What disappeared was the wasted motion between the valuable work.
AI can remove that same wasted motion in knowledge work. The time spent on first drafts that exist only to be rewritten, searching for information that already exists somewhere, re-explaining context to a tool that doesn’t remember. What remains, and grows in importance, is judgment. Domain knowledge. The ability to ask the right question and recognise the right answer.
References
Bender, E.M., Gebru, T., McMillan-Major, A., & Shmitchell, S. (2021). On the Dangers of Stochastic Parrots: Can Language Models Be Too Big? FAccT '21, 610-623.
Challapally, A. et al. (2025). The GenAI Divide: State of AI in Business 2025. MIT Project NANDA.
Clark, A., & Chalmers, D. (1998). The extended mind. Analysis, 58(1), 7-19.
Dijksterhuis, A., & Meurs, T. (2006). Where creativity resides: The generative power of unconscious thought. Consciousness and Cognition, 15(1), 135-146.
Hutchins, E. (1995). Cognition in the Wild. MIT Press.
Klein, G. (1998). Sources of Power: How People Make Decisions. MIT Press.
Nonaka, I., & Takeuchi, H. (1995). The Knowledge-Creating Company. Oxford University Press.
Page, S.E. (2007). The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools, and Societies. Princeton University Press.
Parasuraman, R., & Riley, V. (1997). Humans and automation: Use, misuse, disuse, abuse. Human Factors, 39(2), 230-253.