all other tools, mcps, apis, whatever are encapsulated by the one interface. new tools don't bloat the agent's context, and it can write its own code to perform more advanced and batch operations against the available tools (executed within a sandbox).
I settled on lat.md [1] at the beginning of this year and never looked back.
Its design offers a compellingly simple surface for weaving natural-language intent into the codebase itself, without overcomplicating things:
---
Key Ideas
* Plain markdown: readable by humans, parseable by agents
* Wiki links connect concepts into a navigable graph
* // @lat: and # @lat: comments tie source code to specs
* lat check ensures nothing drifts out of sync
* lat search for semantic vector search across all sections
---
For me it strikes the right balance between structure and flexibility. It gives agents enough context-efficient grounding to reduce functional and architectural drift [2], while remaining malleable enough to evolve with new requirements.
Admittedly I haven't run any evals, and I'm sure there are even better systems out there... but if I still had the problem I was trying to solve when I found it, I wouldn't be talking about it right now.
Of course it's likely that my problem has only migrated to a higher order of complexity, but surfacing it again through building increasingly complex things is an interesting enough challenge in itself.
Hi, your comment motivated me to try it out on my project. I'm looking for some advice.
I had a 2000 line specification, but no code yet. Based on lat.md, I have split the specification into 25 different files in the lat.md folder (not sure if that's too many).
My next task is to create a staged implementation plan, but I'm not sure how lat.md can help me (or is it even designed to?).
Should the implementation plan stages also be separate markdown files in the lat.md folder? Or a sub folder? (Does it matter).
My understanding is that lat will help create a knowledge graph between the specification files the implementation files, and the code.
mcp with 2 tools: execute(code) and search(query)
all other tools, mcps, apis, whatever are encapsulated by the one interface. new tools don't bloat the agent's context, and it can write its own code to perform more advanced and batch operations against the available tools (executed within a sandbox).
executor is a great implementation of this - https://executor.sh
opencode v2 also provides its own native implementation