Local agents fit work that needs close human review, such as writing and updating tests.
2
Background agents use isolated Git worktrees for larger tasks where the developer wants partial involvement.
3
Cloud agents run in GitHub Actions and fit work such as documentation when the developer does not need to stay involved.
Summary
Liam Hampton presents VS Code as one place to work with local, background, cloud, and third-party agents. He assigns each path according to how much involvement he wants. A local agent running Claude Opus writes tests while he reviews and redirects it. A background agent uses a Git worktree to build a front end from a GitHub issue, with Hampton checking the result before a pull request. A cloud agent runs in GitHub Actions to add open-source files without requiring his attention. The demo shows all three working on one Python product-store application at the same time. Hampton also explains the controls around cloud agents, including isolated environments, restricted network access, no direct access to the main branch, and MCP connections for GitHub and Playwright. VS Code brings agents, custom instructions, skills, hooks, prompt files, and MCP servers into one control surface, with support for Claude and other services alongside Copilot.
Hampton rejects the idea that an agent can solve an entire problem from one prompt. Developers still need to think about context, tool access, flexibility, and token spend. He connects this to business questions about return on investment and productivity. His point is practical: teams need to choose how they use these systems instead of assuming that more AI infrastructure automatically produces value. The talk focuses on GitHub Copilot agents, but he says the same ideas apply to other agent services.
The amount of human involvement should determine the agent path
Hampton divides agent work into three paths. A local agent runs in VS Code and keeps the developer close to the code, which suits writing tests. A background agent works in an isolated Git worktree, allowing a developer to stay partly involved while it handles a larger task such as building a front end. A cloud agent is for work the developer does not want to touch, such as documentation or making a repository open-source friendly. The choice depends on how much oversight the task needs.
A background agent can build a front end from an issue
Hampton starts with a simple Python CRUD product store and asks a background agent to summarize and plan a solution to GitHub issue 25, which requests a front end. The agent works through the GitHub Copilot CLI inside VS Code and uses Autopilot to avoid repeated approval prompts for tool calls. Hampton tells it to pause before creating a pull request so he can test locally. The work happens in a Git worktree, a branch mapped to an isolated folder.
The three agents can work on separate problems at the same time
While the background agent builds the front end, Hampton starts a cloud agent to add a README, contribution guidelines, and other files needed for an open-source project. He then starts a local agent with a custom Python testing agent and Claude Opus 4.6 at medium reasoning. The local agent writes unit tests, runs them, and updates route error handling when Hampton asks. Hampton can review that work while the other two agents continue, all from VS Code.
Hampton explains that cloud agents run in GitHub Actions inside an isolated environment. They can use the GitHub MCP server and Playwright MCP server, which supports tasks such as front-end testing with screenshots. Network access is restricted with firewalls and allow-listing. The agent cannot access the main branch, so it cannot push directly there. These controls let Hampton hand off documentation and similar tasks without giving the agent unrestricted access to the repository.
The workflow can be shaped with custom instructions, custom agents, prompt files, and agent skills. Hampton describes custom agents as focused configurations for tasks such as writing or fixing test cases. Agent skills are presented as a newer form of the guidance people previously put in agents.md. VS Code also exposes hooks and MCP servers. These settings let developers define how agents work instead of relying on a blank chat prompt each time.
VS Code puts different agent services behind one control surface
Inside the VS Code chat settings, Hampton shows built-in agents such as ask, explore, and plan, along with his custom test agent, skills, extensions, instructions, prompts, hooks, and MCP servers. The same area can include third-party support. He shows Claude plugins, hooks, instructions, and skills alongside Copilot. His claim is that developers can manage these different entry points from one VS Code interface rather than switching between unrelated tools.
Awesome Copilot provides examples that can be adapted
Hampton points to the open-source Awesome Copilot project at aka.ms/awesomecopilot. Although it is aimed at Copilot, he says its configurations can be adapted for other AI tools. The project is also available through an MCP server. He explains that MCP can connect models and chat customizations to resources such as Azure, GCP, AWS, Playwright, documentation systems, and Microsoft Learn, with authentication or open access depending on the server.
