Context your agents read and cannot quietly rewrite
A governed context layer for AI tools. Canonical facts live in Git, every one carries where it came from and when it was true, and a change arrives as a proposal a person reviews. It governs our own context today. The product is expected in fall 2027.
- Status
- Running on our own context
- Product launch expected
- Fall 2027
An agent is only as good as what it was told
Most teams give an assistant a folder. Contracts, notes, an export from last quarter, three versions of the same policy. The model answers confidently from whichever one it found, and nobody can tell which that was.
The failure is not the model. It is that the context had no owner. A fact with no source cannot be checked. A fact with no date reads as current forever. And an agent allowed to write back into its own context can turn its own mistake into tomorrow's canonical answer, which is the one failure mode that compounds.
- Two assistants answer the same question differently and both cite nothing
- A superseded document is still the one retrieval keeps finding
- Nobody can say which version of a fact is the current one
- An agent wrote something into the knowledge base and no person saw it
- Moving to a different model means rebuilding the context from scratch
What it does
Seven mechanisms the design commits to.
- Canonical context in Git
- Context is a reviewed artifact in a repository, with the history, the diff and the blame that comes with one. There is one canonical version because there is one branch that counts.
- Reads are open, writes are proposals
- An agent reads everything it is permitted to see and writes nothing directly. A change arrives as a proposal on a branch and merges when a person approves it, so only approved context ever reaches a chat assistant, a coding agent, an IDE copilot or an internal tool. Human review is the mechanism, not a setting somebody can switch off.
- Provenance on every fact
- Each assertion carries where it came from. An answer built on it can be traced back to the document, the conversation or the decision that put it there.
- Source and confidence kept apart from the claim
- A verified fact, a self-reported one and an inference are stored as different things. A system that flattens those three into one is how a guess becomes a quoted number.
- Temporal validity
- A fact records when it was true. Something that was correct in March and is wrong now reads as stale instead of reading as current, which is the difference between an outdated answer and a wrong one.
- Separated domains, least privilege
- Personal, work and client context are separate domains, and a section can be marked so that agents never read it and never reconstruct it. What any one tool may see is a decision somebody makes once and can audit later.
- Vendor portability
- The context layer is not a feature of one vendor's assistant. Changing model or tool does not mean rebuilding what you know, which matters on the day a provider retires a version you depend on.
Where the boundary sits
Three domains in, one review gate, and only what passed it reaches a tool.
Separated domains
- Personal
- Work
- Client
Human review gate
- provenance
- confidence
- approval
Approved context only
- Chat assistants
- Coding agents
- IDE copilots
- Internal tools
Not approved
A change that fails review stays on its branch. Nothing downstream sees it, and nothing downstream has to be told to ignore it.
Personal, work and client context are kept as separate domains. Every proposed change passes through one human review gate, which records provenance, confidence and approval. Only approved context reaches connected chat assistants, coding agents, IDE copilots and internal tools. A change that fails review stays on its branch and reaches nothing.
Why this is not only our problem
The same pattern applies wherever an organisation wants AI tools connected to internal knowledge without handing that knowledge to one vendor, losing track of where a fact came from, or letting a model quietly rewrite something people depend on. We built it because we needed it. We are describing it because the shape of the problem is not ours alone.
What to expect, and what not to
The scope of a first release is worth stating plainly, because the gap between what a product does and what a launch post implies is where trust goes.
At launch
- a Git-backed canonical context store
- the proposal and review path for every write
- provenance, confidence grade and validity window on each fact
- partitioning, with sections agents cannot read
- read access for the AI tools we use ourselves
Not at launch
- a hosted multi-tenant service
- a graphical editor for anyone who would rather not see a diff
- automatic ingestion of an existing document estate
- an integration catalogue
- anything resembling a compliance certification
Is this the problem you have?
CanonOS came out of running AI tools against our own context and not trusting the answers. If that is familiar, tell us how it shows up in your week. We reply within two working days, and we will say plainly whether this is the thing that would help or whether something we already build is.
Discuss a problem