Mob definition
A mob definition declares profiles (agent templates), wiring rules, and flows. Definitions can be JSON or TOML.Profile fields
| Field | Type | Description |
|---|---|---|
model | string | LLM model name |
skills | string[] | Skill references to load |
tools | object | Tool categories: builtins, shell, comms, memory, mob, mob_tasks, mcp (server names) |
peer_description | string | Visible to peers in comms discovery |
runtime_mode | string | "autonomous_host" (default) or "turn_driven" |
external_addressable | bool | Visible for cross-mob comms |
output_schema | object | JSON Schema for structured output extraction |
Flow step fields
| Field | Type | Description |
|---|---|---|
role | string | Profile name to execute this step |
message | string | Prompt sent to the member |
depends_on | string[] | Step IDs that must complete first |
depends_on_mode | string | "all" (default) or "any" |
dispatch_mode | string | "fan_out" (default), "one_to_one", "fan_in" |
condition | object | Guard expression (eq, in, gt, lt, and, or, not) |
branch | string | Branch label for conditional routing |
timeout_ms | number | Step-level timeout |
allowed_tools / blocked_tools | string[] | Per-step tool overlay |
Mob tools reference
Whenenable_mob is set, the agent gets these tools:
| Tool | Parameters | Description |
|---|---|---|
mob_create | definition (JSON) | Create a mob from definition |
mob_list | mob_id? | List mobs, or get status of one |
mob_lifecycle | mob_id, action (stop/resume/complete/destroy) | Control mob state |
mob_events | mob_id, after_cursor?, limit? | Read mob event log |
mob_run_flow | mob_id, flow_id, params? | Execute a DAG flow |
mob_flow_status | mob_id, run_id | Check flow run status |
mob_cancel_flow | mob_id, run_id | Cancel a running flow |
meerkat_spawn | mob_id, specs (array of {profile, meerkat_id, runtime_mode?, initial_message?}) | Spawn members (batch) |
meerkat_retire | mob_id, meerkat_id | Remove a member |
meerkat_wire | mob_id, a, b | Establish trusted comms channel |
meerkat_list | mob_id | List mob members and their state |
meerkat_message | mob_id, meerkat_id, content | Send a direct turn to a member |
List prefabs
- CLI
- JSON-RPC
- REST
- MCP
- Python
- TypeScript
- Rust
Create a mob
- CLI
- JSON-RPC
- REST
- MCP
- Python
- TypeScript
- Rust
Spawn members
- CLI
- JSON-RPC
- REST
- MCP
- Python
- TypeScript
- Rust
Wire and unwire peers
- CLI
- JSON-RPC
- REST
- MCP
- Python
- TypeScript
- Rust
Retire a member
- CLI
- JSON-RPC
- REST
- MCP
- Python
- TypeScript
- Rust
Send a turn
Send a message directly to a specific mob member, triggering an LLM turn.- CLI
- JSON-RPC
- REST
- MCP
- Python
- TypeScript
- Rust
Run a flow
Execute a named DAG flow. Steps execute in dependency order with configured dispatch modes.- CLI
- JSON-RPC
- REST
- MCP
- Python
- TypeScript
- Rust
Check status
- CLI
- JSON-RPC
- REST
- MCP
- Python
- TypeScript
- Rust
Mob events
Read the structural event log (spawns, retires, wires, flow transitions).- CLI
- JSON-RPC
- REST
- MCP
- Python
- TypeScript
- Rust
Lifecycle
Control mob state transitions.- CLI
- JSON-RPC
- REST
- MCP
- Python
- TypeScript
- Rust
Tool-driven mob usage
The primary pattern across all surfaces: enable mob tools and let the agent orchestrate everything from a natural language request.- CLI
- JSON-RPC
- REST
- MCP
- Python
- TypeScript
- Rust
Runtime modes
| Mode | Behavior | Use case |
|---|---|---|
autonomous_host (default) | Member runs a long-lived runtime-backed loop: admit inbox work → process → respond → sleep | Long-lived agents that react to messages |
turn_driven | Member only executes when explicitly given a turn via meerkat_message content dispatch or flow dispatch | Controlled execution, deterministic ordering |
