A DevOps team wants an AI agent to analyze a monorepo's dependency graph, identify outdated packages, and then automatically update those packages across all affected services in a single pipeline run. A senior engineer recommends splitting this into two distinct agents. What is the primary architectural reason for this recommendation?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Think of an auditor and a contractor — the auditor inspects first, hands off the findings, and only then does the contractor begin the work. On the GH-600 exam, separating a read-only research agent from a write-capable execution agent is the classic Domain 1 'separate planning from execution' pattern applied to CI/CD. The split creates a validation gate between discovery and action.
Full explanation below image
Full Explanation
This question tests the separate planning from execution objective of Domain 1, applied to a realistic CI/CD scenario. The recommendation to split into two agents — one that analyzes and one that executes — is driven by a safety architecture concern, not a technical limitation.
The analysis agent operates in a read-only mode: it traverses the dependency graph, identifies outdated packages, and produces a structured output (a plan artifact) listing what should be updated and why. This artifact is inspectable — a human engineer or an automated validator can review it before any changes are made. If the analysis is wrong (e.g., it flags a pinned dependency that should not be updated), the mistake is caught at the plan review stage, not after the repository has been modified.
The execution agent receives the validated plan and performs only the updates that were approved. By keeping execution downstream of a validated plan, the architecture prevents the agent from making unreviewed changes based on its own analysis.
Why (b) is wrong: Context window capacity is a real constraint but is not the reason cited in Domain 1 for separating phases. Modern LLMs can handle complex monorepos in a single context. The architectural reason is safety and validation, not token limits.
Why (c) is wrong: The two-agent design is sequential by intent: analysis → validate → execute. Parallel execution is a different pattern. The split is not about speed; it's about inserting a validation gate.
Why (d) is wrong: Authentication contexts for package management are an operational detail unrelated to the Domain 1 architectural principle being tested. This answer is a plausible distractor but doesn't explain the recommendation.
Why (a) is correct: The separation creates a validate-before-act checkpoint. The read-only analysis agent's output is reviewable before the write-capable execution agent acts — precisely the plan-then-execute pattern Domain 1 requires.