GitHub Copilot is turning agent work into a shared workspace

GitHub has turned its Copilot release cadence into a map of where coding agents are headed next: less like a single chat box in an IDE, and more like shared work that can start in a team channel, continue in a dedicated app, move through a terminal, and land back in a pull request.

The company published its Copilot weekly release bundle on August 28, 2026, with updates across Slack, Microsoft Teams, the Copilot app, Copilot CLI, JetBrains, VS Code and Visual Studio. The individual features are easy to read as product housekeeping. Together, they point to a sharper change: GitHub is making agent sessions portable, visible to teams, and easier for organizations to govern.

That matters because the hard part of using a coding agent at work is no longer just whether a model can write a patch. It is whether the work has context, permissions, logs, cost controls, review defaults and a path back into the ordinary software delivery process.

The release is really about handoff

The clearest signal is in team chat. GitHub says users can now mention @GitHub in Slack and Microsoft Teams to investigate problems, plan work and make changes that the team can follow and guide together. That is not the same as asking an IDE assistant for a local edit. It makes the agent's work visible in the place where many engineering teams already triage incidents, discuss bugs and negotiate priorities.

The same release says VS Code can continue recent Copilot or Claude agent sessions from other applications. Copilot CLI can restore sessions that did not exit cleanly, and GitHub's CLI documentation says a developer can resume an interactive session or bring a GitHub-started cloud agent session into the local environment. The Copilot app adds tab management and Azure DevOps issue entry points. Visual Studio adds organization custom agents and Git-agent review of uncommitted changes or commits.

The pattern is handoff. The agent session is becoming the object that moves, not the interface. A developer might start with a rough bug report in Teams, let Copilot research the repository on GitHub, inspect the proposed branch in VS Code, resume the context in the CLI, and ask Visual Studio's Git agent to review the resulting commit before a pull request.

Cloud agent is the anchor

GitHub's documentation says Copilot cloud agent can work independently in the background to research a repository, create implementation plans, fix bugs, add incremental features, improve tests, update documentation, address technical debt and resolve merge conflicts. It can automate branch creation, commit messages and pushing. A developer can then iterate before deciding whether to create a pull request.

GitHub also draws a useful boundary. Cloud agent is distinct from IDE agent mode: cloud agent works in a GitHub Actions-powered environment on GitHub, while IDE agent mode edits a local development environment. That distinction explains why cross-surface handoff is becoming important. If cloud work, local work and review work happen in different environments, the product has to preserve enough context for a human to understand what the agent did and why.

The August 28 bundle pushes in that direction without pretending one interface can solve every workflow. Team chat is good for assignment and coordination. The Copilot app is good for session management and customization. The CLI is good for local inspection and shell-level work. IDEs are good for editing, debugging and code review. Pull requests remain the place where teams make a durable decision.

Custom agents are becoming organization assets

The Visual Studio update says GitHub organization and enterprise owners can publish custom agents for use across repositories, with Visual Studio showing their descriptions and organization source in the agent picker. GitHub's docs explain the underlying model: organization owners can create organization-level custom agents in `.github` or `.github-private`, while enterprise owners can publish enterprise-level agents through a designated `.github-private` repository.

That is a small but important governance move. A custom agent is no longer just a personal prompt someone keeps in a dotfile. It can become a maintained asset with a repository location, ownership, testing path and release process. GitHub's docs say custom agents can be used across GitHub.com, IDEs and Copilot CLI. Once agents can travel across those surfaces, teams need to know which agent profile was used, who maintains it and whether it is approved for a repository or organization.

The Copilot app update points to the same direction from another angle. GitHub says the Customize tab now brings MCP servers, plugins, skills and canvases together in one place. That list describes the emerging software layer around coding agents. MCP servers connect tools and data. Skills carry reusable instructions. Plugins package capabilities. Canvases organize work. The model is only one part of the system.

This is where recent agent tooling starts to look less like autocomplete and more like an internal platform. The valuable work is not only asking an agent to write a function. It is giving the agent a controlled way to find context, use approved tools, follow team rules and leave enough evidence for review.

The controls are catching up with the autonomy

GitHub's August 28 Visual Studio update adds model thinking effort controls, model pinning, model management and usage visibility. GitHub's model documentation says users can select a model and, where supported, choose thinking effort. In practical terms, that gives teams a way to match the cost and depth of a request to the work at hand: low effort for routine tasks, higher effort for debugging, algorithms or architecture decisions.

Code review is getting a similar treatment. GitHub's Copilot code review documentation says Lite review provides faster targeted feedback, while Balanced routes pull requests to a higher-reasoning model for longer analysis of complex logic, security-sensitive code and cross-service changes. GitHub's August 28 policy post says the default value for Copilot code review will switch from Lite to Balanced for existing and new repositories and organizations using Copilot code review no earlier than September 28, unless admins explicitly select Lite.

That is a real trade-off, not a cosmetic preference. Balanced review may catch more complicated issues, but GitHub says it uses more AI credits and may consume slightly more GitHub Actions minutes than Lite. For teams that already watch CI spend, code review latency and model budgets, the agent workflow now has to be managed like any other compute-backed engineering system.

The sandbox story is also moving. GitHub's policy post says cloud agent will use Sandbox as part of a future unified Copilot experience. Its sandbox documentation says cloud sandbox policies share configuration with Copilot cloud agent policies, and that teams can run multiple Copilot tasks in parallel in the cloud without consuming local resources. That is useful for throughput, but it also raises the stakes for permission design. Parallel agents need tighter boundaries, not looser ones.

Policy convergence will be the next test

The most consequential part of GitHub's August 28 policy post is scheduled, not immediate. GitHub says that no earlier than September 28, 2026, Copilot Chat on github.com, Copilot Chat in GitHub Mobile and Copilot cloud agent will relaunch as a single unified Copilot experience and policy. The same post says the unified experience will be enabled by default after launch, cloud agent will use Sandbox to provide a faster cloud experience, and chat data will be retained for the life of the account rather than 28 days.

For developers, that may make Copilot feel less fragmented. For administrators, it changes the checklist. A single policy is simpler to explain, but it also means a choice can affect more surfaces at once. GitHub says business and enterprise administrators should review the policy before September 28 and confirm that it reflects how they want to manage Copilot access.

There is also a billing change arriving sooner. The same policy post says GitHub will start reenabling sign-ups for new Copilot Business and Enterprise customers paying by credit card or PayPal starting September 1, with account vetting and billing updates. New seat assignments will require payment before users gain Copilot access, and existing credit-card or PayPal customers should expect billing-cycle changes from October 1. GitHub says Copilot Business and Enterprise prices are not changing.

The connection between billing and agent workflows is straightforward. When agents can run in the background, choose higher reasoning levels, start from chat, continue in IDEs and review code automatically, usage accounting stops being an afterthought. Teams need to know which work consumed credits, which model was used and whether the result deserved the spend.

Why this is bigger than another Copilot update

The agent market often gets measured by benchmark wins and dramatic demos. GitHub's release is less theatrical. It is about the operating layer that lets agents fit into software teams without turning every task into a private conversation between one developer and one model.

That operating layer has several pieces:

• Shared session entry points, so agent work can begin where a team is discussing the problem.
• Session recovery and continuation, so useful context survives a tool switch or interrupted terminal run.
• Organization and enterprise custom agents, so reusable expertise has an owner and a repository home.
• Model and effort controls, so teams can choose between speed, depth and cost.
• Review defaults and sandbox policy, so autonomous work still passes through governed checks.

None of this removes the need for engineers to understand the code. It changes where they spend attention. Instead of manually carrying context from Slack to an issue to an IDE to a pull request, they can ask the agent to carry more of that context and then inspect the result. The skill shifts toward scoping the task, setting the right permissions, choosing the right effort level, reading the evidence and deciding whether the patch is worth merging.

That is also where the risk sits. A persistent session can improve auditability, but it can also retain more work context than some teams expect. A shared agent in Teams can make coordination easier, but it can also blur who is responsible for the prompt, the permissions and the final decision. A higher-reasoning code review can catch deeper issues, but it can also create budget pressure if it becomes the default for routine changes. The product now gives administrators more choices. It does not make those choices for them.

What teams should watch next

The next two dates are practical. September 1 brings the Copilot Business and Enterprise signup and billing updates described by GitHub. September 28 is the earliest date for the unified Copilot experience and the code review default change to Balanced. Before then, organizations using Copilot should review cloud agent access, custom agent ownership, sandbox policy, review effort defaults, model budgets and data retention expectations.

The August 28 release bundle is not just a list of places where Copilot now appears. It shows GitHub trying to make agent work durable enough to move through a team. If that works, the coding agent will be less of a side panel and more of a work item with context, policy, cost and review attached.

Collins Anfo is a founder and digital product builder. His write-ups are focused on frontier AI, intelligent agents, robotics, semiconductors and AI infrastructure, cybersecurity and governance, and the real-world adoption of emerging technology.

AI assistance disclosure: AI tools assisted with the research and drafting of this article. Material claims are linked to their sources for independent verification.