If you use AI coding agents today, you probably know the routine: start a session, check it, start the next one, and keep the bigger picture in your own head. On 28 October 2026 GitHub announced a feature for the GitHub Copilot app that tries to take that coordinating job off your plate. It is called Projects, and it is now in public preview.
What Copilot Projects actually are
A project gives Copilot an ongoing goal instead of a single task. According to GitHub’s changelog, a project brings the context, the agents and the results of a piece of work into one place. You describe the goal and add context such as repositories, design mocks or Slack threads. Copilot then runs as many agents as the work needs and brings back results, for example pull requests, for you to review. A pull request is a set of proposed code changes that you can inspect before they are merged.
The difference to a normal session is scope. A session handles one task, usually in one repository, the place where a project’s code lives. A project can span one repository, several, or none at all. GitHub’s documentation gives examples such as grouping customer feedback by theme without changing any code. For a focused task in a single repository, GitHub still recommends starting a session directly from that repository.
How you set up a project
The setup in the documentation takes five steps. In the sidebar, click the plus icon next to Projects to open the New project page. Optionally, choose which repositories the project should use, or skip that step. In the prompt box, describe four things: the purpose, the initial tasks, the expected results and any constraints, meaning the rules Copilot has to follow. Optionally, add files or folders to the Library tab. Then send the prompt and Copilot starts working.
GitHub also advises giving each project one focused goal, so related tasks and results stay together. That sounds like housekeeping, but it matters: a vague goal gives the agents a vague target, and you pay for it later in corrections.
How you keep track of many agents
Inside a project there are four parts: sessions, which are the units of work Copilot starts; optional repositories; automations; and a Library. The Library is split into Agent, for material Copilot generates, and User, for material you add. So you can always tell who produced what.
The Overview tab sorts all work by status into four groups. Needs input collects decisions, reviews and permission requests waiting for you. Open shows work with an open pull request, including session status and lines added and deleted. Working lists sessions that are running, and Done shows finished work. If a session goes the wrong way, you open it from Overview, review its conversation, changes, pull request and plan, and use Steer this session to give new direction. You can also send a follow-up task in the project, or come back later, add new material and ask Copilot to compare it with earlier findings.
What project automations do
Automations are recurring tasks inside a project. You describe the task and when it should run in the project prompt box and answer any follow-up questions Copilot asks. The Automations tab then shows the schedule and the next run time. From its options menu you can pause a task until you resume it, edit the schedule or delete it. To change what the task does, you simply ask Copilot in the project conversation. GitHub’s own example is creating a promo video whenever a feature lands.
Our assessment: who does the checking?
The facts are clear: GitHub is moving Copilot from running single tasks to coordinating a goal. The useful part, in our reading, is not the number of agents but the Needs input group and the Agent/User split in the Library. They make the human checkpoints visible. That is where the real work stays with you, because a pull request produced by an agent is a proposal, not proof that the code does what you wanted.
First, isolate the change. Before you hand a goal to several agents, write down what the finished result must do and how you will check it. Our inference: the more agents run in parallel, the more your review becomes the bottleneck, so a precise first prompt and a habit of checking Needs input first are worth more than any extra agent.
What is still unclear
Projects are a public preview, and GitHub’s documentation says the feature is subject to change. The changelog and the documentation do not state which plans include Projects, how many repositories, sessions or automations a project can have, or how project work counts toward usage or billing. If you try it, start with a small, single-goal project and watch how it behaves before you scale up.
