Release | The .NET Blog

VS Code 1.111: Agent Workflows Gain Autonomy and Debug Visibility

Emiliano Montesdeoca — Wed, 26 Aug 2026 00:00:00 +0000

VS Code 1.111: Agent Workflows Gain Autonomy and Debug Visibility

Original source: Visual Studio Code 1.111

VS Code 1.111 is the first release in the team’s move toward weekly releases, and its agent features explain why that cadence matters. The editor is making autonomous work easier to start while adding the visibility needed to understand it when something goes wrong.

The headline is Autopilot, but the more important story is the boundary around autonomy: permissions, hooks, and debug snapshots give developers ways to scope and inspect the behavior.

Three Permission Levels, One Important Decision

The Chat view now exposes session-level permission choices. Default approvals keep confirmation behavior in place. Bypass approvals automatically accepts tool calls and retries errors. Autopilot, in preview, goes further by allowing the agent to continue, answer routine questions, retry, and stop when it signals completion.

That is a real change for multi-step work. A well-scoped test update or a bounded refactor can run without a developer approving every intermediate tool call. But bypass and Autopilot also weaken the pause that normally catches a destructive command.

For .NET developers, the prerequisite is not enthusiasm. It is a recovery path. Use a feature branch or isolated worktree, make sure tests and CI gates run, and keep sensitive credentials and deployment targets outside the agent’s default reach. Autonomy is only useful when the cost of a wrong decision is contained.

Start with tasks whose acceptance criteria are executable: add tests for a known bug, update a set of mechanical call sites, or implement a small change with an existing pattern. Do not begin with an architectural migration that has no crisp completion signal.

Agent-Scoped Hooks Keep Policies Local

Hooks can now be attached to a specific agent definition rather than applied globally. This lets a specialized agent carry its own pre- and post-processing behavior without changing every other chat session.

A .NET refactoring agent could run formatting and targeted tests after an edit. A database-review agent could inspect migration output without being allowed to apply it. The key is that the policy travels with the agent’s purpose.

Preview syntax and behavior deserve testing in a non-critical repository. Keep hooks fast, make failures visible, and document the commands they run. A hook that quietly changes files or hides a failed validation is worse than no hook at all.

Debug Snapshots Turn Failures Into Evidence

The Agent Debug panel can provide event snapshots that developers attach to chat for analysis. Instead of saying that an agent “did the wrong thing,” you can inspect the tools called, the returned data, and the point where the workflow diverged.

This is particularly useful when an agent misses a project instruction or chooses the wrong configuration file. The snapshot gives the team something concrete to review and improves the next task definition or custom agent.

Debug evidence also helps with reproducibility. Capture the relevant session state, compare it with the repository’s instructions, and ask whether the failure came from missing context, an overly broad tool permission, or a flawed assumption. That is a much better feedback loop than simply retrying.

Small Release Details Matter

The redesigned chat tips help surface commands such as /init and /fork, while AI-oriented terminal profiles can be grouped for easier access. These are not the main features, but they reduce the friction of discovering and moving between the new workflow pieces.

The weekly release cadence also changes how teams should evaluate the editor. Pin versions for controlled environments, test updates on a representative repository, and keep an eye on preview features before making them part of a standard developer image.

What .NET Teams Should Do

Create a feature-branch workflow for trying Bypass approvals or Autopilot.
Use Autopilot only with explicit acceptance criteria and automated checks.
Add one narrowly scoped agent hook for formatting or targeted tests.
Capture debug snapshots when a session fails instead of relying on memory.
Keep preview settings out of production-like automation until their behavior is understood.

VS Code 1.111 does not turn autonomy into a default. It makes autonomy a configurable tool. The teams that benefit will pair that tool with isolation, tests, and a clear human review boundary.

VS Code 1.109 Makes Multi-Agent Workflows Practical

Emiliano Montesdeoca — Thu, 20 Aug 2026 00:00:00 +0000

Original source: January 2026 (version 1.109)

The Agent Choice Becomes a Workflow Choice

For a while, using an AI coding assistant meant choosing the model or subscription attached to your editor and staying with it. VS Code 1.109 moves the decision to the task level. Claude, Codex, and Copilot can take different roles, while the Agent Sessions view gives you one place to see the work.

That matters for .NET teams because the best agent depends on the boundary of the problem. A codebase-specific change benefits from repository context and established conventions. An architectural question may benefit from a second model’s perspective. A long-running refactor may be better delegated to a background or cloud session while the developer continues working locally.

The release does not remove the need for judgment. It makes the judgment visible and easier to manage.

Agent Sessions Are the Operational Layer

The important feature is not simply that more agents are available. It is that their sessions are represented together. A developer can start a local task, inspect a background task, and return to a cloud session without keeping a separate mental checklist of terminals, browser tabs, and chat windows.

For a .NET repository, imagine splitting a modernization task into three pieces: one session inventories target frameworks and packages, another examines test coverage, and a third proposes the implementation plan. The value comes from keeping those activities distinct while retaining a shared place to review their status.

This also creates a better stopping rule. A session that is waiting on a tool call, has failed a test, or needs a decision should be visible as such. That is more useful than treating every agent as an opaque request-and-response interaction.

Parallel Subagents Change Decomposition

The release also makes parallel subagent work more practical. Instead of asking one agent to research authentication, scan project conventions, and review documentation sequentially, a parent workflow can delegate focused investigations and combine the results.

The pattern works well when the tasks are genuinely independent. A .NET microservice change might need a scan of dependency injection patterns, an inventory of database migrations, and a review of CI configuration. Those investigations can run in parallel, then feed a plan that a human reviews before implementation begins.

The caveat is that parallelism increases the need for clear boundaries. Each subagent needs a narrow question, a defined output, and an explicit instruction about what it may change. Otherwise, the main agent receives several plausible but incompatible recommendations. Parallel work is a coordination tool, not a substitute for task design.

Thinking and Steering Need Calibration

The release exposes more of the reasoning experience for supported Claude workflows and adds ways to steer or queue messages while an agent is working. Both features address a real supervision problem: developers often realize halfway through a task that the agent has misunderstood the goal.

Steering is useful when the current tool call should finish but the next step needs to change. Queueing is useful when the direction is right and you want to add a follow-up without interrupting the current operation. Cancellation remains the correct choice when the agent is acting on the wrong target or the next mutation would be unsafe.

More visible reasoning can help during an architecture or security review, but it is not proof that a conclusion is correct. For quick edits, the extra detail may add noise and consume context. Choose the level of visibility based on the risk of the task.

What This Means for .NET Teams

Start with a small, repeatable workflow. Use a local Copilot session for a bounded change, ask a second agent to review the plan, and use a background session only for work that has clear acceptance criteria. Keep source control and tests as the final authority.

Document which tasks may run in parallel and which require a single reviewer. A good default is to allow parallel read-only investigation, but require approval before an agent edits project files, changes package versions, or runs deployment commands.

VS Code 1.109 makes multi-agent development easier to operate, not magically reliable. The teams that benefit most will be the ones that pair session visibility with clear issue descriptions, reproducible builds, and a review boundary that does not disappear just because several agents can work at once.