How to let your agent call other agents

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73

# How to let your agent call other agents

This guide shows how to give your agent a team: other mm agents it hands work to by itself, with the built-in `ask_agent` tool, while you watch which one is working. It assumes you already run `mm` with a configuration file, and have one configuration file per agent you want it to call.

## Steps

1. List the agents under `mmConfigs`, each with a `description` that says **when** to call it — the description is all your model has to choose from:

   ```yaml
   mmConfigs:
     milo:
       path: agent.milo.yaml
       description: Specifier. Turns a request into a specification saved in specs/<slug>.spec.md, and checks code against a specification.
     homer:
       path: agent.homer.yaml
       description: Coder. Implements a specification file from specs/, with tests. Call him only once a specification exists.
   ```

   Paths are relative to the file you write them in. A plain `name: path` entry still works; it is described by the agent's `acp.title`.

2. Decide who approves the agents' own tool calls. By default your agent's `yolo` decides for them too. Give an agent its own `yolo` to change that:

   ```yaml
     homer:
       path: agent.homer.yaml
       description: …
       yolo: true    # his edits and commands run without asking
   ```

   With your own `yolo: false`, you still approve each hand-off — the `ask_agent` call, with the prompt your model wrote — and then homer works on his own.

3. Tell your model, in its `system` prompt, when to hand work over and what to do with the answer. For instance:

   ```yaml
   system: |
     …
     OTHER AGENTS
     `ask_agent` hands a task to another agent; its description says which
     agent does what. Give it a complete prompt. Call it ONCE per task: its
     result is that agent's answer. Then answer the user, saying which agent
     answered; never answer in its place.
   ```

4. Start `mm` and check that the banner lists `ask_agent` among the tools:

   ```text
   mm … | tools: bash, read_skill, read_file, write_file, edit_file, plan, ask_agent | …
   ```

5. Ask something an agent is for, in plain language. In the window (`mm -tui`), the header switches to the agent while it works, and its answer carries its name:

   ```text
   mm [Jan (coding agent)] · Jan-nano:Q4_K_M @ llmman · asked by mm [Bob (coordinator)]
   …
   ‣ mm [Jan (coding agent)]
   The capital of Peru is Lima.
   ```

   Then the header comes back to your agent, which carries on from the answer.

## Variants

- **Send the conversation along.** The model sets `with_context: true` when the agent needs what was said — a reviewer giving a second opinion. Say so in the agent's description ("call it with with_context true").
- **Ask an agent yourself.** `/ask-<name>` and `/ask-with-context-<name>` still work, and keep the exchange in the history. See [How to ask another mm agent](ask-another-agent.md).
- **Long work.** Each event the agent streams keeps your agent's watchdog alive, but a long silence — a large model loading, a long first prompt — does not: raise your `watchdogTimeout` to cover it (10m for a 48 GB model on a laptop).
- **From a script.** `mm --ask <name>` remains the way for a shell command. See [How to ask another agent from a skill or a script](ask-another-agent-from-a-skill.md).
- **Working examples.** `demos/llmman/agent.llmman.yaml` (Bob with Jan, Lucy and a reviewer) and `demos/mini-mes/riker/agent.riker.yaml` (a coordinator, a specifier and a coder).

## See also

- The tool's fields, display and errors: [tools reference](../reference/tools.md#ask_agent)
- The two forms of `mmConfigs`: [configuration reference](../reference/configuration.md)
- Why it runs inside the turn rather than through a skill: [asking another agent — explanation](../explanation/asking-another-agent.md)