Building midland, a shared context layer for AI agents. Agents guess what your company's words mean and reconstruct context live in every chat. I built a deterministic layer they read over MCP instead: answers arrived roughly fifteen times faster on a tenth of the tokens.

An eight month solo project, driven by a deep interest in context engineering. I have deployed adapted versions of it with individual companies, and I am reworking it into an open source system I intend to make public.

The problem. Ask Claude or ChatGPT "which of our enterprise accounts are at risk?" and watch what it has to do. It must first work out what your company means by "enterprise" and by "at risk". It usually can't, so it either interrogates the person asking or quietly guesses. Then it builds its own filters, pulls records over MCP from your CRM, fetches whatever it thinks signals risk, does the math, and hands you an answer. Every step is a chance to be subtly, confidently wrong. Two coworkers asking the same question can get two different answers, because they don't share definitions either.

I watched this play out while helping smaller companies, around forty to fifty people, get started with Claude and ChatGPT. The recurring failure was not the models. It was data access. Reconstructing context through live MCP calls in every conversation is slow, expensive, and unreliable. When an answer takes a long time to arrive and then turns out to be wrong, people stop trusting it. When they stop trusting it, they verify everything by hand, and at that point the tool has added work instead of removing it. That trust break is what kills adoption, and I saw it repeatedly.

Large companies solve this with a data team: pipelines keep metrics fresh, a semantic layer holds the definitions, and a team owns the whole thing. Most companies don't have that and won't. My starting question was whether a thirty to seventy person team can give their AI the same grounded understanding of the business without a data team, without a six month project, and without anyone becoming a data engineer.

The bet. My broad thesis is that companies win with AI in two ways. Either they build an AI-native service in a specific domain, or they operate in an existing market and use AI to lower cost, improve customer experience, and reduce latency. I focus on the second group, because that is where shared context is the bottleneck. This is not a problem I discovered alone. Frontier labs and a wave of open source projects are circling the same gap. Midland is my specific bet on how to close it, shaped by my own observations with real teams.

I built it for two reasons. I wanted a deliberate deep dive into shared context by building the real thing rather than reading about it. And I had seen the problem firsthand in consultancy work, watching teams re-explain the same context to agents over and over.

What I built. Midland is a shared context layer that AI agents read over MCP. The core design decision is that it is deterministic: integrations write data into the layer on a schedule, so agents read pre-computed answers instead of reconstructing them live in every chat.

The context model splits into two kinds of pieces, loosely inspired by atomic design.

Atoms are raw facts. A metric fetched and aggregated from your tools: a number, a date, a list. Or a phrase: what your company means by a word like "trial" or "active user", written by a person or drafted from existing docs and confirmed. Small, clear pieces anyone can read and edit.

Molecules are what you build from atoms. Rules, concepts, and processes. "Enterprise" is company size above a threshold. "Active" is last seen under four days and adoption above sixty percent. These are exactly the things AI gets wrong when left to guess, and exactly the things a team actually holds opinions about.

With this in place, "which enterprise accounts are at risk?" becomes a few calls returning pre-calculated values the model never had to interpret. The definitions were set once, by the team. The AI reads the answer instead of inventing it.

Two deliberate tradeoffs sit inside this design. First, data is frozen into a daily snapshot rather than fetched live. For account reviews and planning, a stable picture everyone shares beats a number shifting mid conversation. Live tools remain available for surgical tasks; the snapshot is the default, not the only path. Second, a system this constrained gives up serendipity. An AI left to guess will sometimes surface things you didn't think to ask for. Midland trades some of that away for consistency and trust in the everyday answer.

Every value carries its source and a timestamp, so when the AI states a figure, you can see where it came from and when. That removes a surprising amount of second-guessing.

What I measured. I ran comparative experiments with Claude Code, testing Midland's snapshot layer against unstructured live MCP retrieval on the same questions. Two results held clearly: responses arrived roughly fifteen times faster, and input token consumption dropped to roughly ten percent of the unstructured baseline. The mechanism is unsurprising once you see it. The unstructured path pays for schema discovery, multiple retrieval rounds, and raw records in context on every question. The snapshot path pays for none of that at query time.

Hallucination was harder to reduce to a single number, and I decided that a one-time percentage was the wrong instrument anyway. What matters in deployment is not whether faithfulness was good on launch day but whether it stays good as models and data change underneath the system. So instead of a benchmark, Midland ships with a nightly evaluation harness. Every night it replays a fixed set of fifteen ground-truth questions, ones with known correct answers, including trap questions where an undefined term invites a confident guess. It runs against the models the deployment actually uses, currently Sonnet and Opus, and checks the answers against ground truth. All questions pass and the run goes green. Any failure produces a report flagging what drifted. Both the question set and the model set are configurable per deployment, because the right traps depend on the company's own language.

Honest state of that loop: today a human reads the report and revises the definition or the data. The system flags drift; it does not yet fix it. Self-adjustment is a direction, not a claim. The design principle stands regardless: faithfulness is a monitored operational property, not a launch metric.

The human half. I approached this from two directions at once, and the second one is where my background as a designer did the most work.

The technical direction says: make the layer deterministic and the trust problem shrinks. The organizational direction says: context management cannot land solely on a data team, because the people who actually know what "churn risk" means work in sales, support, and operations. So Midland is also a surface where non-technical people can see, edit, and agree on definitions. A salesperson can correct a threshold. An ops lead can rewrite what "onboarding complete" means. Different domains collaborate on the same shared vocabulary without touching code.

The obvious risk is one more wiki that goes stale. That is the real test of the whole idea, and my answer is to make upkeep mostly the AI's job: agents that suggest metrics and definitions from your existing docs, that turn a typed sentence into a new piece of context, and that notice when the AI keeps reaching for a word nobody has defined. A person still decides. They approve suggestions rather than authoring a data model from scratch. Whether this stays light enough to survive real use is an open question, and I say so.

From SaaS to open source. I started thinking about Midland as a hosted SaaS product. After working alongside companies, I changed my mind. The context layer holds a company's most sensitive operating knowledge, and the teams I worked with wanted it close, inspectable, and adaptable, not rented.

So I am reworking Midland into an open source system, with documentation written for agents as much as for people. Clear guardrails in markdown, a clear design language, explicit deployment and database schemas. The intent is that a company points Claude Code at the repository, and Claude Code understands the system well enough from the documentation to deploy and adapt it to their stack. This makes the project a second experiment layered on the first: a test of what on-prem, agent-installable open source infrastructure looks like. Keeping it open keeps me learning, because I can keep adapting it with different companies and, once public, watch others adapt it in directions I would not have chosen. The project lives at getmidland.tech.

What building it taught me. Three things I would carry into deployment work.

The trust problem is a data problem before it is a model problem. Nearly every failure I observed traced back to the agent guessing at meaning or reconstructing state it should have been handed. Fixing the substrate did more than any prompt engineering.

Shared understanding is negotiated, not extracted. The hard part of a definition like "at risk" is not encoding it. It is getting sales and support to agree on it, and building a surface where that agreement is visible, editable, and owned by the people it describes. The moment the definitions became something non-technical people could touch, the conversations changed from "the AI is wrong" to "our threshold is wrong". That shift is the whole game.

Durability beats benchmarks. A system that was right once proves little. A system that checks itself nightly against ground truth, and tells you when the world has drifted out from under it, is something an organization can actually build on.

I left a designer role to explore context engineering because it sits exactly where my background in design and data pointed. Midland is what that exploration produced: a concrete, measured answer to how a small company gets its machines and its people to mean the same thing when they use the same words.