Inside Glasshouse, the context layer we run on
Why we built Glasshouse, how a sentence in a note becomes a fact an AI agent can trust, and what it costs to run, in eleven screenshots.
In the last essay I argued that static files can’t carry context for AI agents, and that what you need underneath them is an archive that knows where every fact came from and when it stopped being true. Then I stopped at the theory.
This is the build. Glasshouse is the context layer we run House of [MAAD] on: 64 notes, 339 checked facts, and a graph our agents read from instead of a folder of markdown. Here is why we built it, how a sentence in a note becomes a fact an agent can trust, and what that costs.
Why did we build Glasshouse?
Because our own files started disagreeing with each other.
When we relaunched [MAAD], the letters changed meaning. They used to stand for MarTech, AdTech, AI and Data. Now they stand for Meaning, Anchor, Agents and Decision, with Guardrails as the brackets. The new meaning went into the Claims Register, the note where every claim we have made in public is written down once. A README from 22 September still filed Guardrails under the old MAAD Stack.
Both files were right on the day they were written. An agent reading the vault had no way to know which one was still true, so it would have used both. That is the Jedi Archives problem, in our own house, less than two weeks after I wrote about it.
Where does the context come from?
Glasshouse doesn’t replace the places we already write in. It reads them, and each source has its own rule for who may read it.
The Obsidian vault is watched on the server, read-only. Google Slides decks come in through n8n every hour, but only the ones picked on the Decks screen. Gmail comes in through n8n every 30 minutes and is read by a local model only: if the Mac is asleep, emails wait. They never go to Claude.
The server itself calls no model at all.
Claude reads what’s waiting over MCP, on our own subscription, through one prompt on the Glasshouse MCP server. That keeps the expensive, fallible part (reading prose) outside the system, and the part that has to be right (deciding what counts) inside it.
How does a note become a fact?
Every note goes through the same four steps.
- Claude proposes. It reads the note and proposes facts and, now and then, a new concept.
- Every quote is checked word for word. A proposed fact has to carry the sentence it came from, and that sentence has to be in the note, exactly. A paraphrase doesn’t get in.
- Names are matched to the graph, then the rules check each fact against the model. The matching is the Anchor step: the Guardrails in a README and the Guardrails in the Claims Register have to resolve to one thing, or the contradiction further down never surfaces.
- Most facts go in by themselves. What the rules can’t decide goes to Review.
Of the 339 facts in the graph today, 290 went in by themselves and 49 by a decision of mine. Droids draft, Jedi decide, and the Jedi only see what the droids couldn’t settle.
What decides what counts as a fact?
The model. Before anything is read, we define what the things in our business are and how they relate: offerings, engagements, frameworks, pieces, proof points, decision points. The first version came out of a single interview on 21 September. Today the business model has 18 concepts and the tech stack model 5.
The model is defined once, and it grows only when I approve. When Claude finds something the model has no place for, it doesn’t invent a field. It proposes the change, and the proposal waits under “Waiting for you”, with a preview of what publishing the next version would do.
Each concept also carries rules for its facts. A framework needs a quote, its source item and a date. Some relationships hold several values; others hold one at a time, and a new value has to replace the old one explicitly.
The order of work isn’t ours. It is Fluree’s Model, Map, Connect: model the domain first, map what arrives onto that model, then connect the result to the people and agents who use it.
Our version adds one step. Fluree’s method treats identity resolution as a detail inside Map. We make it a step of its own, Anchor, with its own acceptance criteria, because two systems that disagree about who a customer is will produce a confidently wrong agent.
That is also where the method meets [MAAD]. [MAAD] is the architecture: what has to exist. Model, Map, Connect is how each layer of it gets built, one use case at a time.
| Layer | Phase | What gets built |
|---|---|---|
| Meaning | Model | Concepts, relationships, controlled vocabulary |
| Anchor | Map, as a step of its own | Row → instance, key → relationship, one durable IRI per entity |
| Agents | Connect | MCP tools, GraphRAG retrieval, tuned behaviour |
| Decision | The competency questions | The business outcome the questions were written for |
| Guardrails | All three | Shapes and policy written in Model, enforced in Connect, checked before release |
Glasshouse is that method, run on our own notes, on Fluree’s graph database.
What happens when two notes disagree?
They land in Review, side by side, and nothing changes until someone decides.
This is the [MAAD] relaunch from the start of this piece, caught by the rules. “Guardrails” is a layer of something, and that relationship holds one value at a time. The README says it belongs to the old MAAD Stack, the Claims Register says it belongs to MAAD. Glasshouse doesn’t pick one. It asks: new replaces old, keep old, or both true. One click, recorded in my name.
Review holds 54 items right now: 6 new concepts, 19 possible duplicates, 10 contradictions and 19 uncertain facts. At about 90 seconds each, that is 81 minutes of my time to clear the queue.
Can you trace every fact back to a sentence?
Yes, and that is the point of the whole build. Click any fact and Glasshouse shows where it came from.
The sentence, highlighted in the note it came from. The source file, its revision and the line. Who read it, and in which run. Which version of the model it was checked against. Why it was let in: it fit the model and passed every check. When it became true, and when we learned it.
Those last two are different dates on purpose. A fact can be true from Monday and only reach us on Wednesday, and an agent asking “what did we know on Tuesday?” deserves the honest answer. The ledger keeps both, so you can drag a slider back to any date and see what the graph held then.
What does an agent get when it asks?
Not a blended paragraph. Every part of an answer keeps its label.
An answer comes back in three columns: checked facts, which are in the graph with a source and a date; notes to reuse, which are where those facts came from; and unverified mentions, which are in the notes but were never checked. When we asked what House of [MAAD] offers and which proof points back it up, four of nine sentences came back as checked facts, four as uncertain, and one as not found. The agent knows which is which, and so do I.
Is it worth it?
Here is what Glasshouse costs us.
Ingesting a note costs nothing: no model runs on the server, so 1,000 notes cost €0.00 in tokens. Claude’s reading runs on a subscription we already pay for, and the API spend on the Today screen reads $0.04. The one-time costs are a 23 MB model download and a few seconds of local CPU per 1,000 notes.
The real cost is my attention: 271 review decisions so far, and an 81-minute queue when I let it pile up. In exchange, 75% of the notes in the vault now hold at least one live fact, and the graph grew from about 110 facts on 2 October to 339 on 15 October.
Every morning, Glasshouse also asks a few questions back. Is the status of a draft from June still true? A question I asked on 14 October has no checked fact to answer it: what is missing? A static file never asks you anything.
Can we build one for you?
Yes. Glasshouse is what House of [MAAD] runs on, and it is the working version of what we build for enterprise brands.
Yours wouldn’t be a copy of ours. The model would hold your offerings, your customers and your decisions, and the sources would be the places your teams already write in. The method stays the same: model the domain first, map what arrives onto it, anchor every name to one thing, and connect the result to the people and agents who use it.
That’s what we build at House of [MAAD]: the context layer underneath your agents, where every fact can be traced back to the sentence it came from.
Frequently asked questions
- What is a context layer for AI agents?
- A store of checked facts that sits underneath your agents and that they read from instead of raw files. Each fact carries the sentence it came from, its source and the date it became true, so an agent can tell a live fact from a dead one.
- How do you build a context layer for AI agents?
- Define the model first: what the things in your business are and how they relate. Then let a model like Claude propose facts from your notes, check every quote word for word against its source, match every name to one identity, let rules admit what fits, and send what they can’t decide to a human. Glasshouse stores the result in a graph database, FlureeDB.
- How is a context layer different from RAG?
- Retrieval hands an agent text that looks relevant, whether or not it is still true. A context layer hands it facts that were checked against a model, each with its source and validity dates, and keeps checked facts, notes and unverified mentions apart in every answer.
- Does Glasshouse send my data to an AI model?
- The server calls no model at all. Claude reads the notes waiting in the queue over MCP, on your own subscription, and email is read only by a local model on your own machine; it never goes to Claude.
- What does it cost to run?
- Ingesting a note costs nothing in tokens, because no model runs on the server. The real cost is human attention: in our case 54 open review items, about 81 minutes at 90 seconds each.
What would your agents get wrong if one fact in their context died today?
Tell me