> ## Documentation Index > Fetch the complete documentation index at: https://docs.myrmagent.ai/llms.txt > Use this file to discover all available pages before exploring further. # Kanban & Sub-Agent Orchestration > Visual task board with DAG dependencies and 6 orchestration patterns for multi-agent workflows. # 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 | | ------------- | ---------------------------------------------------------------------------- | | **Triage** | Rough idea just added — use AI Specify to refine into actionable 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 Define task dependencies as a directed acyclic graph. Tasks auto-start when all upstream dependencies complete. Cycle detection prevents deadlocks. 4 priority levels (Urgent / High / Normal / Low) with automatic dispatch to the next available worker. Heartbeat monitoring detects stalled tasks. If a task stops reporting progress, it's automatically reclaimed and reassigned. 429/503 API rate limits trigger smart backoff — the task is paused for 15 minutes, then automatically retried. No manual intervention needed. Cancel a task and the LLM execution stops within milliseconds — no wasted tokens. Works for both running and queued tasks. ### Task Result Editing Completed, failed, or cancelled tasks can have their `result` and `metadata` fields edited directly from the task drawer in the frontend. * Click a task card → open the drawer → edit the result inline * Only available for terminal-state tasks (completed/failed/cancelled) to prevent interference with running tasks * Each edit emits an `EDITED` event with a payload listing changed fields, providing a full audit trail in the activity feed * Metadata merges additively — existing keys are preserved unless explicitly overwritten ### Pipeline Wizard For complex workflows, use the **Pipeline Wizard** to create a task DAG from a template: 1. Navigate to **Kanban > New Pipeline** 2. Select a template (7 built-in: code review, data analysis, research paper, video production, multi-topic research, content distribution, competitive analysis) 3. Answer discovery questions — multi-select answers automatically generate parallel tasks via **repeat\_for fan-out** (0 LLM calls, deterministic) 4. Review and launch — tasks execute in dependency order with a safety cap of 20 parallel tasks Custom templates are defined as YAML frontmatter in Skill files, making them reusable and version-controlled. The `repeat_for` field on any task seed turns a single template node into N parallel tasks based on user multi-select input. ### 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_discovery` enabled 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_middleware` injects `[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: 1. **Worker** agent executes the task 2. **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. 3. **Verifier** agent independently reviews the result and the physical evidence in a read-only sandbox 4. If verification fails, the Worker retries with the Verifier's feedback 5. Maximum retry count is configurable This ensures high-quality output for critical tasks and completely eradicates "hallucinated success". ### 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 | **Smart Model Downgrade**: When budgets are near exhaustion or certain limits are triggered, Myrm can automatically downgrade the sub-agent from an expensive reasoning model to a cheaper, faster model, preventing budget burn while still attempting to complete the task. Budget exhaustion produces structured errors with clear reasons, not silent failures. ### 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 GC** — Three-layer garbage collection (stale events, run records, workspace dirs) runs every 6 hours and on startup. Archived task workspaces are safely deleted with harness-dir boundary checks, and DB paths are nulled to prevent repeated scans — zero manual maintenance required * **UI Interaction Blacklisting** — Sub-agents running in the background are completely physically blocked from using UI interaction interfaces (like `interactive_feedback` or `send_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 (like `PENDING_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. ### Non-Fatal Timeout Most agent frameworks kill sub-agents that exceed their time budget — all progress is lost, and you have to start over. Myrm takes a fundamentally different approach: **timed-out sub-agents keep running in the background**. * The parent agent receives a partial result with `still_running: true`, so it can continue with other work immediately * When the sub-agent finishes, an **event-driven callback** automatically wakes the parent agent — no polling, no manual checks * The completed result is available for the parent's next turn with semantically clean serialization (no misleading completion timestamps) * **3 cancellation strategies** (Immediate / Graceful / Checkpoint) give you fine-grained control if you do want to stop a sub-agent **What this means for you:** Long-running research tasks, code generation, or complex analysis never lose progress to arbitrary timeouts. Your agents work like a real team — if someone takes longer than expected, the team keeps moving and picks up the result when it's ready. *** ## Completion Verification Every task, whether Kanban or conversational, can be verified before being marked complete. ### CompletionVerifier Protocol ```python theme={null} class CompletionVerifier(Protocol): async def verify(self, task: KanbanTask, result: str) -> VerificationResult: ... ``` Verification results include: * `passed` — Whether the task meets acceptance criteria * `reason` — Explanation of the verdict * `error_logs` — Specific issues found ### Goal-Level Verification Goals support dual-engine verification: 1. **Shell verification** — Run test commands (e.g., `pytest`, `npm test`) 2. **Semantic verification** — LLM-based assessment against acceptance criteria Both must pass for a goal to be marked complete. *** ## 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 1. **Kanban Board**: Navigate to the Kanban page in the sidebar 2. **Create a Task**: Click "New Task" and describe what needs to be done 3. **Set Dependencies**: Drag connections between tasks to define execution order 4. **Launch**: Tasks auto-execute based on priority and dependency order 5. **Monitor**: Watch real-time progress with heartbeat updates For sub-agent orchestration, simply describe a complex task to any agent — it will automatically decompose and delegate using the appropriate pattern.