Goal & Planning Pipeline¶

Orchestrate a multi-team product launch with hierarchical goal decomposition, optimal task ordering, component discovery, and parallel agent coordination across marketing, engineering, and QA workstreams.

Illustrative end-to-end example

A worked illustration of how the planning components compose — every component and operation named below is real, and these steps run offline. It is a worked example, not a copy-paste script; some param shapes are condensed for readability.

GoalInput¶

{
  "goal": "Orchestrate a multi-team product launch with hierarchical goal decomposition",
  "context": "SaaS B2B product launching v3.0 with three parallel workstreams: Marketing (campaign assets, landing pages, email sequences), Engineering (feature freeze, performance hardening, deployment automation), and QA (regression suite, load testing, UAT sign-off). Teams share cross-cutting dependencies — QA cannot begin UAT until Engineering delivers the release candidate, and Marketing launch date depends on QA sign-off.",
  "constraints": [
    "All subtask orderings must respect cross-workstream dependency constraints",
    "Parallel execution across workstreams where dependencies allow",
    "Each subtask must be resource-bounded (tokens and wall-clock time)",
    "Architecture must be iteratively refinable based on intermediate results"
  ],
  "resource_bounds": {
    "max_execution_seconds": 240,
    "max_tokens_per_hour": 150000
  },
  "breakpoints": [
    {
      "name": "pre_launch_review",
      "description": "Pause for human review before activating the product launch",
      "active": true
    }
  ],
  "guardrails": [
    {
      "name": "token_budget",
      "predicate": "resource_limit",
      "params": {"max_tokens_per_hour": 150000},
      "message": "Halt if hourly token budget exceeded"
    }
  ],
  "subtasks": [
    {
      "goal": "Decompose the product launch into a SearchTree with resource-bounded subtasks",
      "context": "Use goal_engine to parse the top-level goal into a hierarchical SearchTree. Each leaf node represents a concrete deliverable: marketing asset, engineering milestone, or QA gate. Attach ResourceBounds to every node.",
      "constraints": ["Minimum 3 workstream branches", "Each leaf must have max_execution_seconds and max_tokens"]
    },
    {
      "goal": "Find optimal task ordering under dependency constraints",
      "context": "Use solver to compute a topological ordering of the SearchTree leaf nodes. Engineering feature freeze must precede QA regression, QA sign-off must precede Marketing launch activation. Minimise total wall-clock time by maximising parallelism within constraints.",
      "constraints": ["Respect all cross-workstream edges", "Minimise critical path length"]
    },
    {
      "goal": "Discover available components for each subtask type",
      "context": "Use navigator to query the component registry for each subtask category: content generation, deployment automation, test execution, performance profiling, and notification. Return component names, capabilities, and tier requirements.",
      "constraints": ["Only return components available at Basic tier or above", "Include capability descriptions"]
    },
    {
      "goal": "Provide tool recommendations for each discovered component",
      "context": "Use guide to map each component to its recommended tools, configuration parameters, and invocation patterns. Include fallback recommendations where primary tools have optional dependencies.",
      "constraints": ["Include fallback paths for optional dependencies", "Annotate tier requirements per tool"]
    },
    {
      "goal": "Manage parallel agent teams across workstreams",
      "context": "Use hat_orchestrator to spin up three parallel agent teams — Marketing, Engineering, QA — each with their own subtask queues derived from the solver's ordering. Coordinate cross-workstream handoffs: Engineering RC -> QA UAT -> Marketing go-live.",
      "constraints": ["Three concurrent workstream agents", "Block on cross-workstream dependencies before proceeding"]
    },
    {
      "goal": "Refine the architecture iteratively based on intermediate results",
      "context": "Use recursive_architect to evaluate intermediate outputs from each workstream. If QA discovers a blocking defect, re-plan the Engineering subtasks. If Marketing finds a messaging conflict, adjust the campaign tree. Feed refinements back into the SearchTree.",
      "constraints": ["Maximum 3 refinement iterations", "Each iteration must reduce open issues"]
    }
  ]
}

Pipeline Diagram¶

graph TD
    A[goal_engine<br/>decompose goal] -->|SearchTree| B[solver<br/>optimal ordering]
    B -->|ordered tasks| C[navigator<br/>discover components]
    C -->|component list| D[guide<br/>tool recommendations]
    D -->|tool configs| E[hat_orchestrator<br/>parallel teams]
    E -->|intermediate results| F[recursive_architect<br/>iterative refinement]
    F -->|refined plan| A
    E -->|Marketing workstream| G((Launch Assets))
    E -->|Engineering workstream| H((Release Candidate))
    E -->|QA workstream| I((UAT Sign-off))

What You Need¶

Tier: Researcher
Components: goal_engine, solver, navigator, guide, hat_orchestrator, recursive_architect

Step-by-Step¶

Step 1: Decompose the Goal¶

{
  "component": "goal_engine",
  "operation": "decompose",
  "params": {
    "goal": "Orchestrate multi-team product launch for SaaS v3.0",
    "context": "Three workstreams: Marketing, Engineering, QA. Cross-cutting dependencies between workstreams.",
    "resource_bounds": {
      "max_execution_seconds": 240,
      "max_tokens_per_hour": 150000
    }
  }
}

Returns a SearchTree where each branch represents a workstream and each leaf is a concrete deliverable with its own ResourceBounds. The tree captures parent-child relationships (workstream to task) and sibling dependencies (Engineering RC blocks QA UAT).

Step 2: Solve Task Ordering¶

{
  "component": "solver",
  "operation": "solve",
  "params": {
    "search_tree": "...SearchTree from Step 1...",
    "objective": "minimize_critical_path",
    "constraints": [
      {"from": "eng_feature_freeze", "to": "qa_regression", "type": "blocks"},
      {"from": "qa_sign_off", "to": "mktg_launch_activation", "type": "blocks"},
      {"from": "eng_release_candidate", "to": "qa_uat", "type": "blocks"}
    ]
  }
}

The solver computes a topological sort respecting all dependency edges, then identifies which tasks can run in parallel. Output is an ordered schedule with parallelism annotations.

Critical Path

The critical path runs through Engineering feature freeze, QA regression, QA UAT sign-off, and Marketing launch activation. All other tasks are parallelisable around this spine. The solver identifies this automatically from the dependency graph.

Step 3: Discover Components¶

{
  "component": "navigator",
  "operation": "nav_discover",
  "params": {
    "subtask_types": [
      "content_generation",
      "deployment_automation",
      "test_execution",
      "performance_profiling",
      "notification"
    ],
    "tier_filter": "basic"
  }
}

Navigator queries the component registry and returns matching components for each subtask type, including capability descriptions and tier requirements. This replaces hard-coded component selection with dynamic discovery.

Step 4: Get Tool Recommendations¶

{
  "component": "guide",
  "operation": "guide_find_tool",
  "params": {
    "components": ["...component list from Step 3..."],
    "include_fallbacks": true
  }
}

Guide returns tool configurations, invocation patterns, and fallback paths for each component. For example, if a primary tool has an optional dependency that is not installed, guide recommends the built-in fallback.

Fallback Paths

Every G6 component with optional dependencies provides a built-in fallback. Guide surfaces these automatically — you never hit a dead end because a pip package is missing.

Step 5: Orchestrate Parallel Teams¶

{
  "component": "hat_orchestrator",
  "operation": "allocate_task",
  "params": {
    "workstreams": [
      {
        "name": "Marketing",
        "tasks": ["create_landing_page", "design_email_sequence", "prepare_campaign_assets"],
        "blocked_by": ["qa_sign_off"]
      },
      {
        "name": "Engineering",
        "tasks": ["feature_freeze", "performance_hardening", "build_release_candidate", "deployment_automation"],
        "blocked_by": []
      },
      {
        "name": "QA",
        "tasks": ["regression_suite", "load_testing", "uat_sign_off"],
        "blocked_by": ["eng_release_candidate"]
      }
    ],
    "tool_configs": "...tool recommendations from Step 4..."
  }
}

The hat_orchestrator runs three agent teams concurrently. Engineering starts immediately. QA blocks until Engineering delivers the release candidate. Marketing blocks its launch activation until QA signs off. Within each workstream, tasks without internal dependencies run in parallel. (hat_orchestrator coordinates a team via register_agent to enrol each workstream agent, allocate_task to assign work, and resolve_authority to arbitrate cross-team conflicts — there is no single orchestrate op, so the call above is condensed for illustration.)

Step 6: Refine Iteratively¶

{
  "component": "recursive_architect",
  "operation": "refine",
  "params": {
    "search_tree": "...current SearchTree...",
    "intermediate_results": "...outputs from all three workstreams...",
    "max_iterations": 3
  }
}

The recursive_architect evaluates intermediate outputs and feeds refinements back into the SearchTree. If QA discovers a blocking defect, the Engineering subtree is re-planned. If Marketing identifies a messaging conflict, the campaign branch is adjusted. Each iteration must reduce the count of open issues — convergence is enforced.

Convergence Behavior

The recursive_architect enforces monotonic progress: each refinement iteration must strictly reduce the number of open issues. If an iteration fails to reduce issues, the loop terminates and surfaces the remaining blockers for manual review.

What Happened¶

G6 orchestrated six components in a closed-loop planning pipeline:

goal_engine decomposed the product launch into a hierarchical SearchTree with three workstream branches and resource-bounded leaf tasks
solver computed an optimal topological ordering, maximising parallelism while respecting cross-workstream dependencies
navigator discovered available components for each subtask type via the component registry
guide provided tool recommendations and fallback paths for every discovered component
hat_orchestrator ran three parallel agent teams (Marketing, Engineering, QA) with dependency-gated handoffs
recursive_architect refined the plan iteratively, re-planning subtrees when intermediate results revealed blockers

The pipeline is a closed loop: recursive_architect feeds refinements back into goal_engine, enabling the plan to adapt as execution proceeds.

Why G6 Over a Bare LLM¶

A capable LLM can draft project plans and break down tasks. G6 adds a formal SearchTree decomposition with machine-readable resource bounds, a live component registry for dynamic discovery, and dependency-gated parallel coordination — all prebuilt and composable. One GoalInput JSON triggers structured planning, constraint solving, and iterative refinement that halts once no further issues are reduced — no manual orchestration required.