[AI Assistant] Add setting for preferred type

[dgieselaar]

Adds a setting in the aiAssistantManagementSelection plugin that allows users to set the preferred Assistant type. The allowed values are:

• default: the status quo, which is: show the Observability AI Assistant in Observability apps, the Security AI Assistant in Security solution apps, and none in the other apps.
• never: Never show any AI Assistant.
• observability: Show the Observability AI Assistant everywhere, except for Security solution apps.
• security: Show the Security AI Assistant everywhere, except for Observability apps.

it is up to the solutions to respect the setting. See x-pack/plugins/observability_solution/observability_ai_assistant_app/public/hooks/is_nav_control_visible.tsx for an example. It should also be set in the specific Serverless config: config/serverless.oblt.yml.

Update: this is now labeled as an Observability-only setting.

[apmmachine]

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

• /oblt-deploy : Deploy a Kibana instance using the Observability test environments.
• /oblt-deploy-serverless : Deploy a serverless Kibana instance using the Observability test environments.
• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[dgieselaar]

/ci

[dgieselaar]

/ci

[kc13greiner]

LGTM!

One question: When

[elasticmachine]

Pinging @elastic/obs-knowledge-team (Team:obs-knowledge)

[dgieselaar]

@kc13greiner want to finish that sentence? 😀

[kc13greiner]

@kc13greiner want to finish that sentence? 😀

😆 I figured it out; I had the wrong proj type running - PR LGTM!

[stephmilovic]

Code review only, LGTM. Thanks!

[YulNaumenko]

Security Solution team didn't get a feedback from the Platform team regarding AI Assistant global availability in Kibana and didn't make a decision for making it deliverable in 8.14.
Also we want to avoid a UX, where selecting Security as preferred AI Assistant will do nothing to the user (CC: @jamesspi)

Screen.Recording.2024-03-25.at.4.00.47.PM.mov

[dgieselaar]

@YulNaumenko as mentioned on Slack, we did get confirmation. Re:

Also we want to avoid a UX, where selecting Security as preferred AI Assistant will do nothing to the user

As mentioned in the description, each solution needs to implement something that respects the setting. For Observability, that happens in this PR. For Security, that should probably happen in a follow-up. I can also remove Security as an option for now. What do you prefer? In any case, I want to avoid blocking this PR until you have implemented something on your side, as we have follow-up PRs planned.

[bojanasan]

@dgieselaar @boriskirov Would you mind sharing any Figma files/explorations for context?

I also have a few other questions:

• unless I'm misunderstanding something, the video above shows the AI Assistant in the General section of Advanced settings. The rest of General Settings items aren't visible (there's over 40 and then another 10+ sections below that). To clarify, is the proposal to add the AI settings to the top of General section?
• I'm curious if the possibility of including AI settings in the new AI Assistant page in Stack management was discussed?
• There are a number of issues with moving the AI icon into the dark header at this moment, including reduced discoverability (stylised icon vs. clearly labeled button, visual separation from the solution), crowding of icons in the dark header making it easier to overlook, the hierarchy implies a global level tool (not yet), etc. (I've shared that 90%+ of users are finding the AI Assistant button in Security) IMHO moving to the top header is not an obvious option for the Security AI Assistant atm, esp without proper vetting of that decision (we risk inadvertently decreasing discoverability).
• What was the rationale for moving the icon to the dark header? Are there discoverability issues on the Observability side?
• Is there a need to ease navigation between Stack Management and the AI assistant (we might be better off pulling some settings into the solution AI flyout in that case)?
• Or other reasons discussed for that design choice? This seems like the perfect example of a UX decision that needs alignment, its a global decision with impact to UX for all.

@dimadavid @jamesspi @grabowskit

[dgieselaar]

@bojanasan all good points and appreciate the feedback. Re: the setting, let's first figure out whether we'll want to use that approach short-term. I did ask in the Design WG channel about whether we can come up with a way to display it in the top nav without losing discoverability. I don't think we have other options than the top nav: anything outside of the top nav gets unmounted and remounted so you will lose the state of the conversation as you move between apps. This is especially an issue in docked mode.

[bojanasan]

@dgieselaar Thanks for the quick response 👍🏻 I had noticed that note in slack although it lacked the context that I needed, so it took a bit of time for me to understand the implication of the proposal.

• where you say "let's first figure out whether we'll want to use that approach short-term" (about settings) is that in reference to top of the General section, the new AI Assistant page in the left nav, or something else? I wasn't sure what you meant there.
• Also, if you don't mind expanding re: having no other option. Are you're saying that moving the button into the dark header is for the sole purpose of maintaining the sate of the conversation between the apps? What is lost with the unmounting/remouting of the flyout or conversation? Or is there more to that?

happy to take a look at any rough notes/sketches if that's faster for catching up on the context

[dgieselaar]

@bojanasan re:

where you say "let's first figure out whether we'll want to use that approach short-term" (about settings) is that in reference to top of the General section, the new AI Assistant page in the left nav, or something else? I wasn't sure what you meant there.

This is about having an advanced setting at all (to select the preferred Assistant type). So not necessarily about whether the setting is displayed - I think we can tackle that later.

Also, if you don't mind expanding re: having no other option. Are you're saying that moving the button into the dark header is for the sole purpose of maintaining the sate of the conversation between the apps? What is lost with the unmounting/remouting of the flyout or conversation? Or is there more to that?

Yes. The top nav is always there - the header below that is rendered by each app separately. That means if you move between apps, the AI Assistant component is unmounted, which means that all state is lost - things that are kept in memory, network requests that are running etc. Effectively, it means the same as refreshing the page. If a conversation has not been stored, if the LLM is currently still responding, or a function is being executed, that is then aborted and the conversation is reset to its last persisted state after remounting the component.

[dgieselaar]

@YulNaumenko as discussed, I've labeled it as an Observability-only setting. The setting name is still generic - that way we can simply add Security to the list and remove the Observability-specific labeling once you folks are ready for it (otherwise we'd have to add a new setting and remove this one).

@bojanasan for reference, we agreed we'd ship this as an Observability-only setting for now and don't advertise it. We can talk about how can polish this when Security is ready, this is a very minimal implementation for now given the changes we expect.

[dgieselaar]

@elasticmachine merge upstream

[dgieselaar]

@elasticmachine merge upstream

[dgieselaar]

@elasticmachine merge upstream

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: ff3d4f8

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
aiAssistantManagementSelection	63	65	+2

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
aiAssistantManagementSelection	2	4	+2

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
aiAssistantManagementSelection	44.9KB	44.9KB	+3.0B
observabilityAIAssistantApp	140.4KB	140.8KB	+343.0B
total			+346.0B

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
aiAssistantManagementSelection	0	1	+1

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
aiAssistantManagementSelection	4.0KB	4.3KB	+331.0B
observabilityAIAssistantApp	12.3KB	12.5KB	+160.0B
total			+491.0B

Unknown metric groups

API count

id	before	after	diff
aiAssistantManagementSelection	2	4	+2

ESLint disabled line counts

id	before	after	diff
aiAssistantManagementSelection	3	6	+3

Total ESLint disabled count

id	before	after	diff
aiAssistantManagementSelection	3	6	+3

History

• 💔 Build #201696 failed c562a73
• 💚 Build #201380 succeeded 2029f75
• 💚 Build #199175 succeeded 13a024d
• 💔 Build #198895 failed b179bdcb7ff5a80316c3161ec4d3c4eeaed6437f

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @dgieselaar

[YulNaumenko]

LGTM! Thank you, @dgieselaar for making the changes.
You may ignore that comment, but wording "Everywhere"/"Nowhere" doesn't seem to be clear - maybe "All applications" / "Disabled" 🤷‍♀️? Anyway, the general approach of the Kibana wide assistant availability is going to change that.