multi-agent

mtix

Task infrastructure for parallel AI coding agents.

An AI coding agent is only as good as the context behind its task. As a plan breaks into smaller pieces, that context scatters. The goal, the constraints, and the reasoning end up spread across issues, chat threads, and memory. Agents drift. They redo finished work. They stall for clarification.

mtix fixes this with a context chain. Every task inherits the full briefing of its parents. When an agent claims a task, it gets one assembled prompt: the why, the scope, and the exact step to run. Each task briefs itself. So many agents can run one plan in parallel, each with the context its piece needs. No collisions. No re-explaining.

The same context chain works across a team. One shared hub keeps everyone's agents on the same plan and the same context. It is local-first. A remote team keeps working offline, then syncs on reconnect.

mtix ships as a single binary. It speaks MCP, so Claude Code uses it natively. Every agent, claim, and state change is tracked, so parallel work stays consistent and auditable.

---

mtix (micro-ticks) is a hierarchical task management system where multiple LLM coding agents decompose, claim, and execute work concurrently. Work breaks down into infinitely nested micro issues using dot-notation IDs (PROJ-42.1.3.2.1), where the hierarchy itself becomes the agent's briefing — each level adds context that flows down to the executing agent. Every operation is available through CLI, REST, gRPC, MCP, and a real-time web UI — agents and people use whichever interface fits.

Why mtix

The hierarchy is the briefing. When an agent picks up PROJ-42.1.3, it traverses the parent chain to assemble a complete prompt — business goal from the epic, user story from the feature scope, exact instructions from the issue. No separate documentation, no context windows stuffed with irrelevant files. The tree structure carries the intent.

Agents decompose, not templates. A decomposing agent reads the parent's full context and produces children with problem-specific prompts, acceptance criteria, and test specifications. The structure emerges from the problem's complexity — a one-liner gets one subtask, a cross-cutting refactor gets twelve. No predefined shapes imposed.

Multi-agent orchestration, not just assignment. Agents register, claim nodes, send heartbeats, and run sessions. mtix tracks who is working on what, detects stalled agents, prevents double-claiming, and auto-recovers from crashes. When ten agents work in parallel, node state and agent state stay consistent.

Every state change is auditable. Each transition records who, when, and why — in the same transaction as the data write. An auditor can trace any node's full lifecycle from creation to completion. Built for environments where DO-178C, IEC 62304, and NASA-STD-8739.8 apply.

Single binary, zero infrastructure. Pure Go, embedded SQLite in WAL mode, embedded web UI. No database server, no container orchestration, no runtime dependencies. Copy one file, run it.

Features

• Infinite hierarchy — Epics, stories, issues, micro issues, and beyond. No depth limit.
• Dot-notation IDs — PROJ-42.1.3.2 encodes the full parent-child path. No UUIDs needed.
• 7-state machine — open / in_progress / blocked / done / deferred / cancelled / invalidated with enforced transitions.
• Automatic progress rollup — Child completions propagate to root in a single transaction.
• Dependency tracking — Cross-branch blocks, related, duplicates, discovered_from with cycle detection.
• Prompt chain propagation — Parent prompts cascade to children for LLM context assembly.
• Multi-agent orchestration — Agent state tracking, sessions, heartbeats, stale detection.
• Agent-native query — Multi-value filters (--under A,B --status done,cancelled --type issue), --format briefing for paste-into-context output, --fields for JSON projection. No post-processing stub code needed.
• CLI-first — Every operation available via mtix CLI with --json for machine consumption.
• REST API — Full CRUD, query, and admin endpoints with CSRF protection.
• gRPC API — Protocol Buffers interface for high-performance integrations.
• MCP (Model Context Protocol) — Native tool registration for LLM agent frameworks.
• Web UI — Linear-inspired SPA with keyboard shortcuts (Cmd+K, j/k, c, x), create modal, expandable tree, real-time WebSocket updates.
• Single binary — Pure Go, no CGO, embedded SQLite (WAL mode), embedded web UI.
• Export/Import — JSON export with checksums, merge and replace import modes.
• Content integrity — SHA256 content hashes on every node, full-project verification.
• Team sync (BYO Postgres hub) — Optional event-sourced replication across teammates with LWW convergence, conflict log, hub-unreachable detection, and a mtix sync daemon for periodic auto-pull. Local SQLite remains the canonical store on every CLI.

Why Dot-Notation? The Context Chain

The dot-notation hierarchy isn't just an ID scheme — it's a context chain. Each level encodes a layer of context that flows down to executing agents:

PROJ-1           "Build user authentication"              ← business goal
PROJ-1.3         "Implement rate limiting for auth"        ← technical scope
PROJ-1.3.2       "Add sliding window counter in window.go" ← exact instruction

When an agent calls mtix context PROJ-1.3.2, it receives an assembled prompt — a single document built by traversing root to leaf, combining every ancestor's description and prompt. The agent gets the full picture: why the work exists, what constraints apply, and exactly what to implement.

This is mtix's core design: the hierarchy IS the briefing. Parents provide the "why" and scope. Children provide the "what" — file paths, function names, test cases, edge cases. An LLM agent that reads the assembled context has everything it needs to execute without asking questions.

When decomposing tasks, write each child's description to complete this chain. The test: "Can an agent execute this task using only the assembled context from root to this node?"

Install

Homebrew (macOS/Linux)

brew install hyper-swe/tap/mtix

Binary Download

Download pre-built binaries from GitHub Releases, then install (and upgrade) with an unlink-then-copy — never cp over an existing binary:

install -m 0755 mtix /usr/local/bin/mtix     # or: rm -f target && cp mtix target

On macOS, overwriting a binary in place invalidates its cached code signature and every run is killed (Killed: 9) — install(1), rm+cp, and mv are all safe; Homebrew and go install handle this for you. If mtix daemon runs as a service on the machine, run mtix daemon start after upgrading so the service restarts onto the new binary.

Go Install

go install github.com/hyper-swe/mtix/cmd/mtix@latest

Claude Code Plugin

/plugin marketplace add hyper-swe/mtix
/plugin install mtix

OpenAI Codex

mtix plugin install --target codex   # MTIX.md briefing + native pointers + .codex/config.toml

Project-local installs fully regenerate MTIX.md and append one pointer in root CLAUDE.md and AGENTS.md, preserving other user content. Valid old mtix marker blocks migrate; malformed pairs are refused. HYPERSWE.md suppresses new pointers and native-file creation; existing pointers remain. Existing MCP config is preserved. Add --global for the unchanged global instruction/config install in ~/.codex/. Details: MCP Setup Guide.

pi

mtix plugin install --target pi      # MTIX.md briefing + AGENTS.md pointer (pi loads it natively)

Add --global for the unchanged global briefing install in ~/.pi/agent/. pi drives the mtix CLI through its shell tool; for