Prepare agent architecture and SDLC processes

You assign an issue to Copilot cloud agent (GitHub's agent that works on the task in its own GitHub Actions-powered environment and opens a pull request), and a pull request comes back. What made that result safe to review and merge? Preparing agents for the software development lifecycle (SDLC) comes down to three decisions, and the subtopics in this domain use the same three names (this guide's names, not GitHub terms). The contract decides whether the work should go to an agent at all, what the agent is given, and what it must hand back. The gate decides what stops the agent from acting before a person has accepted its plan. The controls decide what a running agent may do, which of its actions need a person, what can merge, and what evidence the run leaves behind. The classic trap answers these decisions with capability: an agent that can write the diff is not thereby the right owner of work with security, authentication, or production impact, as GitHub's guidance on choosing tasks for Copilot cloud agent makes clear, and a planning agent that is only told not to edit still holds every editing tool its tools list grants.

Follow the subtopics in the order agent work meets each decision. Integrate agents into the software development lifecycle sets the contract, which that page starts with triage (deciding by properties such as impact and ambiguity, not by difficulty) then breaks into three faces: inputs (the assigned issue as a prompt whose acceptance criteria define done), environment (the agent's build-and-test workspace, not the protected environments below), and outputs (the pull request and its review loop). Separate planning and reasoning from agent action places the gate: where approval sits on VS Code custom agents and their plan-to-implementation handoffs, the VS Code Plan agent, in Copilot CLI (command-line interface) plan mode, and in GitHub Copilot upgrade, and which settings quietly remove it. Configure observability and control for autonomous agents sets the controls, which that page sorts into three layers (this guide's labels): a runtime layer that acts while the agent runs (tool permissions and hooks, among others; hooks are commands or HTTP calls Copilot runs, such as just before a tool call), a job layer deciding whether a workflow job runs and what a deploying or secret-reading job reaches (workflow-run approval, where workflows on code Copilot cloud agent pushed wait by default until someone with write access selects Approve and run workflows, and protected environments, whose required reviewers are the other job approval the routing below asks about), and an acceptance layer on what can merge (rulesets, required checks, and code-owner review). Evidence such as artifacts and session records is the record these layers leave, not a fourth layer. The table and decision tree below route each scenario to its decision.

Across all three decisions, the stronger answer is usually a mechanism that holds whatever the agent decides, not a sentence asking it to behave, and the narrowest such mechanism that meets the requirement. For the gate, that means a planning agent whose tools cannot change code, or Copilot CLI plan mode, which waits for your approval before implementing; in plan mode the part that holds is that wait, because its block on project-file edits is a safety net, not a guarantee, and the plan-then-autopilot start is the exception that moves on without that approval. For the controls, it means a protected environment with required reviewers, required review from code owners, or scoped tool permissions rather than an instruction file or a blanket allow-all. For the contract, where the issue text is itself an instruction, the same instinct makes it checkable: complete acceptance criteria a reviewer can test the result against, and an environment that runs the project's checks, so the pull request arrives with validation evidence rather than a claim. An enforced signal only proves what it checks, though: an agent commit shown as Verified (Copilot cloud agent signs its commits) shows who produced it, an artifact digest shows the bytes arrived intact, and neither shows that a person accepted the approach.