Generative AI

Sitecore Search

JAM Stack

Developer Experience

Sitecore XM Cloud

Sitecore

Cloud Development

Frontend Development

Backend Development

Optimizely

Developer Relations

Sitecore Platform DXP

Sitecore CDP/Personalize

Hello friends! I'm back and super excited to talk about a POC I’ve been working on over the past few months which is related to MCP and AI. The Model Context Protocol has been gaining significant attention over the last few months, but its use cases seem limited since most discussions center around desktop applications (of which, probably not many new to AI have ever used like Cursor or Claude Desktop). However, there's another powerful way to use MCP servers—specifically those hosted remotely (I have an upcoming post about building a Remote MCP server using Cloudflare Workers). Let's dive into this topic by first covering how to build MCP clients, then exploring how to use an existing remote MCP server (fetch) in our Client.

For today's discussion, I'm introducing a new app I've developed over the past month. It's open source (for now) and available here: [dylanyoung-dev/my-copilot: Building an app where you can do advanced Gen AI capabilities with Sitecore APIs](https://github.com/dylanyoung-dev/my-copilot). The app is hosted on the web (via Netlify) and accessible at [My Copilot](https://copilot.dylanyoung.dev/). While I'll dive deeper into this tool in future blog posts, let's focus on two key requirements: setting up an API key/token and configuring our remote MCP server. I'll guide you through a specific use case that you can follow along with, and in a future post, I'll explore the technical details of this application.

### Setting up a API Token

In this application, it has the concept of bring your own integrations, by storing the tokens needed for the different parts of the application in localStorage in the browser, the app doesn’t store your data, so no need to worry about data breaches, as long as you protect your device from being used by others.  You can navigate to Open AI, login and grab an API Key, to do this specifically, just follow the steps listed here: [Where do I find my OpenAI API Key? | OpenAI Help Center](https://help.openai.com/en/articles/4936850-where-do-i-find-my-openai-api-key), or if you’d like to use Anthropic, follow these steps here: [How can I access the Anthropic API? | Anthropic Help Center](https://support.anthropic.com/en/articles/8114521-how-can-i-access-the-anthropic-api).

![](https://cdn.sanity.io/images/lanua4su/production/5430604d6e7c3959232d9a50ecb978f145906c51-1279x575.jpg)

Once you have your key, find the API Tokens link on the left side of the application, or navigate directly to this page: [Sitecore Copilot](https://copilot.dylanyoung.dev/settings/config). Click the "Add Token" button to open a modal. In the Token Category, select `AI Services` and choose your provider—either openai or anthropic. Give your token a name, paste in the token you generated earlier, and you're all set. For future use, check out the Import/Export page, where you can save your configuration (API Tokens, MCP Servers, and Sitecore Instances) to a file. This backup comes in handy if your browser's local storage resets or if you switch browsers, saving you from repeating the setup process.

![](https://cdn.sanity.io/images/lanua4su/production/92bc3bf2ca9e1206be7293d92c109ab0b0a23f72-1278x633.jpg)

### Setting up a Remote MCP Server

Now let's cover setting up a remote MCP server. Unlike desktop applications like Claude Desktop, GitHub Copilot, and Cursor that run MCP servers locally, our hosted application can only use remotely hosted MCP servers—similar to how you'd use an API server. These remote servers must support SSE or HTTP Streams. The MCP server we'll use today is simple, requiring no additional authentication. While my app doesn't yet support the standard OAuth flow, this feature is coming soon. Atlassian provides a good example of OAuth implementation—when you interact with their MCP remote server, it knows who you are and provides access to your specific items like tickets or projects. You can also add header information, which I'll cover in a future blog post about building our own Remote MCP server. While there aren't many remote MCP servers available currently, this approach will likely become the preferred method. After all, if you have a project with an API, creating a remote MCP server that works both locally and remotely makes perfect sense.

Let's walk through setting up our Fetch remote MCP server. My copilot includes a process for defining preconfigured MCP servers, offering both preconfigured and custom options. Navigate to `Configure MCP` and click `Add MCP Server` to see these options in a popup modal. We'll focus on the preconfigured option today. When you click it, you'll see several choices—though currently, Fetch is the only fully functional option. Select "fetch," and since it needs no additional configuration, it will immediately appear in your list of configured remote MCP servers. That's all you need to get started.

![](https://cdn.sanity.io/images/lanua4su/production/9a636f0f4c8a719883766d306266336d491bee7a-1282x745.jpg)

### A Quick Demo

Now that you have your environment configured with at least one MCP Server and one API token for an LLM like Anthropic or OpenAI, navigate to the "Copilot" link in the left-hand navigation. You'll see a Chat interface that you can interact with. If you've skipped ahead to this section, you'll see a message indicating that you need to configure an API token first—this is required for the interface to work. Note that you don't need to have tools configured to use the chat interface.

On the chat page, you can select different models to use with the chat window. We currently support Anthropic and OpenAI models, but you'll only see the options for models whose API tokens you've configured.

In the bottom left of the chat window, you'll find a gear icon. Clicking it reveals your list of configured MCP servers. While you can have hundreds of MCP servers configured, it's best to toggle off the ones you don't need for your current chat session. A smaller list of active tools helps the chat interface select the appropriate tool and respects the limits on tools per chat request. For our current use case, we'll simply ensure the `Fetch` option is enabled.

![](https://cdn.sanity.io/images/lanua4su/production/ffb258898629b1f2b1bf588409f61d25cc13e686-1281x845.jpg)

Now that we're ready to test the application, let's start by asking the chat interface about available tools.

When I asked "What tools are available to me?" I received this response:

![](https://cdn.sanity.io/images/lanua4su/production/8c3282bd356b065e2125f8991baab79fdef8952b-1278x1151.jpg)

From here, it's straightforward to use the tool. Simply provide a URL and ask it to explain the page contents. For example, I used this prompt: `Can you fetch:` [`https://www.sanity.io/`](https://www.sanity.io/) `and can you summarize the contents of this page?` The tool responded with a concise summary of the page. Note that some URLs weren't accessible, likely due to Cloudflare's request blocking.

You now have access to this powerful tool, and there are many exciting features in development—including a dedicated remote MCP server for Sitecore Personalize, which you can glimpse in some screenshots. Stay tuned for a blog post about that in the coming weeks. If you'd like to suggest new features or report issues, please visit the Github page and submit an "issue" or "feature" request.

Artificial Intelligence

AI Friday: Building a Hosted MCP Client and Consuming a Remote MCP Server

Hello friends! It's been a while since I last posted, but today I'm excited to share a first look at a newly released feature for Sitecore Personalize and CDP. This new feature combines my two favorite things—personalization and artificial intelligence (AI). It addresses one of the key challenges I've been trying to solve: the difficulty of building experiences and experiments with Sitecore CDP and Personalize.

## What is the Code Assistant?

The Code Assistant is an AI-powered tool that integrates directly into Sitecore Personalize's code editing experience. It helps developers write code specifically within the Sitecore Personalize context. The product has traditionally required specific technologies and JavaScript variations for creating assets—a complexity that challenges even developers familiar with modern JavaScript.

This is where the new Code Assistant will provide significant value for developers. I believe this is just the beginning—there may be opportunities for marketers to use the code assistant to create experiences as well. Last year, I wrote an article [Revolutionizing Sitecore Personalize: Unleashing the Power of Generative AI Function Calling](https://dylanyoung.dev/insights/revolutionizing-sitecore-personalize-unleashing-the-power-of-generative-ai-function-calling/) on a similar topic, exploring how to use an LLM to generate experiences through prompts. While that approach had limitations and was intended as a proof of concept, it makes me excited to see these innovations coming to the product.

In this initial release, you can use the Code Assistant to craft code for Conditions (compatible with XM Cloud when used alongside Personalize), Session Traits (a recent addition), and Audience Export. You'll find it in any section that requires code writing. While Session Traits and Conditions are straightforward to use, for Audience Export you'll need to specify an output format using the `Advanced` option.

For more information about how to use the new feature, refer to the [documentation](https://doc.sitecore.com/cdp/en/users/sitecore-cdp/ai-in-cdp.html) or the [release notes](https://developers.sitecore.com/changelog/cdp/05062025/introducing-your-ai-powered-code-assistant-in-cdp).

## Hands-on Use Cases

### Working with Conditions

In my exploration of the Code Assistant, I tested its capabilities with conditions and discovered several key features:

- The assistant analyzes existing code and suggests performance improvements
- It provides a code output view with copy and replace options
- Though it can refactor code to improve readability (such as creating separate functions), performance gains are often modest
- I encountered a few limitations:
	- The assistant lacks conversational feedback—more context around its suggestions would be helpful
	- When seeking code improvements, I had to manually compare the full suggestion against my existing code

I tested a use case for a Condition that would determine the user's state—specifically whether they were a Visitor or Known user. I provided this prompt to the Code Assistant: `Create a Condition that determines the user guest Type. It should allow me to specify the type as a parameter and then returns true or false if the user has that type`. Here's the snippet it generated:

```javascript
(function() {
    var specifiedGuestType = "[[guest type | enum(customer, visitor, member) | customer | { required: true }]]";
    var returnValue = false;

    if (guest && typeof guest.guestType === "string") {
        returnValue = (guest.guestType === specifiedGuestType);
    }

    return returnValue;
})();
```

The output isn't perfect—member and customer aren't valid types, and it doesn't generate a description (such as "Is the current visitor [guesttype]"). Like with all AI tools, we can't blindly trust its suggestions, but it does provide a solid starting point.

### Session Traits Implementation

One of the most valuable applications I discovered was creating session traits. Let me show you an example of how the assistant helped develop a keyword tracking system:

```javascript
(function ai_generated_function() {
    var keywordTracker = {};

    for (var i = 0; i < triggerSession.events.length; i++) {
        var event = triggerSession.events[i];

        if (event.type === 'VIEW' && event.arbitraryData.keywords) {
            var keywords = event.arbitraryData.keywords.split(',');

            for (var j = 0; j < keywords.length; j++) {
                var keyword = keywords[j].trim();
                keywordTracker[keyword] = (keywordTracker[keyword] || 0) + 1;
            }
        }
    }

    var sortableKeywords = [];
    for (var key in keywordTracker) {
        sortableKeywords.push([key, keywordTracker[key]]);
    }

    sortableKeywords.sort(function(a, b) {
        return b[1] - a[1];
    });

    var topFiveKeywords = sortableKeywords.slice(0, 5).map(function(keywordArray) {
        return keywordArray[0];
    });

    print("Top five keywords: " + topFiveKeywords);
    return topFiveKeywords.length > 0 ? topFiveKeywords : null;
})();

```

I haven't used Session Traits before myself, but here's what they do: they let you collect metrics from the current viewing session and tracked events, then use JavaScript to store specific data points back to the guest's profile. For example, you could analyze a user's entire viewing history from their last session to make determinations about them. This capability would greatly enhance the behavioral personalization strategies I covered in my previous article—I'll need to update that piece to incorporate these Session Traits.

### Audience Export

As mentioned, the Code Assistant also supports formatting output for Audience Export. While I haven't extensively tested this feature yet, I wanted to note its availability. I plan to cover Audience Exports more thoroughly in a future blog post.

## Limitations and Areas for Improvement

- The chat interface needs to be closed and reopened to start new sessions
	- However, this limitation may not be significant since each additional message only considers your current code state and prompt, rather than the entire conversation context.
- I encountered several cases where the tool's performance fell short, which I won't detail in this post. However, the good news is that as AI models improve, these limitations should become less frequent. Also I know they ground the model suggestions as well, so as they fine-tune the output, these will also decrease these scenarios.
- As mentioned previously, it would be helpful to have a way to merge the suggested code snippets with existing code.

## Conclusion

The Sitecore Personalize Code Assistant marks a significant advancement in simplifying personalization development. Though it has current limitations, the tool shows great potential for speeding up code creation and boosting developer efficiency. As it matures, it's likely to become essential to the Sitecore Personalize development process—especially for developers working with conditions and session traits.

Personalization

First Look: Sitecore Personalize Code Assistant

Hello friends! A few weekends ago, I participated in the Sitecore Hackathon 2025—a 24-hour event that starts at 7 PM on Friday and ends at 8 PM EST on Saturday. But wait, that's 25 hours? Well, the first hour is dedicated to brainstorming an idea based on the provided category. This year, our team—team DED (named by combining the first letters of team members Dylan, Dan Solovay, and Erica Stockwell-Alpert)—used that entire hour to develop our concept. The category gave us freedom to build anything we wanted. While we initially considered creating a CLI for IAR files, we ultimately settled on an idea that energized the whole team. I was particularly excited because it aligned with my work on the Sitecore Assistant and would expand the tool in a new direction (which I'll discuss later when covering the Hackathon outcomes).

## The Idea

We decided to build something similar to the Sitecore Assistant tool, expanding upon a tool that Erica had developed for XM/XP. However, since Sitecore XM Cloud's landscape has changed and traditional package installation methods no longer work, we created an XM Cloud replacement—a separate Next.js application that integrates with both the XM Cloud Edge/Delivery APIs and the Authoring/Management APIs. The app's architecture allowed us to deploy it to Vercel (check it out here: [https://sitecore-content-export.vercel.app](https://sitecore-content-export.vercel.app/)). Taking inspiration from the Sitecore Assistant, we added a Copilot feature that pulls content from the Delivery/Edge API. Though we had to rush the interface, the potential is enormous. I particularly loved our tech stack choice—Next.js, Tailwind, and ShadCN for the UI. Even with my limited UI experience, I breezed through the interface development using Vibe code, and the results were fantastic.

## My Overall Thoughts

This was definitely one of the best Hackathons I've ever experienced. With AI by my side, I never felt stuck—I could use it to overcome any obstacle. I primarily relied on GitHub Copilot, which proved invaluable for 90% of situations. Rather than getting bogged down wondering how to build something, I could simply ask how to refactor the code to achieve specific goals, and I was off to the races.

That said, Copilot Edits has its drawbacks—it frequently overwrote my changes, causing me to lose code, and its formatting leaves much to be desired. Still, Copilot's chat feature has been transformative for my productivity. When Copilot occasionally struggled, I turned to Claude 3.7, which was phenomenal for coding modifications. I could even attach photos and draw on them to illustrate the issues I was facing, and somehow it understood and resolved them perfectly.

AI particularly excels at UI work, and the latest models are clearly improving rapidly in this area. While I'm uncertain about when it might replace humans—I encountered some challenges with AI in another post-hackathon project—it proved to be an invaluable tool for enhancing the UI. I successfully created a stunning UI for the Chat app, which I'll definitely incorporate into future applications.

![](https://cdn.sanity.io/images/lanua4su/production/c2668dbb966d589b04d7c93b1f1ac594926354db-1285x838.png)

## The Outcome

I was impressed with what we were able to create. I plan to make several improvements to both the Sitecore Assistant and this new application. For the app we built during the hackathon, I'll first enhance the API Instance configurator. The initial version was confusing, so I'm rebuilding it to be more flexible and allow for future Sitecore integrations, such as Personalize. While helping Erica enhance the Instance configuration, I also plan to bring more features into the original tool. I learned an important distinction between Session Storage and Local Storage—Session Storage only persists during the current browsing session, while Local Storage remains across multiple browsing sessions indefinitely. This storage functionality is one of the tool's features I'm most proud of, as it allows anyone to configure instances and start using them with their environments. Of course, if we pursue adding this to the Marketplace, we'll need to do additional development work to meet their requirements.

I plan to rename the Sitecore Assistant to Sitecore Copilot and transform it into a multi-agent tool that handles content, personalization, and future capabilities. I'll incorporate the UI we built for the Hackathon submission into Sitecore Copilot and develop advanced chat interfaces that integrate with other Sitecore systems. Additionally, I hope to bring the content-related copilot enhancements back into the Hackathon submission.

I'll share more details about these enhancements to the Sitecore Assistant (Copilot) in my next few posts. Overall, it was an excellent Hackathon experience—our team collaborated seamlessly, and I'm already excited for the next one.


Next.js

Sitecore Hackathon 2025: Team DED - My Thoughts and Review My Contributions

Hello everyone! I'm back in 2025 after a three-month hiatus—I've been busy moving to a new home, which hasn't left much free time. I've also started a new position at Velir, where I'm working extensively with XM Cloud implementations. While I had some experience before, I'm now diving much deeper into the technical details, and I'll be sharing these insights with you. Today, I'll explain how I solved a particular XM Cloud challenge.

Recently, I created a complex component in Sitecore XM Cloud using Integrated GraphQL ([Integrated GraphQL in JSS apps | Sitecore Documentation](https://doc.sitecore.com/xmc/en/developers/jss/latest/jss-xmc/integrated-graphql-in-jss-apps.html)). While building this component, I encountered a challenge—the component required a complex GraphQL query with multiple nested levels, which triggered the following error:

```jsx
{
  "errors": [
    {
      "message": "Query is too nested to execute. Depth is 17 levels, maximum allowed on this endpoint is 15.",
      "extensions": {
        "code": "INVALID_OPERATION"
      }
    }
  ]
}
```

After encountering this issue, I needed to determine the best solution. While searching online, I found that most articles recommended patching the XM Cloud configuration—which is strongly discouraged in Sitecore XM Cloud. This reminded me of my early days learning Sitecore: just because someone writes an article about a solution doesn't mean it's the right approach. Though patching a configuration isn't quite as problematic as creating custom .NET extensions, it was evident this wasn't the optimal path forward. Here's an example of the patch configuration method that I decided against:

```jsx
<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/"
  xmlns:set="http://www.sitecore.net/xmlconfig/set/"
  xmlns:role="http://www.sitecore.net/xmlconfig/role/"
  xmlns:env="http://www.sitecore.net/xmlconfig/env/">
  <sitecore>
    <api>
      <GraphQL>
        <defaults>
          <security>
            <publicService type="Sitecore.Services.GraphQL.Hosting.Security.GraphQLSecurity, Sitecore.Services.GraphQL">
              <complexityConfiguration type="GraphQL.Validation.Complexity.ComplexityConfiguration, GraphQL">
                <maxDepth>15</maxDepth>
                <maxComplexity>2000</maxComplexity>
                <fieldImpact>2</fieldImpact>
              </complexityConfiguration>
            </publicService>
          </security>
        </defaults>
      </GraphQL>
    </api>
  </sitecore>
</configuration>
```

This experience inspired me to write this blog post once I found a solution. It's worth noting that I tried different GraphQL approaches, switching from a datasource query to a search query. However, the query depth limit remained the same regardless of the GraphQL type used.

## Splitting up the Query

As the title suggests, I needed to split up the query to retrieve all necessary data without triggering the error mentioned above. Since these pages are statically generated, making multiple requests is a reasonable approach—it's far less problematic than it would be if we were making these requests on every page load.

While researching this topic, I identified key requirements for the correct approach. The component needed to render on initial page load rather than loading dynamically afterward. While there are cases where you might want an initial interface followed by asynchronous data fetching from Edge GraphQL, I wanted everything to load seamlessly at once. Though both options I'll discuss would satisfy this requirement, I also had to consider how each approach would affect the content editing experience within pages. Before diving into these two approaches, I should mention the Sitecore XM Cloud Accelerate documentation, which thoroughly explains the benefits and drawbacks of the different data fetching methods: [Getting Component Specific Data | Accelerate Cookbook for XM Cloud | Sitecore Developer Portal](https://developers.sitecore.com/learn/accelerate/xm-cloud/implementation/external-data-integration/getting-component-specific-data#related-recipes).

### Using a Placeholder

The first approach is separating the inner components and their data into Placeholders. The issue, as I alluded to above, is that this complicates Page Builder. A component that could be handled as a single unit would now require content authors to drop one component and then immediately drop a second component. This isn't ideal due to that extra complexity. There has to be a better way.

However, this placeholder method can make sense in certain cases, particularly when data is difficult to manage elsewhere and you want to give content authors flexibility in building components with multiple nested elements. For cases where the data structure remains constant, you may want to consider using the Linked List approach, which I'll discuss in a future post.

### Using Component Level Data Fetching

Let's explore the better approach: component-level data fetching. This method allows your component to fetch any additional data needed for your website. Whether it's third-party data or, in this case, breaking down a complex GraphQL query into manageable pieces. I chose to remove all Integrated GraphQL (though I could have simply simplified it to include only what I needed) since working without it seemed more straightforward. I implemented `GetStaticProps` at the component level. For those familiar with traditional Next.js development, this might seem unusual—typically, you'd pass complex objects at the page level and drill props down to their respective components. However, JSS enables these additional requests at the component level, which both simplifies data access and eliminates the need for extensive prop drilling from the page component.

<aside>
⛔

**Important note:** Since `getStaticProps` and `getServerSideProps` are bundled on the client side, be cautious not to include any sensitive information in these functions.

</aside>

Let's take a closer look at the code for our component. The original complex component wired up with XM Cloud handles only its datasource fields, while I use those same fields to construct `additionalFields`, which I hydrate from the `getStaticProps` function:

```jsx
export type HeaderFields = {
  additionalFields: {
    item: {
      megaMenuLinks: {
        targetItems: {
          ...
        }
      }
    }
  };
  fields: {
    logo: ImageField;
    fieldA: TextField;
    fieldB: TextField;
    fieldC: TextField;
    ...
  }
}

export HeaderProps = ComponentProps & PlaceholderProps & HeaderFields;

const Default = (props: HeaderProps): JSX.Element => {
  const { fields, additionalFields} = props;
  
  ... (Rest of the Code to Render Fields)
}

export const getStaticProps: GetStaticComponentProps = async (rendering, layoutData) => {
  const graphQlClient = graphqlClientFactory();
  
  const response = await graphQlClient.request<HeaderAdditionalFields>(headerQuery, { datasource: rendering.dataSource, language: layoutData.sitecore.context.language, });
  
  return {
    externalFields: response || {},
  };
};
  
```

To complete the picture, I should mention that `headerQuery` is simply a datasource GraphQL query stored in a separate TypeScript file.

When you find recommendations to customize the patch config, avoid that approach. Instead, re-engineer your component and break up your request into smaller, manageable pieces. Patching the configuration is a slippery slope—while we might only need a few more nested levels now, future queries could require even more depth, tempting us to keep increasing the limit beyond what's appropriate. This approach also isn't future-proof: what happens if Sitecore removes the ability to customize this configuration? As XM Cloud developers, we must build solutions that will stand the test of time.

Sitecore XM Cloud: The Correct Way to Resolve GraphQL Too Nested to Execute Issue

Sitecore Symposium Recap 2024

Welcome back, friends! In today's blog post, we're building upon my previous article where I discussed using the SDK to create a flow (also known as an Experience). We're taking it a step further by combining this topic with Generative AI. Specifically, we'll explore Function Calling—a concept that allows you to inform Generative AI about available functions and have it select the appropriate function and object based on given requirements. This powerful approach enables AI to dynamically interact with predefined functionalities.

I'm excited to announce a new repository I've been working on that leverages this capability. It's called the Sitecore Assistant. While others may have created similar tools in the past, I wanted to build something tailored for the new composable SaaS landscape—a tool you can run locally or host remotely, allowing users to interact with their Sitecore Cloud instance.

I have big dreams for this app, combining AI with the Personalize SDK and potentially more SDKs in the future. You can find the repository here: [dylanyoung-dev/sitecore-assistant: Building a local-based (or hosted) app that users can configure for their Cloud Portal environment to handle advanced use cases. (github.com)](https://github.com/dylanyoung-dev/sitecore-assistant).

It's a straightforward Next.js application. If you prefer not to use the AI capabilities, simply don't add the OpenAI API key, and it'll disable the chat feature. This project is still a work in progress, so stay tuned for future announcements.

I'm considering building a Nextron shell (since it's using Next.js) in the future, which would allow it to run as an executable on your PC or Mac. Sometimes I feel like I have too many ideas! If you're interested in contributing, reach out to me, and we can discuss the vision further.

This project represents a topic tangential to today's discussion, but one I hope to explore more in the future: how to extend Sitecore XM Cloud or other composable products with new functionality. In the past, you'd build modules and install them directly into Sitecore XM/XP, but this approach required modifying the core code—a practice that doesn't align well with our current SaaS landscape. Today's post offers a glimpse into this new project, and I plan to delve deeper into this topic in future articles. Stay tuned!

## What is Generative AI Function Calling?

Today, we'll utilize the chat interface I've built into that application, incorporating OpenAI Function Calling. This powerful concept works as follows: when a user asks a question like `Can you help me create an experience`, it sends the request to an API endpoint I've configured in Next.js. Behind the scenes, it executes a series of tasks that unfold like this:

1. Pass the current message and all available function specifications to the LLM.
2. Based on the input and available functions, it determines if any functions can be used and if it has the required input to call them. If not, it returns details to the user, prompting for more information or guiding them towards the correct function (if multiple are defined).
3. If it has all the necessary information, it returns the function and required parameters to the code running in the API request. You can then parse and run the function, or—as we'll see—use OpenAI's beta functionality to define a function structure and the function to run, allowing it to handle the function call for you.
4. Once the function returns data (such as from an API call or web scraping), it passes this back to the LLM, which formulates a response based on your original request.

This concept becomes incredibly powerful when you consider its potential. You could chain functions together, combine it with a Retrieval-Augmented Generation (RAG) approach, or even integrate it with a custom or fine-tuned Language Model (LLM) to achieve highly refined, actionable results. In today's examples, we'll leverage the Sitecore Personalize SDK—which I've been discussing over the past few months—and combine it with our Chat application. This integration will enable our Chat application to create experiences on our behalf.

## Creating an Experience in Personalize

Let's dive into our code to see how we can create an experience using a chat application. I've already shared the repository in the first part of this article, so refer there for the full source. Our application is currently built with Next.js, as I plan to host it on the web and need to keep my OpenAI key secure. This setup is crucial to understand because the chat application features a chat box (running inside a modal) where users input their commands. These commands are then sent to an API route hosted in Next.js, which handles all the OpenAI magic with Function Calling. This API route is responsible for sending code to OpenAI, managing system messages, defining and using Function Calling, and providing the functions that the code will execute. We also pass in all currently configured clients, which are used to authenticate with various services for asset creation.

Now, let's examine the API route code:

```typescript
const client = new OpenAI({ apiKey: process.env.OpenAI_API_KEY });

interface Message {
  sender: "user" | "assistant";
  content: string;
}

interface ChatRequest {
  message: string;
  messages: Message[];
  clients: ClientData[];
}

export async function POST(req: NextRequest) {
  try {
    const { message, messages, clients }: ChatRequest = await req.json();

    const combinedMessages: ChatCompletionMessageParam[] = [
      {
        role: "system",
        content:
          "You are the Sitecore Assistant which will help users create Sitecore assets in the Sitecore SaaS products.  When running Sitecore Personalize apis that require code, always use EcmaScript 5.0 javascript that would work with Server Side Nashorn Javascript Engine.",
      },
      ...messages.map((msg) => ({
        role: msg.sender,
        content: msg.content,
      })),
      { role: "user", content: message },
    ];

    console.log({ clients });

    const runner = await client.beta.chat.completions
      .runTools({
        model: "gpt-4o-mini",
        messages: combinedMessages,
        tools: [
          await CreateExperienceTool(clients),
          await GetFlowsTool(clients),
          await ListOfExperiencesTool(clients),
        ],
      })
      .on("message", (message) => {
        console.log(message);
      })
      .on("functionCallResult", (result) => {
        console.log("result", result);
      });

    const finalContent = await runner.finalContent();

    return NextResponse.json({ message: finalContent });
  } catch (error) {
    console.error("Error generating AI Response:", error);
    return NextResponse.json(
      { error: "Error generating AI Response" },
      { status: 500 }
    );
  }
}
```

Let's dissect this code. Within our API route, which processes a POST request from our chat application, we find the following crucial segment:

```typescript
const combinedMessages: ChatCompletionMessageParam[] = [
  {
    role: "system",
    content:
      "You are the Sitecore Assistant which will help users create Sitecore assets in the Sitecore SaaS products.  When running Sitecore Personalize apis that require code, always use EcmaScript 5.0 javascript that would work with Server Side Nashorn Javascript Engine.",
  },
  ...messages.map((msg) => ({
    role: msg.sender,
    content: msg.content,
  })),
  { role: "user", content: message },
];
```

This code serves two primary functions. First, it provides initial context to our Language Model (LLM), instructing it on its identity and the services it's designed to offer. It also supplies context regarding the JavaScript format required for Sitecore Personalize. Second, the code manages short-term memory considerations. This is crucial as we aim for a conversational interaction with our LLM, allowing us to craft our Personalize experience through multiple prompts.

Next, let's examine a crucial part of the code:

```typescript
const runner = await client.beta.chat.completions
  .runTools({
    model: "gpt-4o-mini",
    messages: combinedMessages,
    tools: [
      await CreateExperienceTool(clients),
      await GetFlowsTool(clients),
      await ListOfExperiencesTool(clients),
    ],
  })
  .on("message", (message) => {
    console.log(message);
  })
  .on("functionCallResult", (result) => {
    console.log("result", result);
  });
```

This code snippet is crucial for enabling AI Function Calling. We're utilizing the OpenAI Node SDK ([openai/openai-node: The official Node.js / Typescript library for the OpenAI API (github.com)](https://github.com/openai/openai-node)), specifically its new beta feature for running Tools in chat completions. We're also employing OpenAI's latest model, `gpt-4o-mini`. The real magic happens when we define our tools—in this case, three examples that perform these key actions:

- Creating a Web Experience
- Getting Back a Specific Experience/Experiment based on a ref
- Getting a List of Experiences

One fascinating aspect I discovered while working with the LLM is its ability to extract required values from unexpected sources. This capability stems from its understanding of function requirements. For instance, after creating an experience, you can prompt the LLM to retrieve additional details about it. It accomplishes this by running the GetFlowsTool, knowing that the reference ID—obtained from the experience creation—is sufficient for this task.

Now, let's examine the final crucial component: the function definition and the function that executes when all the correct parameters for creating an experience are provided. Let's take a look at the code for `CreateExperienceTool`:

```typescript
export const CreateExperienceTool = async (clients: ClientData[]) => ({
  type: 'function' as const,
  product: ProductOptions.PersonalizeCDP,
  function: {
    name: 'create_personalization_experience',
    type: 'function',
    description: 'Creates a new personalization experience in Sitecore Personalize.',
    parameters: {
      type: 'object',
      properties: {
        name: {
          type: 'string',
          description: 'The name of the personalization experience.',
        },
        type: {
          type: 'string',
          enum: ['Web', 'API', 'Triggered'],
          description: 'The type of the experience.',
        },
        channels: {
          type: 'array',
          items: {
            type: 'string',
            enum: ['Call Center', 'Email', 'Mobile App', 'Mobile Web', 'Web', 'SMS'],
          },
          description: 'The channels for the experience.',
        },
        assets: {
          type: 'object',
          properties: {
            html: {
              type: 'string',
              description: 'The HTML content for the experience, use pure HTML only.',
            },
            css: {
              type: 'string',
              description: 'The CSS content for the experience, do not use precompiled CSS, only pure CSS.',
            },
            js: {
              type: 'string',
              description:
                'The JS content for the experience which needs to use Nashorn Engine compatible ES5 Javascript.',
            },
            freemarker: {
              type: 'string',
              description:
                'This is used to define the API response information using free marker syntax for the experience.',
            },
          },
        },
      },
      required: ['name', 'type', 'channels'],
    },
    function: async (args: { params: any }, runner: any) => {
      return await createPersonalizationExperience(args, clients);
    },
    parse: JSON.parse,
  },
});
```

There's a substantial amount of code here, so let's focus on the key points rather than delving into every detail. First, we define the overall description of our function. This description informs our LLM about the function's purpose and use case. Next, we have the `parameters` section, which describes all the fields or parameters that need to be provided. There's also a separate `required` property, as some fields aren't necessary in this example. The assets—such as JavaScript, HTML, and CSS—are only needed if we have a variant. As we've discussed previously, these aren't always required to create an experience, though they're certainly valuable to have (especially when provided by our LLM). We can specifically instruct the LLM to generate the HTML, CSS, and JavaScript for our variant by requesting it to create these values.

Finally, at the bottom of the function definition, we have:

```typescript
function: async (args: { params: any }, runner: any) => {
	return await createPersonalizationExperience(args, clients);
},
parse: JSON.parse
```

Here's how it works: Once the LLM determines all the necessary parameters, it executes the function using those parameters. The `parse` function simply parses the parameters passed through the `args` parameter. After the function runs, its result is fed back into the LLM, which then generates a response based on the function's output. Let's take a quick look at the code for the `createPersonalizationExperience(args, clients)` function.

```typescript
export const createPersonalizationExperience = async (args: any, clients: ClientData[]) => {
  let personalizeClient;
  if (args !== undefined && clients !== undefined) {
    const clientDetails = clients.find((client) => (client.product = ProductOptions.PersonalizeCDP));

    if (!clientDetails) {
      return {
        status: 'error',
        message: 'You must have a client configured for Personalize/CDP to create an experience.',
      };
    }

    personalizeClient = new Client({
      clientId: clientDetails.clientId,
      clientSecret: clientDetails.clientSecret,
      region: mapRegion(clientDetails.region),
    } as IClientInitOptions);
    const flowTypeMapping = mapFlowType(args.type);

    console.log(args);

    if (!flowTypeMapping) {
      console.log(flowTypeMapping);
      return {
        status: 'error',
        message: `Invalid flow type: ${args.type} it should match one of the following: Web, API, Triggered`,
      };
    }

    const experience: IFlowDefinition = {
      name: args.name,
      friendlyId: args.name.toLowerCase().replace(/\s+/g, '_'),
      type: flowTypeMapping,
      channels: args.channels.map((channel: string) => FlowChannel[channel as keyof typeof FlowChannel]),
      status: FlowStatus.Draft,
      schedule: {
        type: FlowScheduleType.Simple,
        startDate: new Date().toISOString(),
      },
    };

    // Check if any of the fields in assets are provided
    if (args.assets && (args.assets.html || args.assets.javascript || args.assets.freemarker || args.assets.css)) {
      experience.variants = [
        {
          name: 'Default Variant',
          assets: {
            html: args.assets.html || '',
            js: args.assets.javascript || '',
            css: args.assets.css || '',
          },
          templateVariables: {},
          ...(args.assets.freemarker && {
            tasks: [personalizeClient.Flows.CreateTemplateRenderTaskInput(args.assets.freemarker)],
          }),
        },
      ];
    }

    try {
      console.log('Creating personalization experience:', experience);
      let response = await personalizeClient.Flows.CreateExperience(experience);

      return {
        status: 'success',
        message: 'Personalization experience created successfully.',
      };
    } catch (error: any) {
      return {
        status: 'error',
        message: `Failed to create personalization experience: ${error.message}`,
      };
    }
  }

  let response = await console.log('Creating personalization experience:', args.params);
  return {
    status: 'fail',
    message: 'Parameters are missing for creating a personalization experience.',
  };
};
```

I won't go through the code line by line, but I'll explain the logic to help you understand what's happening. First, we perform some type checking to ensure we have valid clients and arguments. We also verify that the available clients are for Sitecore Personalize—a specific requirement for our application that might differ depending on your use case.

After confirming the passed data, we create a `Personalize Client` instance, initializing the Sitecore Personalize SDK. We then create a new IFlowDefinition object to build our experience. We check for any asset information for our variant and include it if available. With a valid Flow Definition, we call `personalizeClient.Flows.CreateExperience(experience);`, passing in our newly created definition. The response is then used to inform the app of successful completion. We could enhance this by returning the flow definition details, which the LLM could then display. This represents the current state of our proof of concept, with more iterations and improvements on the horizon. Keep an eye on the repository for future updates—the potential use cases are only going to expand from here.

## The Flow

We've explored how to create an experience using AI Function Calling with an LLM (in our case, the OpenAI GPT model). But what does the application flow look like today? It's actually quite simple to create our asset. If you're new to running this app, you can simply ask, "What are my options?" This will return all the Function Calling definitions available to you. You could also say, "I'd love to create a web experience today." This helps the system understand that you're trying to create an experience, specifically a "Web" experience, which it can use for some of the parameters.

Now, with these basic instructions, the system would likely create an experience without a variant, which isn't particularly helpful. To enhance this, you could ask something like: `It would be great if the experience used a web popup to display that I have a discount available. Could you help me generate this?` This prompt signals to the LLM that you want help generating code for your experience, which will become your default variant. Typically, after running this, it'll generate a sample and ask if you like the output and want to proceed with creating the experience. It's quite impressive that once you confirm, it will create your experience using the function code we previously discussed.

## Conclusion

AI Function Calling is undoubtedly impressive, but there are some obvious challenges with this approach. What if we wanted to incorporate all the different actions available in the Sitecore Personalize SDK? That would require defining even more functions, which would consume additional tokens to store this context. However, Function Calling offers even more possibilities. I'll be back soon to explore more topics related to this tool as I develop a highly effective LLM tool for Sitecore Personalize, and eventually for other products in the Sitecore Composable stack.

Revolutionizing Sitecore Personalize: Unleashing the Power of Generative AI Function Calling

Hello