Your team is designing a new GitHub Copilot agent to automate code review feedback. Before writing any agent code, which three elements should be explicitly defined in the agent's design specification?
Select an answer to reveal the explanation.
Short Explanation and Infographic
You wouldn't hire a contractor without telling them what you want built, what materials they'll have, and how you'll know when the job is done. Same principle here — defining inputs, outputs, and success criteria up front gives the agent a clear contract and gives the team a way to know if it's working.
Full explanation below image
Full Explanation
Before implementing any agentic system, a well-structured design specification must define three foundational elements:
1. Inputs: What data, context, or triggers the agent will receive. For a code review agent, this might be a pull request diff, repository metadata, and team style guidelines. 2. Outputs: What the agent will produce. This might be inline PR comments, a summary review comment, or a check run status. 3. Success criteria: Measurable conditions that define whether the agent performed correctly. For example: 'identifies at least 80% of known anti-patterns in test suite PRs' or 'produces no false-positive blocking comments.'
Why B is correct: These three elements form the contract between the agent and the team. Without them, development becomes guesswork and evaluation becomes impossible.
Why A is wrong: Model version, token counts, and rate limits are implementation details and operational constraints — important later, but not the right starting point for design. They say nothing about what the agent is supposed to do.
Why C is wrong: The codebase language, CI system, and sprint velocity describe the team's environment, not the agent's behavior contract. These might inform design choices but are not the design specification itself.
Why D is wrong: Memory type, tool count, and orchestration pattern are architectural decisions that follow from the inputs/outputs/success criteria, not precede them. Choosing architecture before defining requirements is premature.