Home / Midland

designing for agents.

Midland is a shared context layer for the unstructured content created in AI sessions and automated agent runs. It gives that content a structure that people and agents can understand, update and use across different AI tools.

Problem

None of the memory solutions worked multiplayer, and all eventually drifted, bloated and went stale.

Approach

A Linear-inspired typed data model served over MCP, tested against several models in a harness.

Outcome

Continuous experimentation to build self-improving workflows and accumulated knowledge.

I designed and built a typed data model inspired by Linear, served over MCP, and a visual application. I test it against several models in a harness that agentic loops maintain.

Local markdown files worked reasonably well at first, until they began to drift and maintaining them became a growing task. With other memory tools, I found it difficult to understand where information ended up and whether an agent would find it when needed.

While working on a farm data project with Agronod and my brother, who isn't technical, I tried to share the context I'd developed with my agents. That was much harder than expected. My setup worked for me because I understood how it was organized, but he couldn't pick it up and continue where I'd left off.

At the same time, I was spending hours in AI sessions doing research, making decisions and working through problems. These sessions produced information I wanted to keep somewhere another agent or person could find it.

My first idea was to fetch information from existing systems and serve it to agents over one MCP. Over time, I became more interested in saving what AI sessions themselves produced. That was increasingly where my work was happening.

Of the systems I used during development, Linear over MCP was often the most reliable source of information for agents. Its issues had identities, states, relationships and owners. An agent could discover those properties rather than infer them from loosely organized documents. I wanted to see whether a similar approach would work for other kinds of context.

Midland took shape around terms and metrics, files, collections and skills, each with rules about how information should be saved and used. A metric, for example, has a definition and a source. I wanted the agent to retrieve those along with the number, rather than work out what it meant from whatever documents happened to be available.

I also experimented with connecting instructions to the context they required, so a skill describing how to perform a task could point to the definitions, metrics or documents needed to complete it.

I spent a considerable amount of time working on Midland's MCP tools. Each tool had a name, description, arguments and possible errors. An agent had to interpret these and decide when to use the tool, what information to provide and how to respond to the result.

Relatively small changes to the descriptions could have a large effect on behaviour, so I built a test system to investigate this more systematically. I compared phrasing, the number of tools and the order instructions were loaded, then added checks that ran across models when I changed the code.

When an agent failed to retrieve information or answered incorrectly, I could change a description, instruction or part of the data structure and run the test again. Smaller models were particularly useful here. They often struggled with instructions that more capable models could interpret correctly.

I found this interesting from a design perspective because the tools and instructions were an interface agents interpreted on behalf of people. I could observe where they misunderstood it and revise the interface based on their behaviour. I logged every agent mistake in Midland, which created few-shot examples used to improve tool descriptions.

The checks above run when I change the code. The content changes far more often, and it drifts the same way my local markdown files once did. So Midland runs loops: scheduled agent runs that act as their own member of the workspace. Each loop follows a skill, writes through the same tools as any other agent and records what it did. Its changes show in an item's history like anyone else's.

A loop asks a fixed set of questions with known answers, across several models, and scores the answers. It's the same harness, pointed at the content instead of the code. When an answer drifts, the loop records which item misled the agent and why, so a wrong answer becomes something I can fix.

A loop exports the workspace to a git repository daily. I wanted the context to be backed up outside Midland, with history but no conflicts to resolve. Owning the content is a must for this product category.

Some drift is quieter. A decision gets superseded, or a text still quotes something that was archived. A loop reads across items for those and for plain contradictions. It doesn't rewrite anything. It adds a flag the next reader sees, agent or person, and the owner decides.

Most upkeep is specific to a workspace, so any skill can run as a loop. One completes records that were saved half-finished. Another breaks up long content, like call transcripts, into specific knowledge such as decisions, product feedback and customer relationships.

Initially, I wanted people to work through the AI tools they already used. They could ask an agent to save information, retrieve it later or share it with another person.

This let me concentrate on the data model and agent tools, but people outside my own workflow had difficulty understanding what was happening. Through a conversation, they could retrieve individual pieces of information. They couldn't easily see what existed, what was missing or whether an agent had organized something incorrectly.

I knew the model and its assumptions, so I could usually work out what was going on. Someone encountering Midland for the first time didn't have that understanding.

I eventually built a visual application for inspecting and maintaining the context. I started with the questions I kept asking myself: what was in the workspace, what my agents relied on, what needed attention and who had changed what.

The overview groups items by category and type, with activity showing what gets read and updated. Opening an item shows its content, owner, permissions and writing conventions. Its history records who read or changed it, through which AI tool and when.

I still wanted agents to handle most of the interaction, but people needed a way to inspect and correct what they were doing.

I got six companies to try Midland in small groups, to see whether it could solve a problem beyond my own use. The pilots exposed weaknesses my technical experiments hadn't.

Setup was difficult. Some participants got started independently, while others needed substantial help. Most people I spoke with preferred a hosted product they could sign into over a project they could download and adapt, which was a parallel thesis I wanted to test.

The companies also wanted different things. A “company brain” could mean answers from internal documents, preserving knowledge or making workflows available to agents. In several cases, the immediate problem could probably have been addressed with something simpler than Midland (or not by any AI at all).

The problems I focused most on solving were for people who had already adopted AI into their day 2 day. Working with companies at different stages of adoption pulled me toward a broader set of needs, including helping people get started with AI at all. Understanding where they were required conversations and earned trust, and I had to decide how much of that work I wanted to take on.

I closed the pilots and settled on the technical side of managing shared context. I was building Midland as a side project, and the broader adoption work was taking me toward running a consultancy.

Because building software with AI had become faster and cheaper, I allowed myself to explore too many possibilities. There was always another experiment worth running, another tool to refine or another part of the model to improve. Since I was learning from each one, it was easy to justify continuing.

I don't think that exploration was wasted. I needed to understand data modelling and agent behaviour well enough to make informed decisions, particularly because I was working alone in an unfamiliar field, and to build intuition and taste for agentic work. But I would spend less time accommodating hypothetical uses before establishing that someone needed them.

Starting over, I'd work with a few like-minded people who have the same context maintenance problems and focus on a smaller set of things to solve. I'd revisit those problems as the models improved and keep track of which ones still needed Midland. These are hard to convert as design partners though (I tried with a few).

My interest was in building a shareable, adaptable system. I'd keep the work closer to that purpose, with less time spent trying to turn it into a company.

Midland is a continuous experiment in self-improving workflows and knowledge that accumulates. A hosted beta is live, and the source opens in December. It's also something I use in my own work. I can move between AI tools without rebuilding my context. When I first connected a new agent to Midland, it could access information I'd accumulated through months of work with other tools. A few friends are connected to my workspace, and we collaborate asynchronously through it.

I'd like to extend that experience to teams, where a new person or agent could start working with an understanding of what others have already established. Making that work across people has been harder than making it work across agents.