Playbook
Tasteful Skills
“Tasteful Skills” argues that the best agent skills are not documentation or best-practice lists.
Back to Podcast Digest
Cooking with Agents in VS Code — Liam Hampton, Microsoft
TL;DR
Liam Hampton’s core point: agents are not one-shot magic — he opens by pushing back on the idea that a single prompt will “create a wonderful application,” framing the real challenge as reducing cognitive load, managing token spend, and being deliberate about where each agent fits.
He splits agent work into three modes: local, background, and cloud — local agents are for hands-on tasks like writing tests, background agents sit in the middle using Git worktrees for semi-autonomous work like building a UI, and cloud agents are for low-touch chores like documentation.
The demo’s punchline is one codebase, three agents, three jobs done at once — in VS Code, he runs a background agent to build a frontend for a Python CRUD app from GitHub issue #25, a cloud agent to make the repo open-source-friendly, and a local Claude Opus 4.6 agent to write and update unit tests.
Autopilot is powerful but intentionally a little scary — Hampton uses GitHub Copilot’s preview Autopilot mode because it stops asking before every tool call, calling it “great, wonderful, can be very dangerous” and warning people not to just let it loose without guardrails.
Cloud agents run in GitHub Actions with guardrails, not as all-access bots — he highlights isolated environments, MCP-based extended context via GitHub and Playwright servers, network firewalls, and the fact they can’t push directly to main, as the answer to the inevitable “how much does this cost and how safe is it?”
VS Code is the real product story here: a single control plane for multi-agent workflows — Hampton shows a new settings modal where agents, skills, prompts, hooks, instructions, MCP servers, and even third-party setups like Claude all live in one place, with Microsoft’s open-source “Awesome Copilot” repo as a starter kit.
The Breakdown
The opening reality check on AI agents
Liam Hampton starts by calling out the fantasy that agents can solve everything with a single prompt. He ties that hype back to real business pressure — ROI, productivity gains, infrastructure spend, token costs — and even mentions a pirate-talking chatbot repo from LinkedIn as an example of how seriously people are trying to squeeze efficiency out of LLM usage.
Three kinds of agents, three levels of involvement
He lays out a simple framework: local agents, background agents, and cloud agents. Local means side-by-side and human-in-the-loop; background means more isolated and often powered through Git worktrees; cloud means “I don’t want to touch this myself,” which for him usually means documentation because, as he puts it, he hates writing docs.
Picking the right agent for the job
Hampton makes the model practical by mapping each mode to a task: local for tests, background for building a frontend, cloud for repo hygiene and open-source docs. The point isn’t that one agent is best — it’s that developers should choose based on how much they want to stay in the weeds.
The demo setup: a plain Python CRUD app and issue #25
Instead of a flashy greenfield app, he starts with a basic Python product store and a GitHub ticket asking for a prettier frontend. He uses a CLI background agent to “summarize and plan a solution to issue 25,” then turns on Autopilot — which he jokes is wonderful and dangerous because it stops asking permission for every tool call.
Three agents running simultaneously inside VS Code
While the background agent works on the frontend, he opens a cloud agent to make the repo open-source-friendly with README and contribution files, then spins up a local custom agent to write Python unit tests using Claude Opus 4.6 with medium reasoning. That’s the memorable bit: he’s not waiting on one agent at a time, he’s juggling all three in parallel from the same VS Code context.
Human-in-the-loop still matters, even with Autopilot
As the local agent writes tests and updates route error handling, Hampton keeps intervening where it matters. He also checks the background agent’s Git worktree output, catches that its test/run instructions are wrong, and corrects it before verifying the new frontend — showing that “hands-on hands-off” is still a conversation, not blind delegation.
How cloud agents actually work under the hood
He then answers the predictable questions about safety and cost by explaining that cloud agents run in GitHub Actions in isolated environments. They can use MCP servers like GitHub and Playwright for richer context and testing with screenshots, but they’re fenced in with network restrictions and no direct access to main.
VS Code as the control plane for all this
The closing section zooms out to product philosophy: VS Code is becoming the single entry point for agentic workflows. Hampton shows a recent Copilot settings modal with built-in agents like ask/explore/plan, custom agents, skills, prompts, hooks, MCP servers, and even third-party support for Claude — then points people to the open-source Awesome Copilot project and its MCP server as reusable building blocks.
Share
Keep Reading
Two Ways to Follow
The Weekly Echo. The inbox-shaped summary of what mattered.
New editorials announced here.
