dmx

The missing orchestrator for AI-native engineering.

Most teams building with AI run into the same problems:

• Workflow lives in chat history. No process, nothing that persists, nothing you can hand off.
• Every developer is using AI differently. Different tools, different prompts, different output.
• Results are unpredictable. Brilliant one session, wrong the next.
• No shared context. Every session starts from scratch, every developer builds their own mental model.
• Missing context causes drift. The same problem solved three ways in the same codebase.

The AI SDLC is the framework we built to fix this: start with a spec, build in phases, verify output, keep context in the repo. dmx is the orchestrator that makes the AI SDLC executable.

dmx runs as an MCP server inside Cursor, Claude Code, GitHub Copilot, and Antigravity. It gives you AI skills that govern the full engineering lifecycle — from first spec to production release — as structured loops. Each loop has a skill sequence, a shared memory context, and a validator. A loop without a validator is just a script.

/dmx/create-ticket         # describe the work → spec → branch
/dmx/plan                  # spec → phased task list
/dmx/implement-next-phase  # build next phase, stop, wait for review
/dmx/validate              # quality gate: spec, security, coverage
/dmx/create-pr             # sync memory, draft PR body, open PR
/dmx/create-release        # tag and publish the release

Every command stops and waits. You review, decide, and move forward. Project context lives in .dmx/ — committed to the repo, read by every AI session.

When a skill sequence is trusted, formalize it as a loop — declarative YAML config, automated validators, and persisted state:

/run-loop spec             # start the spec loop (ticket → branch → spec)
/loop-continue             # resume after a human gate

Loop runtime

Loops are declarative configs that run an ordered skill sequence with durable state and automated validation. Default configs ship with dmx; teams override via .dmx/loops/{name}.yaml.

Foreground is running /dmx/* skills manually — you are the orchestrator. Background is the loop runtime: you define the sequence, write validators that encode your judgment, and review the artifact. Trust is earned by validators, not a config flag.

Bundled loops for the SDLC pipeline:

Each loop config defines a goal state, optional repeat_until condition, validators, human gate policy, and on_complete chaining. Run state is written to .dmx/jobs/{job_id}/{loop_name}-{task_id}.json — there's no separate active-run pointer; the active run is derived by scanning a job's state files for the one non-terminal (pending/running/paused/iterating) entry, keyed off the current branch/ticket. This keeps loop state isolated per branch: pausing work on one branch and running a loop on another can't corrupt or lose either one's state.

Validators are plain Python functions at validators/{name}.py in the app repo (bundled fallbacks ship with dmx). The orchestrator invokes them via subprocess after all skills complete — the coding agent runs skills; validators run deterministically.

Status: M1 is complete (#5) — config, state persistence, MCP orchestration (run_loop, loop_advance, loop_continue), human-gate sequencing, validator execution, the policy engine, repeat_until iteration, on_complete auto-chaining, and loop-level memory hooks are all implemented and covered by an end-to-end integration test suite that runs the full spec → plan → dev → validate → release pipeline through the real MCP tools.

Loop-level memory hooks: before the first skill runs, the runtime surfaces activeContext.md's Open Learnings / Open Decisions to the agent; when a loop finishes (complete, paused for validator review, or iterating), it appends a one-line breadcrumb to Session Notes. This is a deterministic log entry, not judgment — promoting it into durable knowledge is still /dmx/update-memory's job.

Roadmap

• Full lifecycle workflow — spec, plan, build, validate, release
• .dmx/ memory bank — shared project context committed to the repo
• Loop runtime — background execution engine with validators, policy, repeat_until, and autonomous chaining (#5)
• Team server — hosted MCP endpoint, shared loops and rules across the team
• Gateway — model governance, cost visibility, autonomous background execution

Get started

{
  "mcpServers": {
    "dmx": {
      "command": "uvx",
      "args": ["--from", "deepmodel-dmx", "dmx", "serve"]
    }
  }
}

Add to your IDE config (Claude Code, Copilot, Antigravity ↓). Run /dmx/init once per project. Then:

/dmx/create-ticket

Learn more

• When Is a Loop Ready to Run Without You? — the thinking behind dmx
• AI SDLC — the open framework dmx implements

{
  "mcpServers": {
    "dmx": {
      "command": "uvx",
      "args": ["--from", "deepmodel-dmx", "dmx", "serve"]
    }
  }
}

{
  "mcpServers": {
    "dmx": {
      "command": "uvx",
      "args": ["--from", "deepmodel-dmx", "dmx", "serve"]
    }
  }
}

{
  "mcp": {
    "servers": {
      "dmx": {
        "command": "uvx",
        "args": ["--from", "deepmodel-dmx", "dmx", "serve"]
      }
    }
  }
}

{
  "mcpServers": {
    "dmx": {
      "command": "uvx",
      "args": ["--from", "deepmodel-dmx", "dmx", "serve"]
    }
  }
}

/dmx/create-ticket