dmx is an open source AI-native engineering harness. It runs as an MCP server inside Cursor, Claude Code, Copilot, or any IDE that speaks the Model Context Protocol, and wraps your AI workflows in structured, verifiable loops.
If you've used AI to write code, you've noticed the problem. The model is fast and often impressive, but the output is inconsistent. Quality depends on how you prompted, whether you remembered to run tests, whether the spec was clear before the first line of code was written. There's no structure. There's just you and the model and whatever happened to work that day.
dmx fixes the process, not the model. It doesn't make the AI smarter. It makes the workflow reliable.
The core idea #
dmx implements the AI SDLC framework, a five-phase workflow with explicit human control points:
| Phase | What happens | Human gate |
|---|---|---|
| Spec | AI drafts a spec, surfaces ambiguity, asks questions | You answer Q&A and approve |
| Plan | AI generates a phased implementation plan | You review and approve |
| Build | AI implements one phase at a time and stops | You review and commit each phase |
| Validate | Automated quality gate checks spec adherence and tests | You review and approve PR |
| Release | AI tags and publishes the release | You confirm |
The model does not merge. It does not advance the workflow. It does not decide when the work is done. You own every gate.
What dmx gives you #
Loops. Each phase is a named, versioned loop: an ordered sequence of skills that run, trigger validators, and wait for your approval before advancing. Loop configs live in your repo, versioned alongside code, reviewed in PRs.
Validators. At every loop boundary, dmx runs validators against a defined policy. Required checks block progress. Optional checks warn. You control what passes.
A memory bank. The .dmx/
directory is committed to your repo. Every session starts with full project context: the spec, the plan, decisions made, patterns established. You stop re-explaining the project to the AI every time.
Persistent job state. Every loop run is a tracked job with a task ID. State persists across sessions. Close the IDE and pick up tomorrow exactly where you left off.
Why dmx if you already use Claude Code or Cursor? #
Claude Code and Cursor are execution engines. They are excellent at running fast. What they don't have is structure: no ordered phases, no mandatory human gate before the next step fires, no validators that block progress on a failed test, no record of what was verified.
Faster execution of an unstructured process is still an unstructured process.
dmx adds the governance layer those tools don't provide:
Workflow sequencing: phases run in order. The AI cannot skip from Build to Release without passing through Validate.Human gates: the loop s at every phase boundary and waits for your approval, not the AI's judgment.Validators with policy: required checks block; optional checks warn. The policy is explicit and version-controlled.Persistent job state: every loop run, validator result, and gate approval is recorded in.dmx/
and readable by anyone on the team.Progressive trust: relax a loop's human gate once its job history shows its validators passing consistently for a given kind of task — a deliberate call you make, not something dmx decides for you.
How it fits with your tools #
dmx is not an alternative to Claude Code, Cursor, or Copilot. It governs what they do. The AI IDE executes skills; dmx defines the sequence, enforces the gates, and runs the validators.
Point your IDE at dmx as an MCP server, and your existing AI tools get a structured workflow on top.
Get started #
There's no separate install step — add dmx to your IDE's MCP config, and uvx
fetches and runs it on demand:
{ "mcpServers": { "dmx": { "command": "uvx", "args": ["--from", "deepmodel-dmx", "dmx", "serve"] } }}
See MCP Setup for IDE-specific config file locations, then follow the Quick Start to run your first loop.