Static context is the Jedi Archives problem

You can store every meeting transcript and client note in an Obsidian vault. You can keep a folder of markdown files next to your agents, write a careful system prompt, or plug in a Jira MCP. All of it works on day one.

Then the conversation moves on. Three weeks later a decision changes in a meeting. Which file knows?

None of them. The transcript still says what was said then. The client note still says what was true then. The agent reads both and has no way to tell that either one has died.

A file has no idea that a fact inside it can change. It can’t say where a statement came from, who edited it, or when it stopped being true. And it never lives alone.

Even if your team only uses ten of those tools, that’s ten places where the same context goes stale on its own schedule. Add the rate at which business data ages, and the result is predictable: agents automating decisions on dead data, confidently, with nothing to flag it.

When we sit down with a client, this is the first thing we set up. Skip it, and everything built on top feels like quicksand.

Over the last few weeks I’ve been refining the Glasshouse framework. Its backbone is Fluree’s three-step method, Model, Map, Connect, with one step of our own added.

Model comes first. Before we touch a single piece of data, we work out the semantics and the ontology: what the things in your domain are, how they relate, and how knowledge about them actually behaves over time. A few focused conversations with your teams get there surprisingly fast.

Map takes what arrives every day, the notes, transcripts and tickets, and maps it onto that model as candidate facts, each one tied to its source.

Anchor is the step we add. Fluree’s method treats identity resolution as a detail inside Map; we give it its own step and its own acceptance criteria, one durable identity per customer, product or account. Two systems that disagree about who a customer is will produce a confidently wrong agent.

Connect makes the approved graph the thing your agents read from, whichever assistant sits on top.

With the model in place, the rest of the system can behave the way it should. Five properties do most of the work.

1. Provenance over opinion. Every entry points back to its source. “Kamino is here” has to link to the exact scout report it came from.
2. Droids draft, Jedi decide. An archive droid parses incoming notes, but a human approves each fact before it enters the core.
3. Glass walls. If someone alters or erases a fact, you see who did it and when.
4. Hard undo. Any erased fact comes back in its exact prior state.
5. Tiered context. Cantina gossip and casual notes stay in general search. The facts that could fly your team into an asteroid field get the Glass treatment.

None of this depends on which assistant you run. Copilot, Claude or whatever ships next share the same weakness: they’re only as good as what they read.

Knowledge graphs work because they’re closer to how memory works. We don’t remember in text dumps filed in separate drawers. We remember in connections, and we redraw them when reality changes. When a fact changes in a graph, everything that depends on it can see the change.

If your agents rely on static context files, you’re one un-updated document away from jumping straight into a debris field.