Executive Summary
As competition among LLM providers drives inference costs toward commodity pricing, organizations face a strategic question: where does durable value reside in an AI stack? This paper argues that value concentrates in two layers that sit above the model itself: Context, which represents structured information about users, organizations, and domains that remains portable across providers; and Capabilities, which encode domain expertise in executable format independent of any specific model.
The architecture we present allows organizations to produce domain-specific output without fine-tuning models or accepting vendor lock-in, while maintaining human oversight at every decision point.
1. Problem
Large Language Models function as general-purpose reasoning engines capable of processing arbitrary inputs and generating coherent outputs across virtually any domain. This generality comes at a cost: without access to industry-specific terminology, quality standards, and institutional constraints, model outputs require extensive human review before they can be applied in professional contexts. Four structural limitations explain why.
Generic output
A model trained on public data has no access to your organization's terminology, compliance requirements, or quality criteria. The gap between generic output and domain-appropriate output must be bridged manually, which means every response requires review against institutional knowledge that exists only in employees' heads or scattered documentation.
Context fragmentation
Organizations that use multiple AI providers face context fragmentation: custom instructions, conversation history, and learned preferences remain siloed within each platform. An organization that builds context in ChatGPT loses that investment when evaluating Claude, and loses it again when a new provider enters the market. This creates implicit lock-in without explicit commitment.
Expertise that does not scale
Domain knowledge typically resides in the heads of senior employees who become bottlenecks as AI adoption increases demand for their judgment. Every decision that requires expert review waits in queue, and junior team members cannot learn systematically because expertise transfers only through direct interaction with those same constrained experts.
Delegation without judgment
Current AI agents can execute multi-step tasks but cannot evaluate whether outputs meet organizational standards. They lack the criteria for quality that would allow genuine delegation. Autonomous execution saves time only when the executing system understands what good looks like in your specific context.
2. Solution
This architecture interposes two layers between the user and the LLM. The Context layer stores structured information about users, organizations, and domains in a format that persists across sessions and transfers across providers. The Capabilities layer encodes domain expertise as executable specifications that any authorized user can invoke, regardless of their own expertise level.
Context
User, organization, project, domain
Capabilities
Knowledge, skills, tools
LLM
Interchangeable inference layer
Figure 1. Architecture overview: Context and Capabilities layers above an interchangeable LLM.
Because both layers are defined independently of any specific model, organizations can switch providers without losing accumulated context or rewriting capability definitions. The LLM contributes reasoning ability; Context contributes situational relevance; Capabilities contribute domain expertise. Each layer can evolve independently.
3. Context
The Context layer maintains structured information that persists across sessions and transfers across providers. This decoupling from the model layer means that switching from Claude to GPT, or to any future provider, does not require rebuilding organizational knowledge.
3.1 Data Layers
Context organizes into four hierarchical layers. Personal context captures role, preferences, and communication style. Organization context stores company information, industry classification, compliance requirements, and brand guidelines. Project context tracks goals, constraints, stakeholders, and timelines. Domain context holds specialized terminology, best practices, and regulatory requirements specific to the field of work.
Personal
Role, preferences, communication style
Organization
Company, industry, compliance, brand
Project
Goals, constraints, stakeholders, timelines
Domain
Terminology, best practices, regulations
Figure 2. The four hierarchical context layers.
3.2 Design Principles
Three principles govern Context implementation:
- Ownership. Context belongs to the user, not the platform, and can be exported at any time in standard formats.
- Portability. The context layer operates independently of any specific LLM provider, so accumulated context transfers when switching models.
- Permission. The system stores nothing without explicit user approval, and every persisted element requires confirmation.
4. Capabilities
A capability represents domain expertise codified in executable format. The tacit knowledge that experts struggle to articulate becomes explicit specification that can be documented, version-controlled, transferred across teams, and scaled independently of the experts who created it.
4.1 Components
Each capability combines three elements. Knowledge contains domain expertise indexed for retrieval: decision rules, thresholds, edge cases, and annotated examples of both successful and failed outputs. Skills define procedures with specified inputs, outputs, and quality criteria that determine whether outputs meet standards. Tools provide authenticated connections to external services that the capability may need to invoke during execution.
Knowledge
Decision rules, thresholds, edge cases, examples
Skills
Procedures, inputs, outputs, quality criteria
Tools
Authenticated connections to external services
Figure 3. The three components of a capability.
4.2 Authoring
Capability creation follows a structured workflow. Experts define knowledge, skills, and tool connections through an interface that requires no programming. Before deployment, capabilities run against sample inputs to verify output quality; authors compare results to expected outcomes and refine definitions until they meet organizational standards. Completed capabilities deploy within the organization with full version control, allowing rollback and audit of how each capability evolved over time.
5. Value Economics
Competition among LLM providers is compressing inference costs toward commodity levels. As reasoning becomes cheaper, durable value migrates to layers that are harder to replicate: context that accumulates through organizational use, and capabilities that require genuine domain expertise to create. This architecture positions organizations to capture that value rather than ceding it to model providers.
| Component |
Ownership |
Value |
| LLM |
Provider |
Commodity |
| Context |
Organization + Individual |
Durable |
| Capabilities |
Organization + Individual |
Durable |
Figure 4. Value distribution across architecture layers.
6. Design Philosophy
Where current discourse emphasizes autonomous AI agents, this architecture positions the human as the agent. The system provides leverage for human decision-making rather than replacing it. Every process begins with a user request and concludes with user validation; the system amplifies capability between these two moments of human judgment but does not act independently.
Input
User submits request
→
Processing
LLM parses intent
Play New injects context + capabilities
LLM generates response
→
Output
User reviews and decides
Figure 5. The human remains the agent throughout the workflow.
Three principles follow from this stance:
- Transparency. Every output traces to its sources, and users can inspect which context was loaded, which capability was invoked, and which model produced each result.
- Reversibility. No action becomes permanent without explicit confirmation, and every operation supports undo.
- Auditability. The system maintains complete logs of what happened, when, and why, supporting both debugging and compliance requirements.
7. Getting Started
Organizations can engage with the platform at three levels:
- Users begin by browsing the capability library to find expertise relevant to their work, installing capabilities and configuring them with organizational context to adapt outputs to specific situations.
- Domain experts who want to scale their knowledge use the authoring interface to codify expertise as capability definitions, making their judgment available to colleagues who lack that specialized background.
- Administrators deploy capabilities across teams or the entire organization with full audit trail and version control; the platform supports both cloud and on-premise deployment depending on security requirements.
