An agent is tasked with 'fixing security vulnerabilities in the authentication module.' After 40 tool calls, the agent is still iterating because it cannot determine when it is done. It has patched several issues but keeps finding new edge cases to address. What should have been defined before the agent was launched?
Select an answer to reveal the explanation.
Short Explanation and Infographic
You wouldn't send a contractor to 'make the house look nice' without a punch list — they'd never leave. Answer C is correct: measurable, verifiable exit conditions let the agent know precisely when the job is done. Specific CVEs, a zero-High SAST scan result, and green tests are all machine-checkable criteria. Time limits, call counts, and periodic check-ins are proxies that don't answer the actual question: is the work complete?
Full explanation below image
Full Explanation
An agent that cannot determine doneness will loop indefinitely or terminate arbitrarily. This is a success-criteria failure — the task definition lacked the verifiable conditions the agent needs to evaluate completion.
Why C is correct: Measurable exit conditions give the agent a deterministic way to evaluate its own progress. A list of CVE IDs is a finite checklist — each one is either remediated or not. A SAST scan with zero High/Critical findings is a pass/fail gate the agent can invoke as a tool call. Green existing tests confirm no regressions. Together these form a done-state definition the agent can check without human judgment on every iteration. This is the security-first pattern: define the acceptance criteria before the agent touches any code.
Why A is wrong: A 30-minute time limit is an arbitrary execution boundary, not a quality gate. The agent might stop with 3 of 7 CVEs unpatched because it hit the clock, or it might be sitting idle for 20 minutes having finished 10 minutes in. Time limits are a safety backstop for runaway agents, not a substitute for defining what 'done' means.
Why B is wrong: A maximum tool call count (20 calls) is similarly arbitrary. Different vulnerability remediations have vastly different complexity — one CVE might require a single patch file edit, another might require refactoring an entire token validation flow across multiple files. Capping at 20 calls could terminate the agent mid-remediation on a complex vulnerability, leaving the codebase in a partially patched, potentially more exploitable state.
Why D is wrong: Periodic human confirmation prompts (every 10 calls) convert a semi-autonomous agent into an interrupt-driven workflow that scales poorly and undermines the value of automation. It also doesn't solve the root problem: even with human check-ins, neither the human nor the agent knows whether the work is done without pre-defined completion criteria. Interrupts are overhead, not correctness.