Change:
history: ChatMessage[]; } <ins> /** * Represents an error result from a chat request. */ </ins> export interface ChatAgentErrorDetails { <ins> /** * An error message that is shown to the user. */ </ins> message: string; <ins> /** * If partial markdown content was sent over the `progress` callback before the response terminated, then this flag * can be set to true and it will be rendered with incomplete markdown features patched up. * * For example, if the response terminated after sending part of a triple-backtick code block, then the editor will * render it as a complete code block. */ </ins> responseIsIncomplete?: boolean; <ins> /** * If set to true, the response will be partly blurred out. */ </ins> responseIsFiltered?: boolean; } <ins> /** * The result of a chat request. */ </ins> export interface ChatAgentResult2 { <ins> /** * If the request resulted in an error, this property defines the error details. */ </ins> errorDetails?: ChatAgentErrorDetails; } <ins> /** * Represents the type of user feedback received. */ </ins> export enum ChatAgentResultFeedbackKind { <ins> /** * The user marked the result as helpful. */ </ins> Unhelpful = 0, <ins> /** * The user marked the result as unhelpful. */ </ins> Helpful = 1, } <ins> /** * Represents user feedback for a result. */ </ins> export interface ChatAgentResult2Feedback { <ins> /** * This instance of ChatAgentResult2 is the same instance that was returned from the chat agent, * and it can be extended with arbitrary properties if needed. */ </ins> readonly result: ChatAgentResult2; <ins> /** * The kind of feedback that was received. */ </ins> readonly kind: ChatAgentResultFeedbackKind; }

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.