@frwang1 @bastirehm I've updated the design to reflect feedback across our UX team. I've attached the update to this comment and updated the designs above. Happy to continue iterating based on any thoughts you all have as well! I will update the designs as I complete edge case UX as well.

@ohoral Yeah, agreed. The inline error at the bottom of the chat is enough here since it's right where the user's attention already is. No need for a top banner. I think the top alert banner should be for system level errors not tied to specific chats. Otherwise inline make the most sense.

@viktomas Appears to all be captured. Looks good to me!

@ohoral For a quick fix I think that works! Only risk is that the user can't visibly see the label when the menu is collapsed if we use an icon only treatment, but I'm not sure there's space for a scalable dropdown with text. For now, let's use icon only and the selected state to disclose the selection to the user when they open the menu.

@Juhee We can come up with a more permanent labeling system in v2.

@ohoral Just to clarify you mean a clear "selected" state such as a checkbox in this dropdown?

@viktomas

Here are a few of my thoughts:

• Nested list spacing (section 2): Extra blank lines between sub-bullets, e.g. between "Install Node.js 18+" and "Configure your .env file". These should be single, tighter line spacing. This is the biggest readability issue, it makes the response feel detahced.
• Code blocks breaking list continuity (section 4): The numbered list restarts at "1. Add the build job" instead of continuing to "2." The code block between the list items seems to break the list sequence.
• Code block indentation (section 4): Code blocks under list items are indented pretty far from the list item text. Could be tighter.
• Header hierarchy (section 8): ### and #### are barely distinguishable. They're almost the same size and rely on color alone to differentiate which may create accessibility issues. Thinking we should be using typographic weight or size with more contrast to create clear hierarchy, not just color.

@viktomas Apologies for the delay on this, I've added the .md file here.

It covers the main patterns we typically see in Duo responses like numbered lists, nested bullets, inline code density, code blocks under list items, mixed content with prose, and header hierarchy. The idea is to render this through the CLI and see what breaks.

Happy to adjust any of the patterns if needed. I don't know that this precise rendering is necessarily urgent, what do you think @mcorren

Duo_MD_Rendering_Example.md

@juhee.lee @ohoral Quickest fix would be replacing the header with the agent name. If we need to keep "Gitlab Duo Agent Platform", something like below would work by adding a new label. I considered placing the label in the top right aligned with the "Gitlab Duo Agent Platform" header but I'm not sure that's scalable.

.

@ohoral @donaldcook I've added designs to this issue that should cover cancelled and timed out states. Let me know if you have any questions!

The Figma file can be found here: https://www.figma.com/design/VqpH0V6joIOokfeXS71Yqz/Duo-Agent-Platform-Side-Panel?node-id=16125-101006&t=iCh95wgKk5lA8V0X-4

@juhee.lee Good point! This panel provides some parity with the platform's designs in that "Duo Agent Platform" is also not directly labeled. I think this is okay as the user is directly chatting with an individual entity within DAP. However, if there is concern over reenforcing the brand name I think we could stack headers as is currently done in the platform. Something like below:

To note, this is a quick mock but I think some exploration around whether the "Agent Name Header" is also a dropdown to select the agent and kick off a new chat might be valuable.

What does this MR do?

This MR makes error and info alerts in the agentic chat dismissible by users. Previously, these alerts were displayed as non-dismissible banners, which could be disruptive to the user experience.

Changes:

• Made error alert dismissible in DuoChatHeader component and info alert dismiss configurable. We have a case where we show the info alert "Chat is responding in another window" which needs to be dismissible. For danger alert there is no such cases so its not configurable.
• Added dismiss-error and dismiss-info event handlers that bubble up through the component hierarchy
• Updated Storybook stories to demonstrate the dismissal functionality with local state management: run storybook and navigate to http://localhost:9001/?path=/story/agentic-chat-agentic-duo-chat--default&args=error:message;chatState.reason:test;chatState.canDismiss:!false
• Added comprehensive test coverage for the new dismiss events

Screenshots or screen recordings

Integration merge requests

• GitLab: mr_url
• CustomersDot: mr_url
• Status Page: mr_url

Does this MR meet the acceptance criteria?

This checklist encourages the authors, reviewers, and maintainers of merge requests (MRs) to confirm changes were analyzed for conformity with the project's guidelines, security and accessibility.

Toggle the acceptance checklist

Related issue

gitlab-org/editor-extensions/gitlab-lsp#1982

Conformity

• Code review guidelines.
• GitLab UI's contributing guidelines.
• If it changes a Pajamas-compliant component's look & feel, the MR has been reviewed by a UX designer.
• If it changes GitLab UI's documentation guidelines, the MR has been reviewed by a Technical Writer.
• If the MR changes a component's API, integration MR(s) have been opened (see integration merge requests above).
• Added the ~"component:*" label(s) if applicable.

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• Security reports checked/validated by a reviewer from the AppSec team

Accessibility

If this MR adds or modifies a component, take a few moments to review the following:

• All actions and functionality can be done with a keyboard.
• Links, buttons, and controls have a visible focus state.
• All content is presented in text or with a text equivalent. For example, alt text for SVG, or aria-label for icons that have meaning or perform actions.
• Changes in a component's state are announced by a screen reader. For example, changing aria-expanded="false" to aria-expanded="true" when an accordion is expanded.
• Color combinations have sufficient contrast.

@ohoral Looks great to me and more adherent to the design system to me. It reflects the design related to notification of usage limits here: https://www.figma.com/design/VqpH0V6joIOokfeXS71Yqz/Duo-Agent-Platform-Side-Panel?node-id=8295-22825&t=iCh95wgKk5lA8V0X-4 which I think aligns with our broader design system. Thanks!

@ohoral To confirm, are we moving forward with a version of the proposed solution in the related issue above? Would you like me to provide designs there?

gitlab-org/editor-extensions/gitlab-lsp#2022

@ohoral Definitely agree on the fix removing the flag.

@juhee.lee Thanks for noting this UX pattern, agreed we should surface the agent more clearly. In the most updated designs, the agent name is in the header and in the input field as an interactive dropdown, allowing the user to change agents directly from the input box. Could we opt for one or both of these in the as is? I think here the header change would be the easiest fix.