A superset of Markdown designed to exploit LLMs' ability to evaluate programs.
This project aims to:
- Enable the creation of programs not possible with traditional programming languages
- Find and codify LLM's emergent capabilities to evaluate such programs
The language is designed to be:
- Readable as natural prose
- Unconstrained by deterministic paradigms
- Parseable by deterministic tools (for syntax highlighting, quality checks, observability etc.)
- Interpretable by LLMs as executable instructions
- Composable through references to sub-agents and skills
MDZ is "prose first", meaning that you write prompts as normal, and use MDZ keywords to opt-in to programmatic control flow.
The language is very flexible about mixing prose and programmatic statements (reflecting LLMs' ability to interpret and contextualise instructions).
To disambiguate from regular prose, the language leans on all-caps keywords. These notify a contractual obligation.
To provide clarity to LLMs, MDZ uses the END keyword to delimit blocks. MDZ is indentation insensitive.
Under the hood, a .md or .mdz file parsed with MDZ is an amalgam of two grammars: Markdown and MDZ.
MDZ is the grammar that adds LLM-interpretable programmatic constructs to a host grammar (e.g. markdown, plain text etc). The focus is on extending Markdown, but architecturally any document format can in theory be a host language.
The MDZ parser segments the document into a block stream containing:
- unparsed blocks belonging to the host grammar e.g. raw markdown strings
- blocks of proz AST nodes
MDZ kicks in when a delimiter like FOR or SPAWN is detected
In the case of MDZ, you end up with a block stream that looks like this:
[
{ "type": "host", "text": "---\nname: example-doc\n---\n\n# MDZ" },
{
"type": "for",
"target": "item",
"iterable": "items",
"blocks": [
{ "type": "host", "text": "prose inside for loop\n" },
{ "type": "stmt", "keyword": "CONTINUE" }
]
}
]There are a few different ways MDZ could be deployed:
LLMs are capable of holding state both internally and in context between turns. In some quick benchmarks I found MDZ outperformed prose, and used fewer tokens. However, LLMs can forget things and they do get distracted.
In this model, the LLM still runs the program, but uses a tool to update and store its internal pointer and program state. A pre-processing step could annotate the program with statement addresses for the LLM to reference.
Similar to the ideas in recursive language models, the LLM would call out to a REPL to request a module, or part of the program. The evaluation of the program could itself be a recursive call to prevent context rot.
At the end of each turn the LLM could call itself with an updated version of the program containing its remaining steps and the program's internal state. This is most likely a bad idea, because one mistake corrupts the program, but it will be fun to explore.
Contributions from the community are warmly welcomed.
While the language spec is being discovered, the most valuable contribution is sharing data from real-world usage of MDZ.
If there is a feature you think should belong in MDZ, it is recommended that you fork the repo, add the feature to your fork, and share your findings in an issue. The evolution of the language will be driven by data on what works in production.
MIT License - Copyright (c) 2026 Daniel Grant