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.

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

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.


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

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 friends, it's been a while since I created an AI topic. Today, based on a conversation with Rodrigo Peplau, I decided to write this blog post. Prompt engineering and how to use Generative AI to create useful outputs is a powerful topic. Many newcomers to AI don't realize all the amazing things it can do. Rodrigo and I are working on some auto-personalization functionality using Generative AI (sorry Rodrigo if you didn't want me to share that 😛). In our case, I wanted to take some information about a website built with Sitecore and use Generative AI to generate persona and profile key information for the site automatically. I mentioned that I had done this for my SUGCON EU presentation on behavioral personalization but had lost the prompts. So, this is an exercise in recreating that outcome. I believe I used Microsoft Copilot and provided information about the SUGCON North America website, asking it to create personas for this type of site and output them in a table. In today's use case, I wanted the output in JSON format so that the data could be used for other purposes.

## Initial Prompts

My initial attempts to create the Persona and Profile Keys (or Attributes) shared across Personas began with a straightforward description of the site. These attempts resulted in multiple prompts to achieve the desired JSON output, which looked something like this:

```json
[
    {
        "name": "Some Persona",
        "description": "Information about the persona",
        "attributes": [
            {
                "name": "Tech Enthusiast",
                "score": "10"
            }
        ]
    }
]
```

This JSON output would allow us to then take additional action with the output generated by Generative AI.  The additional prompts were helpful to use in our code to combine those additional instructions into a single request to help generate the outcome that we were expecting.  Some of the following were the issues that I had with the initial prompt, that I had to follow up with additional prompts:

- The attributes were inconsistent across personas, whereas in Sitecore, profile keys must be uniform for a Profile and Pattern Card.
- Give it more context about the schema of the attributes.
- It didn't know how to provide the `score`, resulting in vague scores like `High` or `Low`. I clarified that the scores needed to be numerical, specifically within a range of 1 to 100, which resolved the issue.

After these additional prompts, I finally got the desired output. However, I now wanted a way to run this from the code. Let's discuss some strategies I used to incorporate those additional instructions and context into a single request to guide the model effectively. Note that the approach might differ slightly when using the Chat Completions API.

## Instruct the Model to Pretend to be a Specific Role

I've seen this used elsewhere on the web, where you have a specific purpose. In our case, I was trying to get Generative AI to assume it was a Strategist or Data Science role, to have it profile the content and come up with a general set of Profile Keys/Attributes and then use those attributes as a way to score the personas of a web page. So adding an instruction such as:
`You are a website marketing strategist and you need to create profile pages on a website`...

This is considered “Role Prompting” ([🟢 Assigning Roles (learnprompting.org)](https://learnprompting.org/docs/basics/roles)) which improves the accuracy of the output from our request. In our case, because Generative AI is assuming it’s a strategist, it’s going to analyze and profile the content that we provided it.

Now, for a lot of the prompting, I was simply using Microsoft Copilot, which doesn’t really allow you to set system prompts, which is where a lot of these instructions that I talk about in this post, should really go. So that when I describe the site or the pages of the site, it uses the system context to automatically send the expected outcome back to the user.

## Provide an Example

In my specific use case, I did not provide an example, but it’s an important element that can greatly improve the accuracy of the LLM in returning the desired output. When I used Microsoft Copilot, even with specific instructions to not use unique attributes per persona, it often made errors. I found that the Microsoft model wasn’t advanced enough to handle this scenario, so I switched to a more sophisticated model for better results. Providing an example of the desired output would likely have generated the correct response. Including a JSON schema in my final prompt yielded better results, and if I had provided more scenarios to generate a common set of profile keys, it might have resolved the issue.

Since I'm not providing examples, this approach qualifies as zero-shot prompting ([Zero-Shot Prompting | Prompt Engineering Guide (promptingguide.ai)](https://www.promptingguide.ai/techniques/zeroshot)). While no examples are given to guide the AI, the additional context I provide should help achieve a more accurate response.

## Final Outcome

Let's review what my final prompt looks like. You will notice that many of the elements discussed above are included in this initial prompt:

```text
1. You are a content marketer/strategist working for a website that is about events in the Sitecore community
2. Your response should be in only JSON in the following format [{ name: string; description: string; attributes: Record<string, number>; }]
3. The attributes will have a string for the name of the attribute and a number between 1 and 100 to score that persona.
4. The attributes that you define, should repeat for each persona, so how you score the attribute the persona will differentiate those personas from each other.
5. The site has various pages about the event such as the agenda, sponsorship information, and the speakers as well as ways to Signup.
```

As you can see, I used a numbered list of instructions to outline the key points, including an example of the desired JSON output and guidelines on what was acceptable. I also assigned the role of `content marketer/strategist` to refine the results further. While this prompt could be enhanced by providing an actual example, I was already getting the expected output.

I will cover more details about this code and its usage in a future blog post. I will also explain how to build upon these prompts to generate JSON, which can be used with function calls to interact with an external API. Stay tuned for that topic 🙂.

## Extra Credit

Many forget that AI output may not always meet expectations. Human oversight is essential to verify and refine the information suggested by AI. It's crucial in any AI application to have a human validate the output. While this feature isn't built yet, the next step could involve allowing users to select specific generated personas and create them, rather than discarding others. Another option is to enable users to regenerate or refine certain personas with additional context. This process supports user creativity, leading to impressive outcomes.

AI Friday: Prompt Engineering Basics

Hello friends, welcome back to my blog, and happy Friday.  Today I want to continue our journey into Generative AI Chat Copilot development.  I had planned to write a different article today, but I think this topic is more appropriate, to give an overview of the different building blocks in developing a Chat Copilot.  It’s possible that some of this information applies past a simple Chat/Copilot example, but since that’s all I’ve really been researching, I wanted to make that the focus and I’ll explore other use cases where Generative AI can be useful (and how to develop those use cases) in the future.  If you missed my first blog post on this topic: [https://dylanyoung.dev/insights/create-a-local-chat-assistant-with-openai-and-microsoft-chat-copilot/](https://dylanyoung.dev/insights/create-a-local-chat-assistant-with-openai-and-microsoft-chat-copilot/), make sure you check that out, since I covered installing the Microsoft Chat Copilot open source repository on your local machine (which is great if you want to build a chat copilot for your own purposes).

This blog post, however, will focus on the different pieces that were represented in Microsoft’s Chat Copilot example, or some other common elements when you are building a chat copilot.  I’m going to call out below, where Microsoft’s offerings fit in and then describe some of the more mainstream options that are available.  In a future blog post, I’ll look through each specific piece and do a deep dive comparison of the options.

Before we explore the different pieces of a Chat Copilot Generative AI application, I wanted to briefly describe the flow that is required.  I found the following very helpful in describing custom development with a Chat interface:

![Source: https://www.antoinebernard.com/diy-support-chatbots-creating-your-first-ai-assistant-on-your-own-documentation/](https://cdn.sanity.io/images/lanua4su/production/11bed825d852a7c4511ce2ea7d35877c4d97c3f6-921x492.png)

Let's take a few moments to break down the diagram above and delve a little deeper into each of its parts. We'll also discuss some of the options you may have when building these components of the application.

## Large Language Models (LLM)

As previously mentioned, the LLM is the most important part of any Generative AI application. While it is possible to use these LLMs directly with ChatGPT ([https://chat.openai.com/](https://chat.openai.com/)), it may not always be the most useful option. Additionally, there are many LLMs available beyond just OpenAI's models, such as LLaMa (Meta) and BERD (Google), each with different use cases. Some are more specific to chat interfaces, while others are more code or multimedia specific.

If you are new to this field, it's worth taking a look at [https://huggingface.co/](https://huggingface.co/), which is a website that lists the different models and allows for filtering based on criteria such as licensing and model types. Having a solid list of available models is a great place to start, and it's important to note that you may use multiple models in your specific application to build better and more rounded applications.

It's important to note that in many cases, using multiple LLMs simultaneously can be helpful in improving your application's ability to return relevant information.

For those who read my first article on setting up the Microsoft Chat Copilot, that open-source project allows you to use either Azure Open AI’s LLMs or Open AIs LLMs.  It is also probably possible that you could connect to other similar LLMs as well, just some modifications may be required to connect/authenticate to those different systems.

## Embeddings

An Embedding is a machine-readable representation of text that is converted into a multi-dimensional array of float numbers. These numbers represent a vector, and similar phrases or words will have very similar vectors. By collecting and storing these vectors, an application can match up similar phrases that are searched for in the future by users.

## Vector Database/Store or Search

The Embeddings or Vectors are saved in a database, typically a database specialized in storing vectors, like a Vector Store/Database such as Azure Cognitive Search, Chroma, or Pine Cone (there are many more to choose from, but we’ll start with some of the most popular ones here). Think of a Vector database and the creation of Embeddings as creating a long-term memory store for our application, which helps it to perform better over time.

To make the most of storing large amounts of vectors and get faster results, you'll need a Vector store designed specifically for that purpose. One important aspect of such a store is effective indexing of the data. When you map a user prompt to a vector and calculate the closest distance for vectors in the database, the multi-dimensional requests can take a lot of time. While you could store vectors anywhere, even in a notepad file, a Vector store designed for storing vectors will provide many benefits.

Another popular topic that frequently arises when discussing Vector Searching (such as using Azure Cognitive Search, which can act as both a Vector database and a Search index) is the ability to perform Hybrid Searches. Hybrid search in the context of Generative AI involves using both traditional word searching and vector searching to improve the relevance of search results for a given query. This approach combines the strengths of both technologies to provide more accurate and useful results. For example, a hybrid search for a chat copilot application could involve using vector searching to match similar phrases or words and then refining the results using traditional word-searching techniques.

## Large Language Model SDK/Orchestrators

Honestly, there doesn’t seem to be an official name to describe these from my research.  Often times I’ve seen these lumped into the LLM category, however, that just doesn’t make sense.  These tools do not act like an LLM and instead work in the middle of everything in the Chat Copilot application.  When a prompt in your chat interface comes in, your request is handled first by the LLM SDK/Orchestrator, which can then add additional context to that request.  An example, is that maybe you want to have the LLM respond in a different language or just a different tense, this is just one example of what the Orchestrator can handle for the application.  Another use case is combining the initial prompt with additional context about the user, such as previous prompts they entered, or using some of the embedding data to help the LLM respond with more focused content.  I will cover this topic further in upcoming blogs and walk through specific use cases.

In our previous blog, where we set up the open-source Microsoft Chat Copilot ([https://github.com/microsoft/chat-copilot](https://github.com/microsoft/chat-copilot)), its orchestrator was handled by Microsoft’s specific option called `Semantic Kernel`.  This SDK can be extended with .Net which is one of the main reasons you would choose to use Semantic Kernel over other potential options if you are a .Net shop.  Some drawbacks however might be that you need to host additional services to handle this orchestration layer, as well as it’s not as popular or has quite as many features as the next option I’m going to describe in the next paragraph.

Another more popular option is to use an SDK called LangChain (mentioned above in our diagram).  This SDK is built to handle more use cases (detailed below) and even works with Typescript/Node, making it a better option in many cases, because it can be used alongside a more modern Next.js application ([https://vercel.com/templates/next.js/langchain-starter](https://vercel.com/templates/next.js/langchain-starter)).  I will admit the Vercel starter kit doesn’t look quite as nice as the Microsoft Chat Copilot, but there are many more options and it’s super easy to spin that up in Vercel to begin testing out these different use cases.

![Source: https://datasciencedojo.com/blog/understanding-langchain/](https://cdn.sanity.io/images/lanua4su/production/dee3ac8dcd5439577459b39534d48fd3f9a6eebc-891x708.webp)

I’ll go into more detail about the different modules that are available with LangChain and use cases where they can be useful in a future blog post.  For some of the Proof of Concepts I’m working on, I’m likely going to use LangChain because it’s feature-rich and easy to use.

## Chat Interface

Finally, it’s briefly mentioned above, but you’ll need a chat interface, this can be pretty simple, so I won’t call it out specifically below.  In our Microsoft Chat Copilot example in my previous post, this was simply a frontend React application running as a SPA, but you could build this with Angular, React/Next.js, .Net, Blazor, etc.  It really doesn’t matter, just the application will connect typically via API to your Orchestrator/LLM SDK.  So with that described let’s now take a closer look at each of the pieces more closely.

Getting Started with Chat Copilot Generative AI Development

Hello Friends, welcome back to my blog.  Today I’m spending some time playing with Open AI, which is a fun and popular topic.  What I want to achieve, is the ability to create a chat interface locally (for local development or to start building a plugin for future use cases).  What I’m going to use is this repository: [https://github.com/microsoft/chat-copilot](https://github.com/microsoft/chat-copilot), which is a free open-source tool that you can get up and running with on your local machine.  Up to this point, my only experiences with Chat GPT and Open AI have come in the form of using [https://chat.openai.com](https://chat.openai.com/) which is nice, but what if I wanted to start building a plugin and extending this further?  Now the GitHub repository that I’m going to walk through, allows you to use either OpenAI or Azure OpenAI.  Until a few days ago, I was still a little unclear what that difference meant, and because of that difference, it’s important to address some things before we get too far into this blog post.


## So what is the difference?

Really it’s quite straightforward (and no they aren’t the same thing), Open AI is just a public Large Language Model (LLM) that’s being trained all the time by various inputs from the public ecosystem, while Azure Open AI, is just taking all those LLM’s that you know and love and moving them and adding security around them.  I would assume they are still learning from the public, but when you use Azure’s version of Open AI, any data that you supply to it, will stay within the confines of your Azure ecosystem.  Also, you can use other Azure Cognitive Services, which allows you to use more rich information potentially from your users or the data they provide to power this LLM.  And you don’t need to worry about that data escaping into the general population.  That is why, today I will be setting everything up to use Open AI only, not Azure Open AI, and it’ll be important whatever I plan to build, must be public information. (no sharing customer or trade secrets to the public LLM)


## What is a LLM

Well as I’ve already written out the acronym, it stands for Large Language Model, but what does that really mean

A Large Language Model is a type of artificial intelligence that specializes in language processing. These models are trained on vast amounts of text data and are able to generate human-like text outputs, such as in a chat interface. The technology behind LLMs has advanced rapidly in recent years, leading to many exciting new applications in natural language processing and conversational AI.  (Did you know that Chat GPT just wrote that paragraph 🙂)

In today’s article, we aren’t really going to dig too deep into the nuances of Chat GPT 3.5 turbo vs. 4, but we will be using mostly Chat GPT 3.5 turbo in our local development environments, because relatively cheaper to run since it’s not trained on vast amount of parameters like Chat GPT 4.  Keep in mind that the more you train a model, the more likely it will be able to provide valuable insights vs. random gibberish.  Although I will say, even 3.5 does an excellent job responding to your input, just keep in mind that version 4 is even better.


## Getting Started: Repository Setup

Before we can get too deep into this setup, there are a few things we must do first.  First, you should go on over to GitHub to the repository that we’ll be setting up today: [https://github.com/microsoft/chat-copilot](https://github.com/microsoft/chat-copilot).  Likely we will need to make modifications to this repository, so instead of just cloning this repository, I went ahead and forked it over to my own account instead: [https://github.com/dylanyoung-dev/chat-copilot-play](https://github.com/dylanyoung-dev/chat-copilot-play).  This is where we will begin.  At this point, let’s go ahead and clone this repository locally.  


## Getting Started: Open AI - API Access

Now that we have our repository locally, we need to get the API key access information for the Open AI service we’ll be using.  Since I don’t currently have access to Azure Open AI, plus honestly for these simple use cases, I don’t have a need for it, I’ll be configuring a key in Open AI directly (and will walk through the steps).  But if you want to start with Azure Open AI, the steps are pretty much the same, and you can use those Azure-based LLMs instead, just follow the steps in the Readme for further information ([https://github.com/dylanyoung-dev/chat-copilot-play#instructions](https://github.com/dylanyoung-dev/chat-copilot-play#instructions)).

To get our API key that we’ll need to connect to our local Chat Copilot, we’ll need to head over to [https://platform.openai.com/overview](https://platform.openai.com/overview) and make sure you already have an account and are logged in to this account.  Once you are logged in, on the top right, you’ll see a picture of yourself (if you configured this) and something that says “Personal”, it’s possible it could say something else if you’ve configured your account differently than the personal account that I have configured.  Either way, click on that and it’ll show a new navigation dropdown, and click on “View API Keys”.  This is where we will go to create our API key.  It’s quite easy to create our API key, just click on “Create new secret key” and then give that key a name, for this blog post, I am going to give my key the name “Microsoft Chat Copilot”, and then click “Create secret key” and then copy your created key, keeping in mind this is the only time you’ll see the key, but you can always go in and delete keys and then recreate them if you lose track of your API key.


## Setup our Chat Copilot

Alright now it’s time to setup the repository that we cloned in the previous step.  You can follow along with my instructions here, or you can read more in the Read me here: [https://github.com/microsoft/chat-copilot#instructions](https://github.com/microsoft/chat-copilot#instructions).  For this blog, I am on a Windows machine so I am going to go through those steps on the readme.  The steps will help you configure this React (for the frontend) and .Net for the Server side application, at some point in the future, I’ll cover how to do these steps with a Next.js or Node-based application, since that makes more sense to me than using .Net.

Let’s open a favorite terminal, make sure you are in “Administrator” mode, and then make sure you are also in the root of your repository.  Once you are there, you’ll need to make sure you install the prerequisites and configure your environment, so you’ll need to change the directory to the scripts folder, which you can do with a simple `cd .\scripts\` in your favorite terminal.  Once you are there now, run the following command:

```powershell
> .\Install.ps1
```

What this will do, is use Chocolatey (if you don’t have it already, it’ll also install this for you) to install dotnet-7.0-sdk which is needed for the Server side interactions, nodejs (for the frontend) and yarn.  Honestly, I’m not sure why it installs yarn, since a lot of users use NPM instead.  Be aware that this step took a couple of minutes to complete, so walk away and grab something to drink while you wait.

Now with everything installed, you can configure the application.  In this step, you’ll need your API key from Open AI that we got in a previous step.  If you are configuring the Copilot with Open AI like I am, you would be running the script like this:

```powershell
> .\Configure.ps1 -AIService 'OpenAI' -APIKey '<Your Key Here>'
```

This will configure SSL as well as configure a .env file here: `webapp\.env` 

Once everything goes smoothly (hopefully), then it’s time to start our two services (the React frontend and the API Layer using .Net).  To start those services, we now (assuming you haven’t had any issues up to this point) need to run the following command:

```powershell
> .\Start.ps1
```

Now hopefully it magically starts for you, however, it didn’t for me, and I think a lot of that had to do with Yarn being used.  The API started just fine, but since I had problems with the Frontend I did end up making some changes.  Luckily you don’t need to stop the running API layer, and can make changes to the front-end and then simply run `.\Scripts\Start-Frontend.ps1` or you can even start a new terminal window (as an Administrator), and navigate to the web app route here: `.\webapp\` and simply run `npm run start` since the React application is using CRA (Create React App).  This setup definitely leaves a lot to be desired so I might make some changes and release a new blog on how to configure that new setup.

I chose to set up a new terminal and run `npm run start` and then I found there were a lot of dependency issues that I needed to work through.  So I just wanted to detail those below, to hopefully help others with those issues.  First off, Chocolatey attempted to install the latest Node version (20 or the latest version), but I use Node Version Manager on my machine to manage multiple Node/NPM versions across different projects I work on, and the method of installation with Chocolatey didn’t exactly work well with that setup, so I needed to ensure I have NVM configured to use the latest version by just running the following commands in my terminal/powershell:

```powershell
> nvm install "20.3.1"
> nvm use 20.3.1

# And to confirm
> node -v
v20.3.1
> npm -v
v9.6.7
```

Once you are done, you can navigate to your `.\webapp\` folder and run `npm install or npm i` and see where that gets you. For me, I was having dependency issues, which I don’t think were related to the node/npm versions I had running.  So I ended up just running a `npm i --legacy-peer-deps` to get it to install correctly.  Though honestly, that doesn’t seem to be a good way to handle it, but some of their dependencies didn’t work with React 18.2.  

Once you are done, you should now be able to run `npm run start` to start your React front end. You should now see in your browser at [`http://localhost:3000/`](http://localhost:3000/) the running React application.  Should look something like the view below:

![](https://cdn.sanity.io/images/lanua4su/production/bf957bb24239d49274e8115d3c472d1d81352afd-1017x590.jpg)

We are now all set to start building a plugin or enhancing this application to add new capabilities or enhance the UI.  I think one of my next tasks is to update this to use Chakra UI with React and use the Sitecore Blok design system.

But before we end today’s topic…..


## Why Setup a Chat Copilot Locally

So we’ve done all this work and we now have a chat client locally, but what’s the next step from here?  Well the purpose behind getting this setup, is so that we can start to create a custom Plugin for Open AI.  This could be a copilot that you plan to release as a separate app on the web with a built-in plugin or this could be a local development environment to build your plugin to then release to the Open AI marketplace.  We’ll continue this series on Open AI Chat Copilots in the future, so be on the lookout for my next blog on this topic.

Generative AI

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

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

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

AI Friday: Prompt Engineering Basics

Getting Started with Chat Copilot Generative AI Development

Create a Local Chat Assistant with Open AI and Microsoft Chat Copilot