How a diagram-to-infrastructure tool turned into a research habit

Terragram (reading an architecture diagram and turning it into infrastructure code) started in May 2025. It worked well on small tasks and fell apart on long ones. The more files a session touched and the longer it ran, the more the model lost track of decisions I'd already made. Prompt engineering alone couldn't keep up with what I was asking it to do.

So I went looking for why. I started reading through the research on how language models actually consume and lose context: what a system prompt can and can't hold onto, why longer conversations degrade, what other people had tried to fix it. By July 2025 that habit had produced the Context Engineering and Orchestration Engineering notes that still shape how I build. The method itself was older: map a new, hard problem onto the shape of a problem someone already solved, instead of starting from nothing.

That research kept paying off in a way that outgrew the one project it started for. Every fix I found for Terragram's context problem was really a fix for a whole category of agent work: durable state, explicit handoffs, a loop that could be inspected instead of trusted blindly. Writing that pattern down once, instead of rediscovering it per project, is what eventually became MOS in November 2025. Dual channels and rule layers is the July 2025 sibling of the same research thread.

The lesson wasn't really about any one protocol or tool. It was that the research itself was the reusable asset. Do it once, deeply, and every future system built on it starts further along.