Kanban & Sub-Agent Orchestration
Myrm provides a visual Kanban board for tracking complex, multi-step tasks and a powerful sub-agent system with 6 orchestration patterns.Kanban Task Board
The Kanban board gives you a drag-and-drop interface to manage agent tasks across 7 columns.Task States
| State | Description |
|---|---|
| Backlog | Tasks waiting to be scheduled |
| Ready | Dependencies met, available for pickup |
| Running | Currently being executed by an agent |
| Completed | Successfully finished and verified |
| Failed | Execution failed (auto-retry or manual review) |
| Blocked | Waiting on external input or a dependency |
| Archived | Completed tasks moved out of the active board |
Key Features
DAG Dependencies
Define task dependencies as a directed acyclic graph. Tasks auto-start when all upstream dependencies complete. Cycle detection prevents deadlocks.
Priority Scheduling
4 priority levels (Urgent / High / Normal / Low) with automatic dispatch to the next available worker.
Zombie Detection
Heartbeat monitoring detects stalled tasks. If a task stops reporting progress, it’s automatically reclaimed and reassigned.
Transient Error Recovery
429/503 API rate limits trigger smart backoff — the task is paused for 15 minutes, then automatically retried. No manual intervention needed.
Pipeline Wizard
For complex workflows, use the Pipeline Wizard to create a task DAG from a template:- Navigate to Kanban > New Pipeline
- Select a template (or create your own)
- The wizard generates a connected task graph with dependencies
- Review and launch — tasks execute in dependency order
Git Worktree Isolation
Each Kanban task can optionally run in an isolated Git worktree:- Parallel workers edit the same repo without conflicts
- Each task gets its own branch
- On completion, changes can be merged as a PR-per-task
Sub-Agent Orchestration
When a single agent isn’t enough, Myrm’s sub-agent system enables multi-agent collaboration with 6 patterns and dynamic discovery capabilities.Dynamic Agent Discovery & @ Mention
Myrm supports an intuitive, Coze-like dynamic discovery and delegation mechanism:- Dynamic Roster: Agents with
allow_discoveryenabled are automatically registered into the system’s dynamic catalog. The main agent (Planner/Leader) dynamically fetches this roster and learns about its available teammates’ capabilities via System Directives. - Explicit @ Mention: In the Chat UI, users can simply type
@to bring up a ReferenceMentionPopover, autocomplete an agent’s name, and explicitly tag them in the message. - Forced Attention: When an agent is tagged, the backend injects a Forced Attention Directive, guaranteeing the main agent will delegate the task to the tagged sub-agent instead of hallucinating or ignoring the request.
- Speaker Identity: The
memory_context_middlewareinjects[Agent: {Name}]prefixes into AI messages, completely eliminating “split-brain” hallucinations where agents forget who said what.
Orchestration Patterns
| Pattern | Description | Use Case |
|---|---|---|
| Spawn | Single child agent delegation | Offload a side task without blocking the parent |
| Chain | Sequential A → B → C | Multi-step pipelines where order matters |
| Batch | Parallel independent tasks | Research across multiple topics simultaneously |
| DAG | Directed graph with dependencies | Complex workflows with prerequisites |
| Verified | Worker + independent Verifier | Critical tasks requiring cross-validation |
| Swarm Fission | Autonomous fission/merge | Exploratory tasks that may spawn sub-tasks dynamically |
Verified Pattern (Adversarial Verification & Zero-Trust)
The Verified pattern prevents agents from “self-grading” or hallucinating success:- Worker agent executes the task
- Physical Evidence Required: The worker must return structural
verifiable_credentials(e.g., file paths, CLI exit codes) instead of just a natural language summary. Claiming PASS without physical evidence is forced to FAIL. - Verifier agent independently reviews the result and the physical evidence in a read-only sandbox
- If verification fails, the Worker retries with the Verifier’s feedback
- Maximum retry count is configurable
Budget Control & Circuit Breakers
Sub-agents operate under strict budget and logic limits:| Dimension | Description |
|---|---|
max_descendants | Maximum total sub-agents spawned (default: 20) |
max_children_per_agent | Maximum direct children per agent (default: 5) |
max_spawn_depth | Maximum nesting depth |
context_budget | Independent token budget per sub-agent |
budget_tokens / max_cost_usd | Hard spending limits |
max_agent_iterations | Circuit Breaker: Physical iteration steps limit to prevent infinite loops |
Workspace Isolation & UI Blacklisting
Each sub-agent runs in an isolated workspace and system sandbox:- CoW cloning — Copy-on-Write workspace duplication
- Precise sync — Only modified files are synced back
- .git protection — Git directory is excluded from operations
- Automatic cleanup — Workspaces are cleaned up on completion
- UI Interaction Blacklisting — Sub-agents running in the background are completely physically blocked from using UI interaction interfaces (like
interactive_feedbackorsend_message), ensuring they never pop up windows to interrupt the user unexpectedly.
Seamless Human-in-the-Loop (HITL)
When an agent hits a checkpoint or needs approval (likePENDING_APPROVAL), the user gets a UI popup.
Beyond simple Accept/Reject, Myrm’s HITL supports Context Injection: the user can provide explicit text instructions (“Wait, also change the color to red”), and the agent resumes with this injected context seamlessly.
Completion Verification
Every task, whether Kanban or conversational, can be verified before being marked complete.CompletionVerifier Protocol
passed— Whether the task meets acceptance criteriareason— Explanation of the verdicterror_logs— Specific issues found
Goal-Level Verification
Goals support dual-engine verification:- Shell verification — Run test commands (e.g.,
pytest,npm test) - Semantic verification — LLM-based assessment against acceptance criteria
Task Diagnostics
Myrm includes a built-in diagnostic engine that proactively detects unhealthy tasks and surfaces actionable recommendations.6 Diagnostic Rules
| Rule | Detects | Action |
|---|---|---|
| Stranded in Ready | Task sitting in READY too long without being picked up | Archive or check dispatcher |
| Repeated Failures | High consecutive failure count (auto-blocked) | Review task description or archive |
| Stuck in Blocked | Task blocked for too long without resolution | Add comment, unblock, or archive |
| Dead Dependency | All parent tasks are in terminal failed/archived state | Archive the orphaned task |
| Stranded in Triage | Rough idea sitting in TRIAGE without being specified | Run Specify or archive |
| Block→Unblock Cycling | Task repeatedly blocked by agent after being unblocked — root cause not addressed | Review block reasons, try different intervention |
Severity Auto-Escalation
Each rule automatically escalates severity based on how far past the threshold the task is:- Warning (1×–2× threshold) — yellow badge on card
- Error (2×–7× threshold) — orange badge
- Critical (≥7× threshold) — red badge with urgent attention needed
Card-Level Badges
Diagnostic results are evaluated at O(1) cost per card and displayed as severity badges directly on Kanban cards. Click any badge to open the diagnostic drawer with detailed explanations and one-click action buttons (archive, unblock, add comment, etc.).Getting Started
- Kanban Board: Navigate to the Kanban page in the sidebar
- Create a Task: Click “New Task” and describe what needs to be done
- Set Dependencies: Drag connections between tasks to define execution order
- Launch: Tasks auto-execute based on priority and dependency order
- Monitor: Watch real-time progress with heartbeat updates