00-core
Rules
How we do things. Beats everything below. A methodology never lives in a log.
AI OPERATING MODEL · v1
Internal Framework · Proposed
How we work with AI & agents.
A three-tier operating model for delivering consulting with AI. It separates the domain knowledge we own, the facts of each engagement, and the practice of feeding both to an agent — so our advantage compounds instead of leaking into one-off prompts.
AUTHOR · Jorge Cubillos SCOPE · Kontext BASIS · Ontology & context engineering
The premise
An agent is only as good as the structure of what you give it.
The industry has settled on a hard lesson: models need context and meaning, not more clever prompts. The value isn't the model — it's the structured knowledge layer underneath it. An ontology defines what things are and how they relate; context engineering is the practice of selecting and ordering that knowledge for a task. Kontext's edge is a codified version of both, expressed as skills and project structure that agents actually consume.
This document names the three tiers, maps everything we already build into them, and states the one rule that keeps an agent from contradicting itself.
The model
Three tiers
Every artifact we produce belongs to exactly one tier. Knowing which tier you're in tells you where it lives, who owns it, and how often it changes.
01
Ontology / Schema tier — what exists & the rules
The domain model. Our IP.
The concepts, relationships, and rules of a domain: what a customer is, how an RFQ becomes a PO, how Chilean VAT must be declared, how we run a project. This is the codified judgment of a senior consultant — stable, reusable across clients, and the hardest thing for anyone to copy.
reusable skills00-core/ methodologyconventionsglossary
Maps to the ontology T-Box — the schema. Changes rarely. Owned by Kontext, not the client.
02
Knowledge / Instance tier — what is true here
The facts of this engagement.
The asserted truth of one specific client: their requirements, the decisions made (with the reason), their architecture, their stakeholders. Regenerated per engagement. It applies the schema from tier 01 to a concrete situation.
10-knowledge/requirementsdecisions (ADR)architecturestakeholders
Maps to the ontology A-Box — the instances. Changes per project. Belongs to the client engagement.
03
Context-engineering tier — how we feed the agent
The practice that wires it together.
How we select, order, and present tiers 01 and 02 to an agent for a given task — the short always-loaded entry file, the precedence rule, the curation that keeps the folder clean. It's a practice, not a platform: lightweight, in markdown, no graph database required.
AGENTS.mdprecedence rulememory.mdcontext-curator skill20-log/ (fenced history)
The operating discipline. Changes as we learn. The thing that makes 01 and 02 usable by a model.
The bridge to ontology
Why this is ontology-shaped — and why that's the point.
The formal discipline of ontology exists to solve one problem: stop meaning from being order-dependent. Our structure solves the same problem at the altitude of a consulting project, without the heavy machinery.
| Formal ontology | What it means | Our equivalent |
|---|---|---|
| T-Box | The schema: classes, properties, rules — what may exist and how. | 00-core/ + reusable skills |
| A-Box | The instances: the specific asserted facts populating the schema. | 10-knowledge/ per client |
| Business glossary | The human-readable layer the ontology makes machine-readable. | 00-core/glossary.md |
| Constraint / precedence | Rules that make resolution deterministic when two definitions collide. | lower-number-wins rule |
| Ontology snippet | A dynamically selected subset loaded for a specific task. | short AGENTS.md, loaded every turn |
The failure this prevents
Without explicit structure, an agent picks whichever definition it encounters first.
The canonical argument for ontology — and the exact reason for the precedence rule
The one rule
When two files disagree, the lower number wins.
10-knowledge
Facts
What is true and decided. Beats history. A decision lives here with its reason, once.
20-log
Events
What happened, dated, append-only. Never a source of truth — fenced off so it can't pollute meaning.
This is how an agent resolves a conflict deterministically instead of by reading order. It is the same move an ontology makes with formal constraints — just expressed in folder numbers a human can read at a glance.
Why build on this
Three arguments.
01
It's where the field is converging.
Enterprise tooling has reframed the AI problem as a knowledge-structure problem, not a model problem. Codifying expertise so machines can use it is named as the differentiator. We've been doing it for two years — now we have the language to sell it.
02
It separates lookup from reasoning.
A connector is for lookup; the knowledge layer is for reasoning. Connectors are commodity. The codified reasoning layer is the moat. This is the spine of the argument that our advantage is methodology, not plumbing.
03
It scales without rewrite.
Load only the slice of knowledge a task needs — the short entry file every turn, detail on demand. The design already follows the scaling pattern the research recommends. It grows by adding instances, not by rebuilding.
Deliberate boundary
Applied, not academic.
We don't need OWL, RDF triples, or a graph database. A full “context operating system” is easier to name than to build. Our value is the applied ontology — a senior consultant's judgment, in markdown and skills an agent consumes today. The formal machinery is for integrating hundreds of systems, not for running excellent engagements. Keep it lightweight on purpose.