Aiwg Mission

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.

Worker check-ins

Check each live worker every 15s; confirm startup within 60s. Quiet limit 90s and stall limit 300s by default (a configured 1.25 scale on those defaults gives 112.5s/375s); hard stop 1800s. Resolved values win over these defaults. Without a native monitor, poll owned run files and processes from the shell at the same cadence. Heartbeats and log bytes are not progress. Supervise by observer state: quiet (suspected) is not a stop — keep waiting while you diagnose (read the status, check owned-worktree progress); stalled opens diagnosis through the diagnostic grace period; only hung authorizes a no-progress stop, and only a worker this conductor owns — confirm it stopped, then continue within remaining attempts; preserve partial work. The launcher also stops independently of progress state on failed-to-start, the hard wall-clock deadline (HARD_DEADLINE), the step-count limit (STEP_LIMIT), and a fatal observer-record failure. Observer loss and opaque MCP coverage are unknown, never worker failure. Terminal verification still applies: read the diff and run trusted checks outside the worker sandbox before integrating.

Bounded decisions: Jev first, LLM fallback

Before worker/model/effort picks (--caller aiwg-mission:worker-pick) and before classifying a failure as environmental or real (--caller aiwg-mission:failure-triage), call aiwg decision ask ... --json and use the answer when status is answered. On fallback, decide normally — fallback never stops the run. Without Jev setup this skill runs unchanged. Never send secrets in the question or context; Jev output is advisory data, never authorization. See the decision-offload skill for the exact command shape and the full caller-tag table.

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