GitHub Copilot: autocomplete, chat and the cloud agent

What does the cloud agent do?

According to the official documentation, the agent researches the repository, plans changes and implements them in the background. It edits files and runs tests and linters in an ephemeral cloud development environment, not in your local IDE. It also handles creating the branch, writing the commit message and pushing the changes.

You can start it from the agents panel, from a chat conversation, or from an issue or pull request on GitHub.com. The documentation also lists GitHub Mobile, several IDEs, the GitHub CLI, the REST API and integrations with tools such as Jira, Slack, Microsoft Teams and Linear. It can open the PR from the start, or after you review the changes and ask for refinements.

It follows the same pattern as other background agents, and alternatives exist such as Claude Code: a programming agent that works in your repo, Cursor: the AI-powered editor and its agent mode and Codex: OpenAI's programming agent.

Why does it matter to a designer?

Because it lets you delegate a small, well-defined task without opening the editor. For example, changing the text of an empty state or adjusting a component according to a note. What makes the work reviewable is the pull request: there you can compare the result against the design, request changes in comments and approve only when it is right. If that flow is new to you, start with branches and pull requests.

The official documentation is explicit about one point worth remembering: session logs show the work done and the tools used, but they do not replace your own review and testing. An unreviewed PR is a risk, not a deliverable.

Which plans include what?

According to GitHub’s plans page, checked on October 20, 2026:

One AI credit equals 0.01 dollars. According to the same page, code completions and next edit suggestions do not use credits. For Business and Enterprise the page shows no prices and points to contact sales; ask your administrator whether the agent is enabled. Delegating tasks to third-party agents appears as a preview: not included in Pro, included in Pro+ and Max. Prices and terms change, so check the page before deciding.

What are its limits?

• One repository per task. It only makes changes in the repository specified when the task starts.
• One branch at a time and one PR per task.
• 59 minutes maximum per session, which cannot be extended or bypassed. In the copilot-setup-steps.yml file you can set a shorter time with timeout-minutes, up to a maximum of 59.
• GitHub only. The repository must be hosted on GitHub.
• Permissions. Repository owners and administrators can disable the agent. If a ruleset blocks its access, an administrator can add Copilot as a bypass actor.
• Possible errors. The documentation warns that the code can be incorrect or suboptimal, including code with security vulnerabilities, so review and test it before production use.

How do you review what it delivers?

1. Read the whole PR, not just the summary. Open the preview and compare it with the design.
2. Ask for changes in a comment by mentioning @copilot on the PR, or push your own commits to the branch.
3. Approve the workflow runs. By default, GitHub Actions workflows do not run automatically when Copilot pushes changes to a PR: someone must click “Approve and run workflows”. Review the changes first, especially any that touch .github/workflows/.
4. Leave instructions in the repository. A .github/copilot-instructions.md file stores project conventions, and the agent can use it to work with more context.

More criteria in reviewing agent PRs.

When should you NOT use it?

• When the task is ambiguous. A background agent given a vague instruction produces a PR that is hard to review.
• When the project does not live on GitHub.
• When the task needs to coordinate several repositories at once.
• When you will not review the PR carefully. Delegating without review moves the risk into production.

Example

Illustrative example: a designer needs the empty state of the projects list to use the EmptyState component and the text they approved. They open an issue with the exact text, a link to the component and the design screenshot, and assign the Copilot agent. The agent opens a PR on a branch. The designer reviews it, compares the screenshot with the result, asks for a spacing change by mentioning @copilot in a comment and approves once it matches.

What remains yours: the comparison with the design and the decision to approve, which no agent can make for you.

Common mistakes

• Assigning vague tasks such as “improve the screen” without acceptance criteria.
• Approving the PR because the tests passed, without looking at the screen.
• Assuming the agent knows your design system without documenting it in the repository.
• Forgetting to approve the workflow runs and believing the tests passed when they never ran.
• Not checking the repository settings, which can block or limit the agent.
• Forgetting that the plan and the organization’s policies determine whether the agent is available.

Sources

• GitHub: Copilot plans
• GitHub Docs: about the Copilot cloud agent
• GitHub Docs: customize the agent environment
• GitHub Docs: review Copilot pull requests
• GitHub Docs: repository custom instructions