Skip to main content
Read Status first. Mzizi is a Phase 0 research prototype. Its goal is a goal, not a result. The language’s front end exists in its toolchain and is tested: a lexer, a recovering parser, a name and type resolver, an agent diagnostic protocol, contract evaluation, a content-addressed IR and nine primitives written in Mzizi. A first backend slice is in: a service with HTTP routes and handlers, which mz build lowers to a local Rust + axum package. A program slice is in too: functions, bindings, numbers, match, loops, results, collections, records with methods and text methods, which mz run lowers to Rust, builds and runs. No component lowers yet, and nothing renders. Mzizi has no modules, standard library or concurrency yet: a program has expressions, bindings, functions, control flow, numbers, results, text, lists, maps, sets and records with methods, in a narrow form, and those rows are ✅ (what still has to be built). Four small pilots of the benchmark have run (two on 2026-09-27, two on 2026-10-29), and none showed an advantage (results). The run that tests the kill criterion has not happened.
Built to make Rust better, the way TypeScript makes JavaScript better. How: no borrows, lifetimes or ownership in the language you write (RFC-0001 §1.8), with the language harness as its spine, the layer an agent reads. “Makes Rust better” is the goal Phase 0 measures, not a result. Mzizi means root. Mzizi is a programming language, and these docs lead with it. Its goal is to be the language people choose instead of TypeScript, Python and C++. Rust is to Mzizi what JavaScript is to TypeScript: its platform. Mzizi is designed to lower to Rust (RFC-0001 §5), and Mzizi Roots is its component model, the way React is JavaScript’s. The aim is that Mzizi does Rust better: you write Mzizi instead of TypeScript, Python or C++, and get Rust underneath. Today a service lowers, to a local Rust + axum package, and a program in RFC-0013’s first slice, to a dependency-free Rust package; no component does. So that is the goal Phase 0 is measured on, not something Mzizi does today. What is which:
  • The language is its syntax, type system, semantics, and contracts as a language feature.
  • The language harness is the spine of the language: every feature registered once, as an entry inside the compiler, and what an agent reads. It covers the language as an agent sees it (mz harness definition), the agent protocol (mz check --agent, its diagnostics and fixes; RFC-0001 §4), and a plugin host that the toolchain, the CLI, the MCP server and plugins are meant to attach to. A first slice exists: entries for every program feature and its codes, served by mz harness. The plugin host and the generated skills are design only (RFC-0012, a draft). It lives in the language repository, mzizi-dev/mzizi, and the agent-tools packages (the CLI, the MCP server, fundi) are its clients.
  • The toolchain is built to support it: the mz compiler that implements it (with its IR, its diagnostic protocol, mz fix and mz contract), the CLI, the MCP server, the skills and the Phase 0 benchmark harness (benchmarks/harness/, not the language harness). They are meant to attach to the language harness. The compiler is not the language.
  • The components are built to support it too: Mzizi Roots and the registry, the language’s UI layer and where its output is meant to land.

​
The claim worth defending

No language in wide use today, TypeScript, Python, C++ and Rust included, was designed for an agent iterating against a compiler. They assume a human is typing, reading docs and holding context in their head. The bet is that this is the wrong assumption for where development is going, and that a language whose syntax, type system and diagnostics are designed for machine authorship is the answer. The charter states it as Mzizi’s “single sharp edge”: syntax, a type system and a compiler feedback loop “designed for machine authorship, not just human ergonomics”. Then a correction that matters more than the original claim. RFC-0001 was written by a frontier model optimising for its own experience, and RFC-0002 withdrew that target:
The design target is small models. A 7B open-weight model running locally, not a frontier model with a million-token context. Frontier capability is improving on its own; the language cannot help there and does not need to.
That inversion is why token efficiency is a first-order goal, why end component button echoes the name back, and why the grammar is small and closed rather than familiar and open. It is also why the second pilot matters: it tested that design target, and the ~7B model did worse in Mzizi than in Dioxus.

​
Phase 0’s goal

Phase 0 has one goal: to build Mzizi as a programming language, measured against the best existing language for each kind of task. That is RFC-0009, and charter v0.4 §4 states it. Two task families gate, on held-out tasks with a ~7B model: Nothing has been measured against that goal yet. The four pilots so far (two on 2026-09-27, which ported registry UI components into Mzizi and Dioxus, and two on 2026-10-29, on a frontier model and a smaller one, against React) were tests inside Phase 0, not its goal. See the benchmark for every arm and its state.

​
Where Mzizi is heading

Direction, not shipped. These are the owner’s stated goals as of 29 September 2026. RFC-0009, RFC-0010 and RFC-0011 in design/ design them. Read the roadmap for how they relate to the phases, and what still has to be built for what exists.
  • The whole stack, not only the UI. Mzizi is meant to build the backend as well as the interface. Mzizi’s own backend infrastructure is meant to be built with it. The first slice exists (a service that lowers to a local Rust + axum package); no Mzizi backend is ported.
  • Two frontend shapes. Astro with Mzizi UI (Mzizi Roots) underneath, or pure Rust end to end.
  • Contracts everywhere. Everything built carries a contract: components, language functions and backend handlers. Today components and services carry contracts; a service’s run in process, tested over generated requests, not proven.
  • A wider benchmark. The benchmark will extend to TypeScript and React on UI tasks, and to TypeScript, Python, Go, C++ and Rust on backend tasks. Today it has Dioxus, Leptos and React arms for UI components and the mzizi-be arm for the backend; only the Dioxus and React arms have ever run, and the other-language backend arms are not added yet.
  • M1, a language that computes, is met on main. Every Tier 1 row of the tracker is ✅ since the fourth release of 8 October 2026, built in waves under mzizi#69. The design (RFC-0013) and its waves are on main since 8 October 2026 (Programs). Collections, records and text operations are built. Modules and the standard library are not started, and they come next, toward M2. See M1: the plan.
  • A higher bar. The kill criterion is now Mzizi against the best existing language for each kind of task, aiming to rank with the top languages. It has not been measured.
  • Every result published. Every benchmark run lands in benchmarks/results/, whichever way it falls.

​
Where to start

Status

What exists, what is tested, what has been measured, and what is still a design.

What still has to be built

The language tracker: what Mzizi still needs against Python, Go, C++, TypeScript and Rust, and milestones M1 and M2.

Pilot results

The two Phase 0 pilots, reported as they came out: no advantage shown.

Syntax

Nine named failure modes an agent hits writing Rust UI code, and the syntax decision that answers each one.

Programs

A program file with functions, numbers, match, loops and results, which mz run lowers to Rust, builds and runs.

The language harness

Every feature registered once and served to agents by mz harness: what is enforced, and what is written by hand.

The nine primitives

Real .mz source with real contracts, gated in CI, and why primitives are copied files and not crates.

The compiler

The toolchain’s compiler, which implements the language: mz check --agent, mz fix, mz contract, mz outline, mz build, mz run and mz harness, and the NDJSON protocol written for a reader holding zero file context.

The IR

Content addressing: one architectural decision that answers seven of eight named reading barriers.

​
What supports the language

The toolchain

The compiler, the benchmark, the MCP server, the CLI and the skills. Free to use, with no sign-in.

Mzizi Roots

Mzizi’s own UI and server components, being rebuilt in Rust for the agentic web. In progress.

Platform

The API at api.mzizi.dev, where data lives, and the console.

​
What Mzizi is not

The charter is explicit about its non-goals:
  • Not its toolchain or its components. The compiler, the CLI, the MCP server, the skills and Mzizi Roots support the language; none of them is the language.
  • Not a rendering engine. Phase 1 is interop with an existing renderer (Dioxus today). Rebuilding one buys the language nothing.
  • Not a tensor runtime. ML inference is a declared capability backed by Candle.
  • Not a post-quantum cryptography project. Named as a future thread and out of scope.
  • Not tied to one web framework. The compiled artifact is meant to be WASM, and native for desktop. Astro with Mzizi Roots underneath is one of the two frontend paths, beside pure Rust end to end, and needs no compiler work beyond Phase 1’s self-contained artifact.

​
Ownership

Mzizi owns and operates the language, its toolchain and its components: the compiler, the registry, the design system, the docs and the API. Nyuchi operates the console and the revenue products. Copyright notices name the Bundu Foundation as the parent copyright holder; Mzizi is not a separate legal entity. The charter states the line and the ecosystem map follows it repository by repository.