GitHub bundles Copilot agents in Visual Studio

GitHub just pushed Copilot further inside Visual Studio — not as a better autocomplete box, but as a set of agents that can take work, run tools, and hand back results. That matters because the center of gravity is shifting from “help me code” to “go do part of the job.” The gap, until now, was that a lot of Copilot’s agent story lived either in chat or outside the core IDE loop. The April 30 update closes some of that gap by bringing cloud sessions, custom agents, and a debugger-focused workflow directly into Visual Studio. (github.blog) ### What actually shipped? Three things carry the story. First, developers can start cloud agent sessions from inside Visual Studio. Second, custom agents now work at the user level, not just the repository level. Third, GitHub added a Debugger agent workflow that can reproduce bugs, inspect runtime behavior, and suggest fixes. The same update also added a chat history (github.blog)e. (github.blog) ### Why are cloud agents the big deal? Because this is the clearest “delegate and walk away” move. In Visual Studio, you can pick the cloud option in Copilot Chat, describe the task, and the agent runs on remote infrastructure instead of your local machine. The flow can ask permission to open an issue in your repo, then create a pull request while you keep working — or (github.blog)and more like an async contributor. (github.blog) ### What changed with custom agents? Custom agents launched earlier as repository-based `.agent.md` files. Those are still there. The new part is user-level agents stored in a profile directory — by default `%USERPROFILE%/.github/agents/` — so a developer’s personal agents can follow them across projects. That sounds small, but it changes the unit of reuse. Instead of “(github.blog)sual Studio also broadened where agent skills can be discovered, including `.claude/skills/` and `.agents/skills/` alongside `.github/skills/`. (github.blog) ### What is the Debugger agent doing? This is the most interesting piece because it ties AI to live runtime evidence. GitHub says the workflow can start from a GitHub or Azure DevOps issue, reproduce the bug, instrument the app, diagnose the problem, and suggest a targeted fix through live execution. Microsoft’s Learn docs describe the built-in `@debugger` agent as some(github.blog)ugging context — not just source code text. That is a much tighter integration than a generic chatbot reading logs pasted into a prompt. (github.blog) ### Why does that matter beyond convenience? Because tooling scope is becoming the real product. Once an agent can open issues, create PRs, inspect runtime state, and talk to external systems through MCP connections, the hard question is no longer “can it suggest code?” It’s “what exactly is it allowed to touch, and how do you review the trail afterward?” GitHub’s own d(github.blog)lls you the control plane is now as important as the model. (devblogs.microsoft.com) ### Is this just Visual Studio catching up? Partly. GitHub’s April changelog shows a broader push around agent sessions, debugging, and Copilot workflow changes across products, not a one-off Visual Studio tweak. But Visual Studio matters because it is where debugging, profiling, testing, and enterprise codebases already live. Bundling agents there makes the IDE the place where automated coding work gets assigned, observed, and reviewed. (github.blog) ### What’s the bottom line? GitHub didn’t just add a few AI features to Visual Studio. It bundled a lightweight agent platform into the IDE. The upside is obvious — less context switching, more delegated work, tighter debugging loops. The catch is just as obvious: once agents can act across code, runtime, and repo workflows, teams will care a lot more about permissions, audit trails, and rollback than about whether the chat panel looks nice.