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
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's 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
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.'
The elements defining inputs, outputs, and success criteria are correct because they form the contract between the agent and the team. Without them, development becomes guesswork and evaluation becomes impossible.
The model version, token count per request, and API rate limit are wrong because they 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.
The programming language of the codebase, the CI system in use, and the team's sprint velocity are wrong because they describe the team's environment, not the agent's behavior contract. These might inform design choices but are not the design specification itself.
The agent's memory type, the number of tools it will use, and its orchestration pattern are wrong because they are architectural decisions that follow from the inputs, outputs, and success criteria, not precede them. Choosing architecture before defining requirements is premature.