{"slug": "introducing-mutagent-helix-a-custom-harness", "title": "Introducing Mutagent Helix: A Custom Harness", "summary": "Mutagent Helix, a custom harness for the Agent Development Lifecycle, shipped as version 0.0.16 on August 15, integrating six stages, eleven sub-agents, and four launch modes into the Pi coding agent as one extension. The beta is public, with support for multiple model providers including Anthropic, OpenAI, Google, OpenRouter, Groq, xAI, DeepSeek, Moonshot, Kimi, and Z.ai, plus Bedrock and Vertex.", "body_md": "# Introducing Mutagent Helix: A Custom Harness\n\nMutagent Helix runs our Agent Development Lifecycle as its own harness, one extension welded into the Pi coding agent. Six stages, eleven sub-agents, four launch modes, bring your own provider. The beta is public.\n\n## Introducing Mutagent Helix: A Custom Harness\n\nThis week we shipped Mutagent Helix. It is our Agent Development Lifecycle with its own harness, the full loop from SPEC to SHIP running inside the Pi coding agent as one extension, no fork, with an orchestrator, six skills, and eleven sub-agents behind it. Version 0.0.16 went out on August 15 as a standalone binary. It is in beta, there will be bugs, and this post is the guide.\n\n## What you see at boot\n\nBoot the binary in a project directory and you’re in a Helix session. The orchestrator is the system prompt, so the lifecycle is live from the first turn, and twelve commands are registered at boot, the stage commands plus state and feedback. The dashboard frames all of it, the stages, the mounted skills, and where the loop stands.\n\n## One session, six stages\n\nA full cycle, stage by stage.\n\n| stage | command | what happens |\n|---|---|---|\n| SPEC | `/spec` | turn what you’re building into a spec the rest of the loop verifies against |\n| BUILD | `/build` | scaffold from the spec, test-first, with a reviewer agent that can steer or stop the build |\n| EVALUATE | `/evaluate` | success criteria learned from the agent’s real traces, binary verdicts at a gate |\n| DIAGNOSE | `/diagnose` | traces read before opinions, root cause pinned, fixes ranked, nothing applied without your approval |\n| OPTIMIZE | `/optimize` | change the layer the diagnosis actually named, validate before it counts |\n| SHIP | `/ship` | watch CI and post-deploy traces, recommend rollback with evidence, never execute it |\n\nEach stage dispatches its own agents, and every agent has one job.\n\n| agent | what it’s for |\n|---|---|\n| ai-architect | reviews builds before code lands, verdicts of PROCEED, STEER, or ABORT |\n| ai-engineer | scaffolds the target and runs the test-first loop |\n| evaluator | learns binary criteria from traces, judges runs, never fixes what it judged |\n| dataset-builder | generates eval candidate cases, never judges them |\n| diagnostics-analyzer | code-first trace analysis, model calls only for the deviations |\n| discovery | collects and exports the trace batch |\n| audit-executor | subject-agnostic static audits, four-tab report |\n| explore | read-only search, a replica of the Claude Code built-in |\n| monitor | the background watch cells, session triggers and release watches, rollback recommendations only |\n\nJudge and fixer are different agents on purpose. The evaluator that scores a run is structurally not allowed to mutate it, so a verdict never optimizes itself into looking better.\n\nConcrete run. Point Helix at a support-triage agent that’s been live for a month. `/spec`\n\nturns its intended behavior into a checked-in spec. The agent already exists, so you skip `/build`\n\nand go to `/evaluate`\n\n, which reads a week of real traces, learns what a good triage looks like, and starts scoring runs pass or fail at a gate. One run fails. `/diagnose`\n\nreads its trace, pinpoints the moment the agent picked the wrong tool after an unusual customer reply, ranks three remedies, and waits for your pick. You pick the prompt-section fix. `/optimize`\n\napplies it scoped to that section and validates against the runs that failed, so the fix has to earn its count. `/ship`\n\nwatches the deploy out, CI green and post-deploy traces clean, and stands down.\n\n## Bring your own provider\n\nHelix doesn’t care whose models it runs. `/login`\n\nsigns you into a provider and stores credentials on your machine, `/model`\n\npicks from the catalog, and your keys never leave your environment. Anthropic, OpenAI, Google, OpenRouter, Groq, xAI, DeepSeek, Moonshot, Kimi, and Z.ai are supported, plus Bedrock and Vertex through their credential chains.\n\nAny dispatch can also pick its model, a fuzzy name like `sonnet`\n\nor a full `provider/modelId`\n\n, so one session can think on one provider and search on another.\n\n## Built for long runs\n\n`/goal`\n\nkeeps a queue. Add goals, pull one to the front, pause, resume, skip, clear, and give each one a token budget so a runaway objective stops itself. The queue renders beside the dashboard, so an unattended run always shows what it’s working toward next. A nightly run might queue triage the inbox first, then draft the weekly digest, each with its own budget.\n\nSkills are drop-in. Any folder with a `SKILL.md`\n\nunder `.claude/skills/`\n\nmounts automatically as a `/skill:`\n\ncommand, so your own tooling appears next to the lifecycle. Skills without a lifecycle stage stay fully usable, they just stay out of the lifecycle panel.\n\nThe `Monitor`\n\ntool watches any shell command’s output line by line and turns each line into a notification the agent reacts to, with flood and timeout guards built in.\n\n## Three modes, one binary\n\nThe same binary runs in three modes, and the mode decides what sits in the system prompt.\n\n| mode | command | what runs |\n|---|---|---|\n| Helix Orchestrator | `mutagent-helix` | the full embedded orchestrator, dashboard, skills, and crew |\n| Agent | `mutagent-helix agent --name X` | your agent definition, replacing the embedded orchestrator |\n| Prime | `mutagent-helix --prime` | the code-interpreter runtime, no orchestrator at all |\n| Prime agent | `mutagent-helix agent --name X --prime` | your definition on the lean code-interpreter runtime |\n\nThe agent mode is the one to try first, because the pathway is direct. At boot the launcher resolves your definition, parses the frontmatter, and injects it as the system prompt over a lean scaffold, into the same slot the embedded Helix orchestrator occupies in default mode. Nothing else of the orchestrator loads. `/agent`\n\nprints exactly what was resolved, the source, the scaffold, the skills, and the model.\n\nThere are three ways to feed it a definition. `--name`\n\nresolves from the agent roots, your project’s `.mutagent/agents/`\n\nfirst, then your global agent directory, then the bundled roster. `--file`\n\ntakes any path on disk. `--prompt`\n\ntakes an inline definition for one-off runs.\n\n```\nmutagent-helix agent --name ui-smoke             # resolved from the agent roots\nmutagent-helix agent --file ./agents/qa.md       # any path\nmutagent-helix agent --prompt \"You audit PRs.\"   # inline, one-off\n```\n\nA definition is just markdown with frontmatter. Drop this in `.mutagent/agents/ui-smoke.md`\n\n:\n\n```\n---\nname: ui-smoke\ndescription: runs the Playwright smoke suite and summarizes failures\nmodel: sonnet\nskills: [playwright-cli]\n---\nRun the smoke suite against the local build and group the failures by page.\n```\n\n`mutagent-helix agent --name ui-smoke`\n\nruns it directly. Dispatching `ui-smoke`\n\nfrom inside a Helix session resolves the same file, because both read the same roots in the same order. One definition, both runtimes.\n\n## Prime mode, a runtime instead of a crew\n\n`--prime`\n\nfolds everything away, the dashboard and the orchestrator included, and hands the model one tool. `run`\n\nexecutes JavaScript in a session that stays alive between turns.\n\n```\n> run: x = 41\n(ask it something else, two turns later)\n> run: x\n41\n```\n\nDefine a function in one turn, call it three turns later. Skills that ship code beside their instructions become callable functions in the same namespace. When code needs the machine, `read`\n\n, `write`\n\n, and shell run behind a gate, every effect is announced before it happens and can be refused, and how much reaches the host is a three-level switch, compute only, gated, or bare.\n\nArchitecturally, prime is the inverted mode. In orchestrator mode the model dispatches a crew, handing briefs to the `Agent`\n\ntool. In prime mode the `Agent`\n\ntool is not on the model’s surface at all. The model gets a code interpreter, one tool, and everything else is reached through code. Skills become callable functions, and dispatch becomes a function call.\n\nThe approach is borrowed with credit, prime-agent’s recursive language model (RLM) design, an IPython-style setup where the code interpreter is the only tool and the model recurses through its own code, spawning sub-agents as ordinary function calls instead of dispatching briefs. Prime is our port of that design onto the harness’s Bun-built runtime. We took a partial inversion. Cells may be submitted in parallel, but execution is strictly sequential, so one runaway program cannot interleave with another. `agent(...)`\n\nreturns a handle, never the answer, and a child’s result arrives later as a new turn, which keeps the model’s context clean of bulk output. The bounds are ours. Recursion stops five levels deep with eight children alive at once, and the function is named `agent()`\n\n, not `rlm()`\n\n, because a borrowed name imports a borrowed contract.\n\n`/refine`\n\nlets a session record what it learned as claim and evidence pairs. A claim with no observation behind it is refused, the code calls it “an objective, not a learning.”\n\nThe honest edges. The namespace lives for the session, on-disk persistence is the next milestone, and the gate currently records effects without refusing them yet.\n\n## Get started\n\nOne binary, macOS and Linux, arm64 and x64. It carries its own harness, skills, and agents inside, so nothing else needs installing.\n\n- Install the binary,\n`curl -fsSL https://install.mutagent.io/helix | bash`\n\n- Run\n`mutagent-helix`\n\ninside your project directory - Run\n`/login`\n\nto set up your LLM provider or subscription - Select your preferred model via\n`/model`\n\n`doctor`\n\nverifies the install and your provider keys, `update`\n\nself-updates. The same lifecycle also ships as plain markdown for any `CLAUDE.md`\n\nreader, including Claude Code, if you want it without switching tools.\n\nIt’s beta. There will be bugs. When you hit one, `/feedback`\n\nfiles a report from inside the session, with the run attached, which is the fastest way it gets fixed.", "url": "https://wpnews.pro/news/introducing-mutagent-helix-a-custom-harness", "canonical_source": "https://mutagent.io/blog/introducing-mutagent-helix/", "published_at": "2026-08-17 00:00:00+00:00", "updated_at": "2026-08-17 16:41:32.054631+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-products"], "entities": ["Mutagent Helix", "Pi coding agent", "Anthropic", "OpenAI", "Google", "OpenRouter", "Groq", "xAI"], "alternates": {"html": "https://wpnews.pro/news/introducing-mutagent-helix-a-custom-harness", "markdown": "https://wpnews.pro/news/introducing-mutagent-helix-a-custom-harness.md", "text": "https://wpnews.pro/news/introducing-mutagent-helix-a-custom-harness.txt", "jsonld": "https://wpnews.pro/news/introducing-mutagent-helix-a-custom-harness.jsonld"}}