Introduce AI Agents and tools to Build Pages from components

Currently there are 2 issues

1. The messages from the page_builder_agent are not rendering in the chatbot window. #3531955: AI-created new components cause loss of DeepChat message history
2. Once a component is selected from the canvas, the screen automatically refreshes while typing the next message. It seems that a request is somehow being triggered to the endpoint /xb/api/v0/form/content-entity/{entity_type}/{entity}/{entity_form_mode}

The changes aren’t about creating or editing components. They’re focused on adding already existing components (Only SDC as of now) to the canvas with dynamic content to help build pages. For example: “Create a section showing three key features of Drupal” or “Add a button with the text ‘Read more.’”
In my opinion, creating entire page templates (with header, body, footer, etc.) can be handled in a separate issue after the current approach is reviewed and accepted, since we’ll need to reuse a lot of the existing logic for that.

Also, have you run npm run build after pulling the latest changes? If yes, are you seeing any errors in the console?

The page builder AI agent needs both the curent layout structure (Provided by the get_current_layout tool) of the page and the details of avaialble SDCs (Provided by get_sdc_info tool). Default information tools option helps to send these direct;y along with the Agent instructions as context. So it saves two extra AI calls.

The problems mentioned in #8 still exist. But the AI agent configs and code have been pushed. Moving to needs review

Moving this back to Active for the following updates

1. Create a form that allows site builders to customize the description of SDC components and their props/slots. This saved description will be sent to the agent as context.

2. Extend the same form with a checkbox list that lets site builders choose which enabled component entities (SDCs, Blocks, Code components) should be included as context for the LLM. Currently only SDCs are allowed

Thanks for reviewing @marcus_johansson. I’ll go through your feedbacks and get back to you.

Thank you for the encouraging feedback @marcus_johansson.

I'm guessing there is another issue for editing components and their values?

Yes. Currenly only component addition is implemented. New issues will be created for updating/rearranging existing components placed in a page.
Eg: User clicks on a paragraph component and asks the agent to summarize/elaborate/replace it's content and props.

The YAML structure should be as minimal as possible (maybe already is) - the wait time is 99% invested on generating tokens, and the less tokens it needs to generate the better.

The front end only needs 2 options to add a component to the page
1. The component object
2. nodePath (An array represnting the position of the component: [0,0] -> First component, [0, 0, 0, 0] -> First component in the first slot of the first component 😬)

Initially, I tried asking the agent to generate the nodepath, but it started hallucinating when components had to be nested deep. So, in the current approach we ask the agent to provide a yml in the following format

    reference_nodepath: []  # Nodepath of any existing component placed in the page.(Agent gets it from the current layout json provided as context)
    placement: below                           # 'above' or 'below'
    components:
      - sdc.component.id:
          props:
            prop_name: "value"
          slots:
            slot_name:
              - sdc.nested.component:
                  props:
                    nested_prop: "value"
    message: "Concise 1-2 sentence summary of changes made"

and then generate the nodepath from this yml. The data for each component in the yml contains its id, prop names and values, slot names and child components.
The front end gets these details -> Loads the component objects based on ID -> Replaces the prop values and places each component at the specified nodepath.
So the yml contains only the required data.

Since we added the possibility to step through the loops it would be nice if the Orchestration Agent splits up the requests to the Page Builder Agent into loops even if this takes 3-5% extra time to produce, because then for a request like "Create me three components on the page for my pizza shop Marios Pizza", would create the first component and have a loader for that and you would see it, then it would start on the next etc. - so you see progress. #3531000: Integrate incremental agent loop execution in XB AI will be needed for this.

Something like this would definitely improve the user experience. I haven't checked #3531000: Show progress when executing prompts yet, but I'm going to give it a try.

Created #3533085: #3530733 - Followup: Incremental Component Generation for enabling looping support for the page builder agent.

Most of the other feedbacks have been addressed. Kindly review the changes again, Thanks

The components are not getting placed in the canvas when they are nested in slots of other components. Moving back to active to check this

It turned out to be a different bug. Earlier, I enabed SDDS theme and then switched back to olivero. But the components from SDDS theme were still sent to the AI agent as context. Only the components provided by the currently active theme must be provided as context to the agent

Pushed the changes. Please reviw

First, I created a code component using the prompt "Could you create a hero banner component with some text, call-to-action button, and background colour red".
Then I added the following prompt to test this MR functionality: "Create a Hero banner showing three key features of Drupal and Create a section showing three key features of PHP"
It created a HeroBanner component and 2 sections - one for Drupal and one for PHP. This seems incorrect to me.

Did it create the code component again? Also after generating the hero anner, was it added to the component library using the 'Add to components' option?
Code component generation and page building do not work together as of now. This means you cannot use a single prompt like: `Create a hero banner with text and a CTA, and place two banners on the page: one with content about Drupal and another with content about PHP.` First the component should be created and added to the libary. Then Js components should be enabled from `'admin/config/system/xb-ai-settings'` (I none selected, all components (blocks, sdcs and js components) would be provided as context to the agent. Then open the xb canvas and try to place the components using the chatbot.

The orchestratior agent may sometimes delegate the task to the code component creation agent if the prompt contains words like 'Create'. So, to test page building, we should either start the prompt with 'Add/place a hero banner...' or at the end of the prompt add '..using the page builder agent'

Updated the code as per the PR feedbacks. Kindly review again after taking latest pull and importing configs, Thanks

Created #3534854: XB AI: Centralized Management of Component Descriptions, Props, and Slots as per #32

Tested current MR with #3531955: AI-created new components cause loss of DeepChat message history. The final message from the page builder agent is not getting printed in the chatbot interface 😫 . We would have to create a followup issue for that as well

Thanks for the feedbacks @heyyo.
#45 was due to a bug in the code. I have fixed that in 37631920 . It should work now.

#44
Urls are correctly getting added if the prop type for the url field is string. Eg:

    url:
      type: string
      title: Url
      description: URL for the link button.
      examples:
        - 'https://drupal.org

It might not be working correctly for 'uri' type props. I think we could support that in #3534950: Follow-up to #3530733: Impossible to set a URL or SRC of an SDC with AI

#46
Added enum validation in b17588fd . This increases the response time, as it forces the agent to regenerate the entire response if it returns a non-existing enum value. But at least (hopefully) we won’t face the "component failed to render" error anymore.

Edit: Reverting the enum validation added in #48 as it breaks tests.

If enums prop is not required, maybe we can just removed non valid option, instead of regenerating the response again, also we can enter into infinite loop if LLM is stubborn

The max_loop setting in agents helps prevent them from going into an infinite loop. Simply removing the incorrect value might not be the best solution here, as I think we may still face the same "component failed to render" issue if the prop is required (though I haven’t tested this yet).

I think it’s better to handle this in a follow-up issue, where all of us can discuss our ideas for a proper fix.

Created #3535208: XB AI: Add enum validation

#41 is also fixed in the current MR. I think we could review & merge this now.