A tech lead assigns an AI agent the task of refactoring a 200-file Python monolith to follow a domain-driven design pattern. The task is expected to take multiple pipeline runs spanning several hours. Before the agent begins, the tech lead wants to ensure the team can pause the agent at any point, evaluate its progress against the original goals, and decide whether to continue, redirect, or roll back. What must be defined first?
Select an answer to reveal the explanation.
Short Explanation and Infographic
You wouldn't drive cross-country without checkpoints on the map — 'success criteria and intermediate checkpoints' are how you know whether the agent is still headed the right direction when you stop to check. On the GH-600 exam, defining success criteria before a long-running agent task is mandatory, and those criteria must be granular enough that you can evaluate progress at any pause point, not just at the finish line.
Full explanation below image
Full Explanation
Domain 1 requires that agents operate with clearly defined success criteria established before work begins. For a long-running, multi-session refactoring task, this requirement is amplified: success criteria must be decomposed into measurable intermediate checkpoints so that the team can evaluate progress at any pause point — not just when the entire task is complete.
Without pre-defined success criteria and checkpoints, the team has no objective basis for deciding at a pause point whether the agent's work so far is on track. They cannot answer: Has the agent correctly identified domain boundaries? Are the refactored modules passing their existing tests? Is the pattern being applied consistently? Can the partial refactor be safely deployed or rolled back? These are not questions that can be answered retrospectively from agent logs alone — they require criteria that were defined before work began and that the agent's artifacts are structured to address.
In practice, success criteria for this task might include: all existing unit tests pass after each batch of files is refactored, each domain boundary is documented in an artifact before refactoring begins, no new dependencies are introduced without explicit approval, and a rollback plan exists for each completed batch.
Why (a) is wrong: Tool permissions are a security and safety configuration concern, not a progress evaluation mechanism. Even with perfectly scoped permissions, if no success criteria exist, the team cannot evaluate whether the agent is doing the right work.
Why (c) is wrong: Context window and chunking strategy are implementation details for how the agent processes large codebases. They affect technical feasibility but do not provide the team with a framework for evaluating progress or making stop/continue/redirect decisions.
Why (d) is wrong: The deployment target is relevant to post-refactoring testing but is premature at the start of a refactoring task and does not help the team evaluate in-progress work.
Why (b) is correct: Defined success criteria and measurable checkpoints are the prerequisite for meaningful pause-evaluate-continue decisions. Without them, stopping the agent is arbitrary and restarting it is dangerous because the team doesn't know what 'good progress' looks like.