Change:
when?: string; } <ins> /** * A followup question suggested by the model. */ </ins> export interface ChatAgentReplyFollowup { <ins> /** * The message to send to the chat. */ </ins> message: string; <ins> /** * A tooltip to show when hovering over the followup. */ </ins> tooltip?: string; <ins> /** * A title to show the user, when it is different than the message. */ </ins> title?: string; } export type ChatAgentFollowup = ChatAgentCommandFollowup | ChatAgentReplyFollowup; <ins> /** * Will be invoked once after each request to get suggested followup questions to show the user. The user can click the followup to send it to the chat. */ </ins> export interface FollowupProvider { <ins> /** * * @param result The same instance of the result object that was returned by the chat agent, and it can be extended with arbitrary properties if needed. * @param token A cancellation token. */ </ins> provideFollowups(result: ChatAgentResult2, token: CancellationToken): ProviderResult<ChatAgentFollowup[]>; } export interface ChatAgent2 { /** <del> * The short name by which this agent is referred to in the UI, e.g `workspace` </del> <ins> * The short name by which this agent is referred to in the UI, e.g `workspace`. </ins> */ readonly name: string; /** <del> * The full name of this agent </del> <ins> * The full name of this agent. </ins> */ fullName: string;

Discussion:
Tracking further work on the ChatAgents2 API. Needed to fully get rid of chat API [x] A static contribution for the default agent. This is so we know to show the chat view even before the extension is activated and logged in Try to avoid a static contribution, cache that we previously had a chat provider and wait a bit for it to be registered Could optimistically register the chat agent from the extension side to speed things up [x] Add welcome message/sampleQuestions to the default agent Can add a provider for this, use a separate type for the followups [x] Add requesterUsername/icon to the default agent [x] can't use a Session object- it could take a instead? This is a weird case, shouldn't have a global function that takes a private object. Other options: a workspace uri property on the result, an argument to vscode.openFolder, a separate api command [x] can't work on a providerId. Should it be api (generic ) or an api command? It should be possible to get rid of this [x] Get rid of the global proposal event, move those types into and rename [x] Should keep its property, or should we return the same instance back to the extension in so it can add its own custom properties? [x] : Other API improvements [x] More doc comments [ ] [x]
API Feedback (apologies if I've overlooked anything): These changes seem to suggest that the only way to access the UX flow would be to register as an agent. However that seems to take away a lot of control that I would otherwise have, it seems quite strictly gated for other extensions - especially ones that do not have as much sway to influence internal VS Code development. How can I, as a third-party extension, use the chat UX after this proposal?
Sorry, I don't really understand the question. What is it you want to do? Yes, the extension model that we are focused on right now is for extensions to contribute chat agents which can be invoked through the chat view.
Apologies, I was out on vacation last week - only just saw this! What I want to do: I, as a third party extension, want to provide the most optimal user experience to my users. The chat API is a great API proposal that I have been following because it provides numerous benefits for my use case.

It is a great tool for cases where a user can provide an input or a task, and an extension can reply with an example of some proposed changes that the developer can quickly review and then accept, discard or amend. There is no alternative API that VS Code currently offers that provides a similar experience. My concern with the direction of this change: By removing this API, and requiring that developers register as a "chat agent", I am losing much of the control I would otherwise have as a third-party extension. What if I want to trigger the interactive UX from a codelens? Or from a keyboard shortcut? I believe enforcing these constraints will make it harder for extensions to build great user experiences and will be detrimental for VS Code users. Furthermore, it seems that "chat view" is "Copilot Chat"[1][2]. This raises many further concerns to me, does a user need to install Copilot before they can use my intended functionality? Does this mean I have a coupling with another third party extension? Does the user need an active Copilot subscription? I think providing both mechanisms ( and APIs) is great. I think constraining extensions to only use is bad. Referenced many times and "we the concept of agents to Copilot Chat." <img width="420" alt="image" src=""
Thanks. It is true that the extensibility experience will be based around contributing chat agents to the Github Copilot Chat view for now. But I don't think that this excludes triggering the chat from other UX surfaces like a codelens or keyboard shortcut. We are already hooking up lots of other entrypoints like quick fixes and hovers, and that will be possible for any extension.
I think gating features like this so that they can only be used via GitHub Copilot Chat is unfair to other extensions and unfair to users. GitHub Copilot Chat is one of many extensions that interface with LLMs (via chat or directing editing code). This change means that Copilot is the only extension that is allowed to use this improved user experience flow. That is not a level playing field. I hope you will reconsider this direction and consider opening up the API for other extensions.