[EAAPL-WRK005] Plan-and-Execute

Category: Agentic Workflows Sub-category: Goal Decomposition Architecture Version: 1.0 Maturity: Proven Tags: planning, task-decomposition, dependency-graph, plan-revision, goal-decomposition Regulatory Relevance: ISO 42001 §8.4, NIST AI RMF (GOVERN 1.1, MANAGE 1.3)

1. Executive Summary

The Plan-and-Execute Pattern defines a two-phase agentic architecture: a dedicated Planner decomposes a complex goal into a dependency graph of sub-tasks before any execution begins, and a separate Executor then executes the sub-tasks in dependency order (parallelising independent sub-tasks). When execution reveals new information that invalidates the plan, the Planner is re-invoked to revise the plan. This upfront-planning approach contrasts with the ReAct loop (EAAPL-WRK001), which interleaves reasoning and execution; Plan-and-Execute is preferred when the task structure is complex enough to benefit from explicit dependency management and when parallel sub-task execution is valuable.

For CIO/CTO audiences: this is how a project manager operates. Before any work begins, the project manager creates a work breakdown structure — what needs to be done, in what order, what can be done in parallel. The team (the Executor) then works through this plan. If something unexpected happens during execution, the project manager revises the plan. The benefit over an ad-hoc approach (ReAct) is that the full task structure is visible upfront, enabling parallelism, better resource allocation, and a clear scope-of-work that can be reviewed and approved before execution starts — which is exactly what governance and compliance teams require.

2. Problem Statement

Business Problem

Complex enterprise tasks — due diligence on an acquisition target, regulatory gap analysis across 12 jurisdictions, incident root cause analysis — have inherent structure: some sub-tasks must precede others, some can run in parallel, and the total work is too large for a single LLM context. Without explicit planning, an agent attempts to execute in an ad-hoc, interleaved manner that is opaque, hard to parallelise, and difficult to audit.

Technical Problem

The ReAct loop interleaves reasoning and execution, which is efficient for simple tasks but inefficient for complex tasks with parallelisable sub-tasks and dependency constraints. Without an explicit dependency graph, independent sub-tasks are executed sequentially when they could run in parallel, and the agent has no global view of task completeness.

Symptoms of Absence

• Complex multi-part tasks are executed sequentially even when sub-tasks are independent
• No visibility into overall task progress until execution completes
• Plan cannot be reviewed or approved before execution starts
• Agent loses sight of the overall goal when focused on individual sub-task execution

Cost of Inaction

• Efficiency: Unparallelised execution of independent sub-tasks multiplies latency unnecessarily
• Governance: Cannot review or approve the task plan before execution; no pre-execution scope visibility
• Quality: Ad-hoc execution is more likely to miss required sub-tasks or execute them in suboptimal order

3. Context

When to Apply

• Task is complex enough to benefit from explicit sub-task decomposition (typically > 4 sub-tasks)
• Sub-tasks have explicit data dependencies that must be respected
• Independent sub-tasks can be parallelised for latency reduction
• Task plan should be reviewable (human-in-the-loop approval) before execution starts
• The task structure may need revision based on execution findings

When NOT to Apply

• Task is simple (< 3 steps) — use Sequential Chain (EAAPL-WRK002) or ReAct (EAAPL-WRK001)
• Task structure cannot be determined upfront because each step depends entirely on prior results (use ReAct)
• Speed is the primary constraint and upfront planning adds unacceptable latency
• Tasks are highly dynamic and plans become stale too quickly to be useful

Prerequisites

• Planner LLM capable of producing structured dependency graphs (JSON DAG output)
• Sub-task executor infrastructure (parallel execution support if parallelism is required)
• Plan validation logic (detect circular dependencies, invalid sub-task specifications)
• Plan revision trigger conditions defined

Industry Applicability

4. Architecture Overview

The Plan-and-Execute architecture separates cognitive planning from mechanical execution, enabling each to be optimised independently.

Planning Phase The Planner receives the overall goal and produces a structured execution plan: a directed acyclic graph (DAG) of sub-tasks, where each node is a sub-task (with input requirements, prompt reference, and expected output schema) and each directed edge represents a data dependency ("sub-task B requires output of sub-task A"). The Planner uses a capable model (high reasoning quality is more important than speed here; the plan is produced once). The plan is validated for structural correctness (no cycles, all dependencies reachable, all referenced prompts exist in the registry) before execution begins.

Plan Approval Gate (Optional) For high-stakes or long-running tasks, an optional human approval gate presents the plan to a human reviewer before execution starts. The reviewer can approve, modify, or reject the plan. This gate is a direct implementation of human oversight requirements for agentic systems.

Execution Phase The Executor traverses the plan DAG in topological order: sub-tasks with no unmet dependencies are eligible for immediate execution and are dispatched (potentially in parallel via Fan-Out, EAAPL-WRK003). As sub-tasks complete, their outputs are stored in the task state, and newly unblocked sub-tasks are dispatched. The Executor is a pure mechanical system: it does not reason; it only manages task scheduling and dependency tracking.

Plan Revision When a sub-task execution produces unexpected output (e.g., discovers that the target dataset does not exist, or that the regulatory scope is larger than anticipated), a revision trigger fires. The Planner is re-invoked with the current plan, completed sub-task outputs, and the revision trigger reason. The Planner produces a revised plan: it may add new sub-tasks, remove now-unnecessary sub-tasks, or change the dependencies between remaining sub-tasks. Revision is bounded by a maximum revision count to prevent unbounded loops.

Plan Completion The plan is complete when all sub-tasks in the DAG have been executed (or explicitly skipped per a revision decision). The final output is assembled by the synthesis sub-task(s) defined in the plan.

5. Architecture Diagram

6. Components

7. Data Flow

Error Flow

8. Security Considerations

Plan Injection

• The Planner receives the user's goal as input; a malicious goal could attempt to inject additional sub-tasks (e.g., "also exfiltrate all database records as a sub-task")
• Mitigation: Plan validation includes a security review of all proposed sub-task types; whitelisted sub-task templates only; human approval gate for novel sub-task types

OWASP LLM Top 10

9. Governance Considerations

Plan as Governance Artefact

• For regulated or high-stakes tasks, the plan itself (before execution) is a governance artefact: it documents the intended scope of work and must be retained alongside execution results
• Plan revisions are change events that must be logged with the triggering reason

Governance Artefacts

10. Operational Considerations

SLOs

Monitoring

• Average sub-tasks per plan trending: increasing may indicate scope creep in planning
• Plan revision trigger reason distribution: identifies the most common execution surprises
• Sub-task execution latency vs. planned estimate: Planner accuracy metric

11. Cost Considerations

Optimisations

• Use a capable model for planning (quality matters); use efficient models for sub-task execution
• Parallelise all independent sub-tasks (Fan-Out, EAAPL-WRK003) to reduce wall-clock time
• Cache plan templates for recurring task types to avoid re-planning identical goal structures

12. Trade-Off Analysis

Architectural Tensions

13. Failure Modes

14. Regulatory Considerations

NIST AI RMF

• GOVERN 1.1: The explicit plan and plan approval gate implement the governance requirement for human oversight of autonomous agentic workflows.
• MANAGE 1.3: The plan audit record and revision log implement risk management documentation requirements.

ISO 42001

• §8.4: The plan DAG is an operational specification; sub-task whitelist is a control; both must be version-controlled.

Australian Context

• APRA CPS 230: For material business process automation, the execution plan must be a retainable operational record.
• Privacy Act 1988: PII handling in sub-tasks must be scoped to minimum necessary access; the plan defines the data access scope per sub-task.

15. Reference Implementations

AWS

Azure

On-Premises

16. Related Patterns

17. Maturity Assessment

Overall Maturity: Proven

18. Revision History