Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.murmur.dev/llms.txt

Use this file to discover all available pages before exploring further.

Murmur’s power comes from orchestrating multiple agents working together. This guide covers the patterns for multi-agent work, from simple parent-child spawning to complex flight DAGs.

​
Pattern 1: Simple parent-child

The simplest pattern — one agent spawns a child and waits for it: 
# From the parent agent (via MCP tools):
spawn(slug="child-task", description="Fix the API endpoint", out="pr")
wait(slug="child-task")
status(slug="child-task")  # read the result
The parent receives a child_lifecycle event when the child completes or fails.

​
Pattern 2: Fanout

Spawn one agent per item — file, module, test suite, or any list: 
# From CLI
echo -e "auth\npayments\nnotifications" | murmur each fix-{} "Fix tests in the {} module" --workspace my-team
Or from MCP: 
{
  "tool": "spawn",
  "slug": "fix-{}",
  "description": "Fix tests in the {} module",
  "each": "/tmp/modules.txt"
}
Each line in the file spawns a separate agent with {} replaced by the item.

​
Pattern 3: Flight DAG

For complex multi-step workflows, use a flight document: 
# Feature Implementation

## design
> persona: architect
> out: respond
Analyze the requirements and design the solution architecture.

## backend
> needs: design
> out: pr
> gate: ci
Implement the backend API based on the design.

## frontend
> needs: design
> out: pr
> gate: ci
Implement the frontend UI based on the design.

## integration-test
> needs: backend, frontend
> out: pr
Write integration tests that verify backend and frontend work together.
Run it: 
murmur spawn --flight feature.md implement-feature --workspace my-team
The pilot agent spawns design first, then backend and frontend in parallel (both need design), then integration-test after both complete.

​
Pattern 4: Event-driven agents

Agents that react to GitHub events in real time: 
---
workspace: my-team
on:
  issue_opened:
    repos: [https://github.com/my-org/my-repo]
    labels: [bug]
---

# Bug Fixer

## triage
> persona: architect
> out: respond
Analyze the bug report and propose a fix.

## fix
> continues: triage
> out: pr
> gate: ci
Implement the proposed fix.
Store in the catalog: 
murmur set flight bug-fixer < bug-fixer.md
Now every new issue with the bug label triggers this flight automatically.

​
Pattern 5: Continuous follow-ups

Send incremental instructions to a running agent: 
murmur spawn --on-idle keep-alive long-task "Build the dashboard"

# Later:
murmur queue add long-task "Also add dark mode support"
murmur queue add long-task "Fix the responsive layout on mobile"
Control how messages are delivered with --dequeue-strategy: 
murmur queue strategy long-task one  # deliver one message per turn

​
Completion assessment

For critical tasks, use the completion assessor — an agentic evaluation that checks whether the flight actually achieved its goal: 
murmur spawn --flight deploy.md --pilot deploy-v2 "Deploy version 2"
The --pilot flag (or completion_check: assessor in MCP) runs an assessment loop up to 3 times before the flight is considered complete.

​
Monitoring agent trees

View the full hierarchy: 
murmur status orchestrator --children --timeline
Or use the dashboard’s agent tree view for a real-time visual of all agents, their status, and cost.