Interface MissionConfig

Top-level configuration object consumed by MissionCompiler.compile(). Produced internally by MissionBuilder.compile().

interface MissionConfig {
    name: string;
    inputSchema: any;
    goalTemplate: string;
    returnsSchema: any;
    plannerConfig: {
        strategy: string;
        maxSteps: number;
        maxIterationsPerNode?: number;
        parallelTools?: boolean;
        style?: "research" | "creative" | "qa";
        plan?: SimplePlan;
    };
    policyConfig?: {
        memory?: {
            consistency?: MemoryConsistencyMode;
            read?: any;
            write?: any;
        };
        discovery?: {
            kind?: string;
            fallback?: string;
        };
        personality?: {
            traitRouting?: boolean;
            adaptStyle?: boolean;
            mood?: string;
        };
        guardrails?: string[];
    };
    anchors: {
        id: string;
        node: GraphNode;
        constraints: {
            required: boolean;
            phase?: "gather" | "process" | "validate" | "deliver";
            after?: any;
            before?: any;
        };
    }[];
}

Properties

name inputSchema goalTemplate returnsSchema plannerConfig policyConfig? anchors

Properties

name

name: string

Human-readable mission name; becomes the compiled graph's display name.

inputSchema

inputSchema: any

Zod schema (or plain JSON-Schema object) describing the mission's input payload.

goalTemplate

goalTemplate: string

Goal prompt template. Supports {{variable}} placeholders (e.g. {{topic}}). The current stub compiler passes it through to generated reasoning nodes.

returnsSchema

returnsSchema: any

Zod schema (or plain JSON-Schema object) describing the mission's output artifacts.

plannerConfig

plannerConfig: {
    strategy: string;
    maxSteps: number;
    maxIterationsPerNode?: number;
    parallelTools?: boolean;
    style?: "research" | "creative" | "qa";
    plan?: SimplePlan;
}

Planner configuration controlling step generation and execution budgets.

Type declaration

  • strategy: string

    Routing/planning strategy identifier (e.g. 'linear', 'react', 'tree-of-thought').

  • maxSteps: number

    Hard cap on the total number of plan steps the planner may emit.

  • Optional maxIterationsPerNode?: number

    Maximum LLM iterations a single gmi node may consume per invocation. Forwarded to gmiNode as maxInternalIterations.

  • Optional parallelTools?: boolean

    When true, gmi nodes are configured to issue multiple tool calls per turn. Forwarded to gmiNode as parallelTools.

  • Optional style?: "research" | "creative" | "qa"

    Optional plan-template selector. Picks which fixed stub template the compiler emits. Defaults to 'research' (gather → process → deliver → refine) which matches the prior behaviour. Other values:

    • 'qa' — short Q&A plan (research-quick → answer)
    • 'creative' — brainstorm → develop-concept → produce-artifact → polish

    The real PlanningEngine (Task 16+) will deprecate this in favour of goal-driven plan generation; until then style lets users opt into a less research-shaped graph for non-research goals.

  • Optional plan?: SimplePlan

    Pre-generated plan that bypasses both style template selection and the goal classifier. When set, the compiler validates the plan shape (non-empty, unique step ids, known actions, valid phases) and uses the steps directly to build the graph. Intended for callers that generate plans externally — e.g. wunderland's opt-in planner.style: 'llm' mode that asks an LLM to decompose the goal into steps at YAML compile time.

    Validation is intentionally strict: invalid plans throw at compile time rather than producing a partially-correct graph that fails mid-execution.

Optional policyConfig

policyConfig?: {
    memory?: {
        consistency?: MemoryConsistencyMode;
        read?: any;
        write?: any;
    };
    discovery?: {
        kind?: string;
        fallback?: string;
    };
    personality?: {
        traitRouting?: boolean;
        adaptStyle?: boolean;
        mood?: string;
    };
    guardrails?: string[];
}

Optional mission-level policy overrides. When set, they are applied to all compiled nodes unless a node already declares its own policy.

Type declaration

  • Optional memory?: {
        consistency?: MemoryConsistencyMode;
        read?: any;
        write?: any;
    }
  • Optional discovery?: {
        kind?: string;
        fallback?: string;
    }
    • Optional kind?: string
    • Optional fallback?: string
  • Optional personality?: {
        traitRouting?: boolean;
        adaptStyle?: boolean;
        mood?: string;
    }
    • Optional traitRouting?: boolean
    • Optional adaptStyle?: boolean
    • Optional mood?: string
  • Optional guardrails?: string[]

    Guardrail identifiers applied as output guardrails on every node.

anchors

anchors: {
    id: string;
    node: GraphNode;
    constraints: {
        required: boolean;
        phase?: "gather" | "process" | "validate" | "deliver";
        after?: any;
        before?: any;
    };
}[]

Declarative anchor nodes that must be spliced into the execution order at specific phases. Anchors allow callers to inject pre-built GraphNode objects (e.g. specialised tools or human-in-the-loop checkpoints) without modifying the planner output.

Type declaration

  • id: string

    Node id assigned to the anchor inside the compiled graph.

  • node: GraphNode

    Pre-built GraphNode to splice in. The compiler overwrites node.id with anchor.id.

  • constraints: {
        required: boolean;
        phase?: "gather" | "process" | "validate" | "deliver";
        after?: any;
        before?: any;
    }

    Placement constraints that control where in the phase sequence the anchor is inserted.

    • required: boolean

      When true the compiler will throw if the anchor cannot be placed.

    • Optional phase?: "gather" | "process" | "validate" | "deliver"

      Execution phase the anchor belongs to. Phases are ordered: gather → process → validate → deliver.

    • Optional after?: any

      Insert the anchor after this node id (sibling anchor id or plan step id). When the referenced id is not found the anchor is appended to the phase tail.

    • Optional before?: any

      Insert the anchor before this node id. Currently reserved for future use; has no effect in this compiler version.

Settings

Member Visibility

Theme

On This Page

nameinputSchemagoalTemplatereturnsSchemaplannerConfigpolicyConfiganchors