/aiwg-mission

namespace: aiwg
name: aiwg-mission
platforms: [all]
kernel: true
description: Launch an AIWG Mission — durable, audited dynamic agent orchestration toward a completion criterion. AIWG owns the conductor (activity-log, gates, best-output, checkpoint/resume, cost); native primitives drive worker mechanism. Surfaces as /aiwg-mission in Codex (AIWG-owned, no plugin dependency).

AIWG Mission

You are launching (or participating in) an **AIWG Mission** — AIWG's dynamic, durable, audited agent orchestration. A Mission decomposes a goal into worker cycles, runs them toward a measurable completion criterion, and aggregates the result, while AIWG owns the bookkeeping and gates regardless of which agent stack each worker runs on.

This is an **AIWG-specific kernel capability**. On Codex it surfaces as `/aiwg-mission`, deployed by AIWG to `~/.codex/prompts/` — it is **AIWG-owned**, not the plugin-provided `/workflow` an arbitrary Codex install may or may not have (`/workflow` is not a core Codex primitive — see `.aiwg/research/provider-workflow-integration.md`).

Mission vs Flow vs in-stack primitive

• **Mission** (this skill) = *dynamic* orchestration. The shape emerges at run time from the goal. Cross-stack capable.
• **Flow** = a *pre-established* declarative YAML sequence (`flow.aiwg.io/v1`); use `aiwg discover` to find a matching Flow before improvising a Mission.
• **In-stack primitive** (Codex `/goal`, Claude's Workflow tool) = orchestrates *within one stack's process/turn*. A Mission may dispatch workers **to** these; they do not replace the Mission conductor.

When this fires

Natural-language triggers:

• "launch a mission" / "start an AIWG mission"
• "orchestrate this across agents"
• "fan this out to several agents and aggregate"
• "spawn workers to do X until Y"
• "run a long unattended orchestration"
• "coordinate Codex and Claude agents on this" (cross-stack — see #1546)

Non-triggers (route elsewhere):

• A single focused task → just do it (no orchestration overhead; see `god-session` / `subagent-scoping`).
• A pre-established repeatable sequence → find the **Flow** via `aiwg discover` (e.g. `flow-release`, `flow-deploy-to-production`).
• An in-session "iterate until condition" on one stack → the provider-native `/goal` (Codex, Claude Code) already routes for that (#1451/#1469).
• "Address open issues" → the `address-issues` skill (which may itself run as a Mission).

How to run a Mission

1. **State the completion criterion measurably** (per the `vague-discretion` rule). "good enough" is not a criterion; "all tests pass and CI green", "score ≥ 85", "every flagged finding verified" are. If the user's goal is vague, extract a checkable criterion first.

2. **Right-size + decompose.** Break the goal into independently-verifiable worker cycles (`subagent-scoping`). Decide single-stack vs cross-stack:

• **Single-stack** (default): workers run on the current stack. Use this stack's native primitive for in-session fan-out where available; otherwise AIWG's external loop.
• **Cross-stack** (#1546): when the operator wants heterogeneous stacks (e.g. Claude conductor → Codex workers), dispatch worker cycles to executors advertising the target `stack:<name>` capability via AIWG's `serve` executor-registry. The conductor stays AIWG-owned.

3. **Dispatch.** For durable/detached/unattended Missions use AIWG's external route (`aiwg mc dispatch` / `ralph-external`) so the Mission survives the session ending. For in-session orchestration, the native primitive may drive the *mechanism* — but AIWG still owns everything in step 4.

4. **Retain ownership (non-negotiable, identical across stacks).** Whatever drives the worker mechanism, AIWG owns:

• activity-log entries (per the `activity-log` rule)
• issue-thread comments / progress
• human-authorization + threat gates (per `human-authorization`)
• best-output selection across cycles
• crash-resilient checkpoint/resume (durability)
• reproducibility + cost tracking
• LFD loop controls: measurable verifier, hypothesis-before-change,

structural-variant quota, hard budget stop, and private eval/holdout channels where applicable

5. **Control the loss surface.** For any long-running, budgeted, or eval-driven Mission, declare observable iteration/wall-clock/token/tool/spend ceilings before dispatch. Each retry records the hypothesis, expected failure mode, distinguishing diagnostic, and whether the next attempt is structurally different. If the budget or exploration quota is exhausted, stop and emit a best-output report; do not continue by random walk. Eval/holdout Missions expose only aggregate score/probe/status or VOID to workers, while holdout answers and detailed lint diagnostics stay private. For durable Mission Control dispatch, use `--max-iterations`, `--max-total-tokens`, `--max-output-tokens`, `--max-tool-calls`, `--max-total-cost`, `--max-wall-clock-minutes`, and `--exploration-quota`.

6. **Converge + report.** Run cycles until the completion criterion is met (with a `max-cycles` escape hatch), select the best output, and report what each worker did and the aggregated result. Apply the anti-laziness recovery protocol (PAUSE→DIAGNOSE→ADAPT→RETRY→ESCALATE) rather than abandoning on failure.

Discover before improvising

Before hand-rolling a Mission, run `aiwg discover "<the goal>"` — a curated Flow or skill may already exist (the `skill-discovery` rule). A Mission is for genuinely *dynamic* orchestration where no pre-established Flow fits.

References

• `.aiwg/architecture/adr-workflow-routing.md` — routing + cross-stack amendment
• `.aiwg/research/provider-workflow-integration.md` — why Codex `/workflow` is not core (#1535)
• #1534 (epic), #1544 (this command), #1546 (cross-stack Missions), #1536 (Missions/Flows naming)
• `aiwg mc` (mission-control) — the durable dispatch surface