Study guide
1.2 Planning vs. Execution Separation & Plan Output
GitHub Certified: Agentic AI Developer GH-600
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 GH-600 Exam Facts and Strategy 1.2 Core Concepts of Agentic AI in GitHub
2 Chapter 1: Agent Architecture & SDLC Integration
1.1 Agent SDLC Integration & Task Boundaries 1.2 Planning vs. Execution Separation & Plan Output 1.3 Agent Observability & Human Intervention Controls
3 Chapter 2: Tool Use & MCP Server Configuration
2.1 Function Calling & Tool Selection 2.2 MCP Architecture, Transports & Registries 2.3 Tool Scoping in CI/CD & Branch Workflows 2.4 Error Handling, Retries & Escalation Paths
4 Chapter 3: Memory, State & Execution
3.1 Short-Term, Long-Term & External Memory 3.2 Durable Artifacts & Context Pruning 3.3 Context Drift & State Continuity
5 Chapter 4: Evaluation, Error Analysis & Tuning
4.1 Evaluation Signals & Automated Scanning 4.2 Root-Cause Failure Classification 4.3 Instruction, Memory & Tool Access Tuning
6 Chapter 5: Multi-Agent Orchestration
5.1 Multi-Agent Orchestration Patterns 5.2 Parallel Execution & Workspace Isolation 5.3 Conflict Detection, Handoffs & Lifecycle Management
7 Chapter 6: Guardrails & Accountability
6.1 Action Risk Classification & Autonomy Levels 6.2 Least-Privilege Permissions & Policy Enforcement 6.3 Authorization Checkpoints & Responsible AI Compliance
1.2 Planning vs. Execution Separation & Plan Output
Key Takeaways Explain This Topic AI
Decoupling planning from execution separates cognitive strategy from stateful system actions, preventing unguided trial-and-error loops.
The Planning Phase operates in a read-only context to inspect repositories, analyze dependencies, and synthesize a structured Plan Output.
A production-grade Plan Output specifies objectives, target file manifests, ordered sub-tasks, step verification commands, and rollback criteria.
The Execution Phase enforces deterministic step execution, running precondition and postcondition verification checks before and after every action.
When execution steps fail verification, the engine freezes execution and routes context back for plan re-evaluation or human intervention.
Last updated: July 2026
Planning vs. Execution Separation & Plan Output
In advanced AI developer agent architectures, decoupling the Planning Phase from the Execution Phase is a fundamental design principle for achieving reliable, deterministic, and safe software automation. Early AI coding assistants attempted single-pass execution, generating code edits and executing commands in an unguided, reactive loop. This often led to infinite file modification cycles, token exhaustion, context drift, and corrupt code states. By enforcing explicit structural separation between plan generation and plan execution, modern agent frameworks create clear inspection checkpoints, constrain resource usage, and establish verifiable state transitions across complex software engineering tasks.
The Two-Phase Agent Architecture
The decoupled agent framework separates cognitive reasoning from stateful system actions through two discrete runtime phases: +-------------------------------------------------------------------+
- | 1. PLANNING PHASE |
- | Issue Description + Context Files --> LLM Planner --> Plan Output |
- +-------------------------------------------------------------------+
- |
- v
- [ Human Approval Gate ]
- |
- v
- +-------------------------------------------------------------------+
- | 2. EXECUTION PHASE |
- | Plan Output --> Step Execution Loop --> Tool Calls --> Verified PR|
- +-------------------------------------------------------------------+
- Phase 1: The Planning Phase
During the planning phase, the agent operates in a read-only or low-privilege environment focused exclusively on context assembly and strategy synthesis:
Repository Discovery & AST Inspection : The agent traverses file trees, inspects configuration dependencies, reads documentation, and parses relevant source code to construct a comprehensive mental graph of the codebase.
Problem Decomposition : The agent breaks the high-level objective into atomic, sequentially ordered sub-tasks (e.g., "Create interface", "Implement concrete service", "Update dependency container", "Add unit tests").
Precondition & Dependency Mapping : The agent identifies preconditions required for each sub-task, specifying target file paths, expected inputs/outputs, and external package dependencies.
Plan Document Generation : The agent formats its strategy into a standardized, structured Plan Output artifact (Markdown or JSON schema) detailing exact file edits, command invocations, and verification checks.
Crucially, no files are modified and no stateful tool calls are executed during the planning phase.
Phase 2: The Execution Phase
Once the plan is generated (and optionally validated by a human reviewer or policy engine), the agent transitions into the execution phase:
Plan Ingestion & Validation : The execution engine parses the approved plan document and validates step prerequisites.
Deterministic Step Execution : The agent executes steps sequentially using targeted tool calls (e.g., view_file , replace_file_content , run_command ).
Step-Level Pre/Post-Condition Checks : Before and after each action, the agent verifies system state. If a file edit fails linter rules or a build step throws errors, execution pauses immediately.
State Tracking & Rollback Management : The engine maintains a versioned transaction log of file modifications, allowing clean rollback to prior step checkpoints if unrecoverable failures occur.
Benefits of Decoupling Planning from Execution
Establishing a strict boundary between planning and execution yields major operational advantages for enterprise AI workflows:
Benefit Single-Pass Reactive Execution Decoupled Plan/Execution Architecture
Human Governance No oversight until full code generation finishes Humans inspect, edit, or reject plans before edits occur
Token Efficiency High consumption due to repeating trial-and-error loops Low consumption; execution uses focused prompts per step
Error Recovery Cascading hallucinations across uncheckpointed files Step-level rollback to clean intermediate checkpoints
Deterministic Auditing Hard to audit dynamic, unstructured reasoning steps Clear plan document serves as an explicit system specification
Execution Safety Unchecked tool execution can alter sensitive paths Tool execution constrained strictly to files listed in plan
Anatomy of a Production-Grade Plan Output Specification
A production-grade Plan Output must be machine-readable and human-auditable. It typically contains five standardized components:
Objective & Executive Summary : Concise description of the engineering goal and high-level strategy.
Scope & Target File Manifest : Explicit list of files created, modified, or deleted, alongside protected files that must remain untouched.
Sequential Task Breakdown : Ordered sub-tasks containing target files, exact change descriptions, and required tool calls.
Verification Strategy : Concrete test commands, linter checks, and expected success criteria for step validation.
- Rollback & Failure Criteria : Conditions under which the execution phase must abort and revert state. {
- "$schema": "https://json-schema.org/draft/2020-12/schema",
- "planId": "plan-refactor-auth-v2",
- "objective": "Refactor token validation logic to support RS256 JWT signatures",
- "targetFiles": {
- "modify": ["src/auth/jwt.ts", "src/config/auth.json"],
- "create": ["tests/auth/jwt.test.ts"],
- "readOnly": ["src/interfaces/user.ts"]
- },
- "steps": [
- {
- "stepId": 1,
- "description": "Add RS256 public key verification method to JwtValidator",
- "targetFile": "src/auth/jwt.ts",
- "toolAction": "replace_file_content",
- "verificationCommand": "npm run test:unit tests/auth/jwt.test.ts"
- },
- {
- "stepId": 2,
- "description": "Update auth configuration schema to include algorithm parameters",
- "targetFile": "src/config/auth.json",
- "toolAction": "replace_file_content",
- "verificationCommand": "npm run lint"
- }
- ],
- "globalVerification": "npm test",
- "rollbackStrategy": "git checkout main -- src/auth/ src/config/"
- }
- Plan Re-Evaluation and Dynamic Replanning
While execution should remain deterministic, complex codebase realities sometimes invalidate initial planning assumptions (e.g., discovering an undocumented internal dependency during step execution).
When an execution step encounters an unexpected error or unmet precondition:
Execution Freeze : The execution loop halts immediately to prevent error cascade.
Context Capture : The engine captures error stack traces, current file state diffs, and failing step parameters.
Plan Re-Evaluation Trigger : Control routes back to the Planning module with an enriched prompt containing the failure context.
Delta Plan Synthesis : The planner generates a revised delta plan addressing the specific blocker, which is submitted for re-approval before execution resumes.
Enterprise Scenario: Database Client Migration
Consider an enterprise task migrating an asynchronous database client library from pg-v7 to pg-v8 across a 20-module backend repository.
Under a unified reactive approach, an agent might start editing files at random, broken imports mid-way, run out of token window space, and leave 10 files in an uncompilable state.
Under a decoupled architecture:
Planning Phase : The agent scans the 20 modules, analyzes all database call sites, and outputs a structured 5-step Plan Document. The plan specifies modifying db/client.ts , updating helper interfaces in db/types.ts , and modifying test suites.
Human Inspection : A tech lead reviews the generated Plan Document, notices that the agent missed updating connection pool parameters in config/db.json , edits the plan markdown directly to add Step 6, and approves execution.
Execution Phase : The execution engine ingests the updated plan, runs steps 1 through 6 sequentially, executes unit tests after each step, and creates a perfectly verified pull request. This approach eliminates wasted tokens and guarantees code correctness.