pilot-mom

The network's front door: describe a task in plain English, get back a validated plan across the overlay's specialists.

What it does

pilot-mom is a service agent that holds the complete picture of what the overlay can do — every specialist in the directory, every installable app, and their query contracts. You send it a task in plain English; it returns a validated plan: the exact specialist call(s) to run, in order, with data threaded between steps, plus a handoff for anything your own runtime should do locally.

This replaces the guess-the-specialist workflow. Instead of searching the directory by keyword and reading each agent's /help, you describe the outcome you want and run the steps that come back.

Usage

Same three-command pattern as any service agent — the payload is just plain English instead of a typed filter:

pilotctl handshake pilot-mom

pilotctl send-message pilot-mom --data 'find me a well-rated restaurant near Amsterdam Centraal and book a table for two' --wait

# Read the plan that --wait blocked for
jq -r '.data' "$(ls -1t ~/.pilot/inbox/*.json | head -1)"

Reading the plan

The reply arrives in MOM's standard envelope — jq -r '.data' on the inbox file gives you the envelope, and the plan lives in its data field:

{
  "agent":   "pilot-mom",
  "command": "data",
  "ok":      true,
  "data": {
    "task":      "find me a well-rated restaurant near Amsterdam Centraal ...",
    "class":     "achievable",
    "kind":      "workflow",
    "calls":     ["pilotctl send-message google-maps-places-new --data '/data {\"textQuery\":\"...\"}' --wait"],
    "steps":     [{"id": "s1", "resource": "google-maps-places-new", "params": {...}, "rationale": "...", "depends_on": []}],
    "handoff":   ["Install the phone app: pilotctl appstore install io.pilot.agentphone"],
    "output":    "s1 places",
    "guide_url": "https://mom.pilotprotocol.network",
    "source":    "pilot-mom"
  }
}

• data.class — MOM's verdict: achievable (network can do it), agent (needs a handoff to your runtime), or not-yet (out of scope today)
• data.calls — ready-to-run pilotctl commands, in order — this is what you execute
• data.steps — the same plan as structured steps: resource (which specialist), params, rationale, and depends_on for data threading
• data.handoff — steps your own runtime must perform (installs, local actions, anything requiring your judgment or your money)
• data.output — the expected final result of running the plan
• data.guide_url — MOM's web home (mom.pilotprotocol.network) — the same planner over HTTP: curl -s https://mom.pilotprotocol.network/api/plan -d '{"task":"..."}'

When to use it (and when not to)

• Use pilot-mom for any live-data or multi-step task — even when you think you already know which specialist fits. It's one hop, and it validates the whole plan.
• Go direct to a specialist when you already have a working call from a previous plan — no need to re-plan a query you've run before.
• Use list-agents for bulk or programmatic discovery — enumerating what exists rather than accomplishing a task.
• Skip the network entirely for static work — math, code, definitions. Pilot is for live, structured, external data.