13 — Sub-Goal Generation

Concept overview

Sub-goal generation translates a high-level objective into smaller outcomes that can be independently attempted and verified. A useful sub-goal describes a result, required evidence, constraints, and its relationship to the parent objective. It is not simply a list of verbs or a longer restatement of the original request.

The architecture must prevent decomposition from expanding scope indefinitely. Track a goal tree or dependency graph, inherit authorization and budgets, and reject children that do not contribute to parent acceptance. Some objectives cannot be decomposed cleanly because intermediate choices change the problem; those require explicit replanning rather than pretending the first tree is complete.

Why it matters in production

Proof of concept

A prototype can ask a model for a short goal list and have a person mark useful versus redundant entries. Evaluate coverage and executability before measuring fluency.

Production

Production validates each sub-goal against available capabilities, required inputs, and completion tests. Give every child a stable identity and explicit owner.

Enterprise scale

At enterprise scale, limit branching and depth, detect duplicate goals semantically and structurally, and aggregate progress by business value. Ten completed trivial children do not imply that the decisive parent requirement is nearly finished.

Architecture components

Goal decomposer

Proposes child outcomes and explains their contribution to parent completion.

Capability matcher

Checks that each child can be executed with available tools and permissions.

Goal graph

Stores dependencies, ownership, status, and inherited constraints for each child.

Completion evaluator

Verifies child artifacts against defined acceptance criteria.

Expansion controller

Caps depth, branching, aggregate cost, and repeated decomposition attempts.

The architecture, mapped

flowchart TD
 P["Recall response objective"] --> D["Sub-goal generator"]
 D --> V["Coverage and capability checks"]
 V --> A["Identify affected lots"]
 V --> B["Locate downstream shipments"]
 V --> C["Prepare customer notices"]
 A --> B
 B --> C
 A --> J["Parent acceptance check"]
 B --> J
 C --> J
 X["Depth and cost limits"] --> V

Runtime flow

1. 1

   Define parent outcome

   Capture the intended deliverable and distinguish mandatory requirements from optional improvements.

2. 2

   Propose children

   Generate bounded outcomes with evidence needs and explicit dependencies.

3. 3

   Validate coverage

   Check for missing requirements, duplicate work, impossible capabilities, and scope expansion.

4. 4

   Assign execution

   Map valid children to workers and allocate budgets while reserving integration capacity.

5. 5

   Evaluate artifacts

   Accept sub-goal completion only when its evidence and output contract are satisfied.

6. 6

   Aggregate meaningfully

   Determine parent completion from required outcomes, and replan only unresolved portions.

Preparing a product recall response

Food manufacturing · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

A food producer receives a contamination alert that may affect several production lots and distribution partners.

The problem

The request to prepare a recall response is too broad for one reliable tool sequence and can omit downstream shipment analysis.

Agent requirement

The assistant must identify affected material, trace distribution, and prepare evidence-backed communication drafts for authorized review.

Architecture

A decomposer creates lot-identification, shipment-tracing, and notice-preparation goals with dependencies and controlled access to traceability systems.

Runtime

• The first child establishes verified lot boundaries; shipment tracing consumes those identifiers rather than guessing from product descriptions.
• Notice drafting begins only when destination evidence is available, and parent acceptance requires all mandatory traceability gaps to be visible.

Failure scenario

If a distributor feed is incomplete, its child remains unresolved and the final package highlights the missing coverage for the response team.

Operational impact

Measure requirement coverage, duplicate child work, unexecutable goals, and unresolved critical dependencies. Drafting many notices is not equivalent to completing traceability.

Architecture tradeoffs

Failure scenarios & recovery

Common architecture mistakes

Defining sub-goals as vague activities

Require an observable result and completion test.

Counting completed children as equal progress

Weight mandatory parent requirements and critical dependencies.

Forgetting an integration goal

Reserve ownership and budget for assembling the final deliverable.

When to choose this pattern

Choose it when

• Objectives contain distinct verifiable outcomes.
• Different capabilities can execute independent parts.
• Coverage of mandatory requirements matters more than conversational fluency.

Avoid it when

• A single bounded operation already completes the objective.
• Intermediate outcomes cannot be validated or assigned.
• The decomposition overhead exceeds the task's useful work.

Architecture checklist

• Specify parent acceptance before decomposition.
• Require completion tests for each child.
• Check capability and permission feasibility.
• Bound depth and branching.
• Detect duplicate or irrelevant goals.
• Reserve integration time and budget.

Related concepts

• 1 — Multi-Agent Orchestration
• 4 — Hierarchical Orchestration
• 8 — Plan-and-Execute Pattern
• 18 — Semantic Condition Checking
• 46 — Max Iterations Fallback

Primary references

• LangGraph: workflows and agents