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 with my annual update from Sitecore Symposium, this year hosted near my house in Orlando, FL. Last year, I recapped all my sessions, but after attending this year, I realized that strategy doesn't make sense anymore. I didn't get much value from the breakout sessions. The keynotes delivered the big announcements, but I gained the biggest insights through MVP Summit and 1:1 conversations with product teams and the community. So I'll break down the event using all that 1:1 knowledge instead of sharing every session I attended. Let's get started.

## The Big Announcement

Let's start with the biggest announcement from Sitecore Symposium 2025: the rebranding of Sitecore XM Cloud to SitecoreAI. I'll admit, I'm not sure I love the new name—it doesn't really describe it well, and it feels like they just want to stick AI in their branding. But that's not the real story. The big news, as Eric Stine described it, is that all the products will now be part of this new platform. Sitecore is building a unified DXP as a single cloud solution, bringing together CDP, Personalize, Content Hub, Search, and all the former XM Cloud products into one product. From a value proposition, this makes a ton of sense. It will really set Sitecore apart—especially from Optimizely. It'll take Optimizely years to catch up to this strategy, and customers will gain value quickly. While talking to the product team, I learned that Sitecore is positioned to enhance SitecoreAI fast, as they already have a huge roadmap of enhancements coming.

## Unpacking Sitecore AI

This is where things get interesting. It took me a little while to process this big announcement and what it means. I think Sitecore's vision here is A+, but the path to that vision will be more complicated than it appears on the surface. Keep in mind this is my opinion, and I've tried my best to verify my understanding—though some details might be off. So what should you expect? On Monday, November 10, 2025, the rollout begins. As I understand it, Monday brings a few new features and a fresh UI. Sitecore XM Cloud customers will now see SitecoreAI instead, with a completely new interface. However, the underlying architecture won't have changed—any functionality that existed before Monday will still be there, just in a different place in the navigation.

On the main stage, they said all the products will become Sitecore AI, but it's actually a rebuild—taking features from other products built with different infrastructure and re-imagining them. This means there could be issues with features that worked fine before. It's also unclear whether a new customer who wants decision models, for example, can buy Personalize + Sitecore AI until those reach feature parity. The other thing is that I'm not sure how long it'll realistically take to reach feature parity—or if that will ever happen.

One last concern is what happens Monday morning for XM Cloud customers when they log in and find a radically new UI. Minor tweaks or a temporary way to revert to the old UI would be fine, but this change could cause significant confusion on day one for many users. People will adapt—that's the nature of SaaS—but I wish Sitecore had taken more time to consider the rollout and its impact on users. They're also rolling it out to some partners, but possibly not all. Partners could have prepared content to help customers, but in my opinion, Sitecore did a poor job of enabling the community of experts before this rollout.

One of the main reasons they're building everything under one roof is to make it easier and faster to develop new capabilities for the platform. In the age of AI, context is everything—and Sitecore wants to build a Knowledge Graph from all that combined data. It's not just about content. It's about metrics collected from the combined abilities of Search and CDP, then using that data to enable more automation with AI Agents.

## AI

Sitecore wants to build AI capabilities into the product as a first-class citizen. They've integrated this throughout the application and built an Agentic AI platform consisting of Signals, Spaces, Flows, and Agents. You can build agents in the app using a workflow that reminds me of n8n—but a bit more deterministic. There's also the ability to bring in external AI Agents from third-party platforms, and they've already built several agents. I'll explore the AI Agentic tools in more detail after Monday, because this could really be a topic in its own right.

## Sitecore Studio

The new Sitecore Studio consists of Agentic Studio (which I discussed above), App Studio, Marketplace, and Sitecore Connect. The two main additions are Marketplace and Agentic Studio.

Marketplace is finally being released—over a year after its announcement. Sitecore is positioning it as a way to build custom SaaS, which has always been the vision. You can add Marketplace apps for Sitecore AI as well. I had many conversations about the new Marketplace. It's a great opportunity for partners to build unique offerings that set them apart. However, there were many discussions around data protection, privacy, and how Sitecore will ensure a safe and secure Marketplace. The old Marketplace on Sitecore had many poorly maintained products. As a partner, this might be less likely—but I've worked for partners where even their own products lose support over time. How the Marketplace is shaped may become more of an issue in the future. Either way, I'm eager to work on it.

There was also the Hackerspace. I didn't participate since I've already built an app, but I learned that they were vibe coding the Marketplace apps—using MCP servers for Blok and other tools to help build marketplace apps faster. Most were simple, but it allowed more people to start playing around with the marketplace.

## Content

I didn't attend the content-focused sessions at Symposium because I prefer focusing on the `Experience` side of the product. However, there were talks about the upcoming Content Service, which promises faster publishing times. There was also discussion about how Sitecore AI will eventually unify content services. For example, instead of having separate media libraries—one in the DAM from Content Hub and another in XM Cloud—there will eventually be a single storage location for media items.

## Experience

As mentioned above, Sitecore AI will now include both CDP and Personalize capabilities. The team plans to rebuild these apps within Sitecore AI. One major challenge will be migrating the data lake (warehouse) from AWS to Azure. In Sitecore AI, this is now called the Unified Data Layer. This change brings exciting possibilities—they're re-imagining and doing their first major overhaul of the Boxever Data Lake. This means fewer references to the airline industry and a more flexible data layer. I don't have many details on the specifics yet, but since this is my focus, expect more content to come.

## Search

Search is worth highlighting. During the main stage previews, they teased a common UI within Sitecore AI to manage indexed content. This would be a game changer for companies that need simple search for their websites. However, keep in mind these will be new search capabilities built directly with Azure within Sitecore AI. This could create challenges during the transition period—because some features will be available while others may take some time to appear back into the Sitecore AI platform.

## Pathway

Pathway was another highly discussed feature. It allows content migration initially from Sitecore to Sitecore, though they mentioned it would eventually support any CMS to Sitecore AI. Some previews appeared on the main stage, but after many discussions, I got the sense it's still a long way off. That said, anything that speeds up migrations—even slightly—is promising. However, it will be built for Sitecore 360 customers, which may limit access for other Sitecore users. Interestingly, I was considering building a tool for this before Symposium, but now that might not make sense. The feature is more sophisticated than I initially thought—Mo Cherif's team is building it with AI to help map schemas from one platform to another. I'll be curious to see whether this continues development or fades away. It seems like every year something loses momentum.

## Wrap Up

In conclusion, Symposium was excellent and reinforced what I believe is a strong vision—returning to a monolithic-like application that gives customers many capabilities in a single purchase. The challenge ahead is rebuilding all existing tools into Sitecore AI over the next year. They plan to launch new features rapidly over the coming months.

Starting Monday (11/10/2025), there will be many new launches that I'll explore and create content about shortly! They also announced next year's Symposium, returning to Orlando, FL on November 10–12.

As always, Symposium was a blast. It was a great opportunity to network and meet new faces on the Sitecore side, as well as connect with new MVPs and customers from the community.

Unlocking the Future: Key Insights and Major Announcements from Sitecore Symposium 2025

Hello folks! I'm back at it again, and today I want to discuss debugging custom conditions in Sitecore Personalize. I have a lot of content coming up about conditions and was recently working with a colleague at Velir when I realized this would make a great blog topic. I actually considered writing about this years ago while working at Sitecore. Back then, I had created content about transitioning from XP-based pattern/profile cards to Personalize and tried implementing it in a condition. Unfortunately, I encountered numerous challenges when creating that condition.

Before diving into debugging methods, let's discuss some common gotchas I've discovered. Many developers new to the platform don't realize that the JavaScript required for these conditions is quite unique. This uniqueness often causes problems when creating assets in Sitecore Personalize.

Fortunately, as I've previously discussed here: [First Look: Sitecore Personalize Code Assistant](https://dylanyoung.dev/insights/first-look-sitecore-personalize-code-assistant/), there's now an AI code assistant that can help when starting to write a new asset. I highly recommend that developers begin with this AI code assistant and then modify the code to meet their specific requirements.

When working with an LLM, I find it helpful to specify that it should write ES5 syntax JavaScript and use print(); instead of console.log. Now, let's explore some common issues:

- You can't import libraries in Personalize conditions, with a few exceptions such as date imports.
- Avoid modern JavaScript syntax like `const` or `let`—these don't work in any JavaScript written for the Personalize/CDP platform.
- Use `print('whatever');` instead of `console.log` for outputting data. This is the only supported method for debugging output, which I'll explain in more detail shortly.

## Debug Tip #1: Testing and Getting the Right Guest Context

When creating a Condition in Personalize, you can test the output of your condition and various input combinations during development. Navigate to your condition and click the `Test` option to display a floating panel. The first option lets you select a guest profile for testing. This feature is valuable because you can choose guests who should either match or not match your condition's criteria, allowing you to verify both positive and negative test cases.

![](https://cdn.sanity.io/images/lanua4su/production/59a19ed0518cf54be5ac35cd6b08c314d75aa8bd-1661x970.jpg)

You might also want to test your own guest context. To do this, go to the site that has the Cloud SDK configured and type in the browser console `scCloudSDK.core.getBrowserId()`. This is similar to the old Boxever method but updated for Cloud SDK. This returns your unique Browser ID, which differs from your guest ID. Alternatively, you can call `scCloudSDK.core.getGuestId()`, which makes an API request to retrieve your Guest ID. Either ID will work for testing with your own user profile.

After providing the Guest information for testing your condition, you can then input the condition parameters based on the parameters/inputs defined in your code. These two options are essential for testing. When you click `Test`, you'll receive a true/false value. While this testing capability is crucial for debugging, remember that a successful test doesn't guarantee your condition will work as expected in XM Cloud or an Experience, or even pass validation. You might also encounter unexpected outcomes without understanding why. Let's move on to the second tip which, when combined with this first tip, will establish a solid foundation for testing conditions.

## Debug Tip #2: Output Variables/Information

This second debugging tip is a fundamental technique for JavaScript developers: outputting variable values to verify your code is working correctly. For example, you might add a "hello world" message within a function to confirm it's being called, or check whether certain guest context information is accessible in Sitecore Personalize. The ability to output information during code execution is essential for effective debugging.

However, debugging conditions in Personalize requires a different approach than simply adding standard logging statements. Remember that `console.log` isn't supported—you must use the `print` function instead, as mentioned earlier.

You might also wonder how to run your code and where these print statements appear. As covered in tip #1, you need to test your condition against a guest profile with specific input parameters. This testing process is what enables you to see your debug output.

![](https://cdn.sanity.io/images/lanua4su/production/41c66a6b6e3e2a92e348ed6a63119cba22fb0cd8-2090x929.jpg)

As shown in the screenshot, the debug information appears in an unexpected location after running a `Test`. This is because the Personalize platform lacks a dedicated debugging tab in the Test UI. To view your `print` function output, open your browser's inspector, find the most recent `testTemplate` request, and check its response. There you'll discover all the debugging information from your `print` statements.

That's it for tip #2. I initially had a third tip, but it was more relevant when I first drafted this article and I couldn't reproduce the issue this time. Nevertheless, I recommend that once you've created your condition, you should test it in both a Web Experience and within XM Cloud to verify it executes correctly. In the past, there were instances where conditions would pass basic validation tests and could be saved (since the platform performs basic script validation during saving), but would still fail when implemented in XM Cloud. If I discover this issue still exists, I'll publish a follow-up article on the topic.

That's all, folks! I hope these tips will help you next time you're creating conditions in Sitecore Personalize. Happy debugging!

Personalization

Tips to Debugging Conditions in Sitecore Personalize

Hello friends! A few months ago, I took the Sitecore Personalize exam, and I wanted to share my personal insights to help those planning to take it themselves. In 2024, I completed the Sitecore CDP exam, which focused primarily on API integrations with the Engage SDK, Batch APIs, Audience Sync, and the Real Time API (Rest API, Interactive API) and Stream APIs. Even before taking the Personalize exam, I could tell it would concentrate more on UI elements, which makes perfect sense—the exam covers the Decision Model interface, creating experiences and experiments, and other Personalize-specific interface components.

Let's dive in! I'll cover the main sections and highlight important areas to know for the exam. The section I found most challenging was experimentation because it involves more nuances about what experiments to run and when to run them.

## Master the Study Guide

The first thing I recommend before any Sitecore exam is downloading the study guide. It's not really a guide but rather a list of documentation links highlighting exam-covered sections. My preferred approach—which I used for this exam—is creating a dedicated page in my favorite note-taking tool (Notion for me, though Confluence or OneNote work well too). I organize each topic with its corresponding documentation link and a checkbox beside it. Then I methodically work through each link, reading the content and documenting key points I might need to memorize.

Another effective strategy, which I didn't use for this certification, is following along with the documentation hands-on. When it demonstrates creating an experiment, log into Sitecore Personalize and complete each step as described. Your learning style matters here—I learn best by doing, but my years of experience with the tool meant I was already familiar with the interface.

## Take Advantage of Practice Exams

Every certification on Sitecore's learning portal offers a practice exam with 6 questions. While I can't confirm all practice questions appear on the actual exam, some definitely do. Memorizing these answers is worthwhile—it increases your chances of success. Since you're allowed to miss some questions, securing these guaranteed correct answers reduces uncertainty. Interestingly, during most exams I've taken, I felt convinced I would fail because several questions had unclear answers. If you encounter only a few of these 50/50 situations, odds are you'll get at least some of them right.

## Key Focus Areas

Now that we've covered some general best practices, I'll share my notes and insights on the key sections from the study guide.

## Competency 1: Real-time Behavioral Data Ingestion

If you took the Sitecore CDP exam, this section will be a rough overview of topics from that exam. The focus here is understanding how to use and implement the Sitecore Engage SDK. You should understand the different implementation scenarios, such as when to use the SDK versus the JavaScript library.

You should also know the nuances of how experimentation works with the SDK and what determines a session. I encountered a question about this in the practice exam that definitely appeared on the actual exam, so understanding what qualifies as a session in Sitecore CDP and Personalize is important for this portion.

## Competency 2: Experiences

This section digs into the UI of Sitecore Personalize. Creating an Experience is one of the main features of Personalize. You should know the differences between the following:

- Full Stack Interactive Experience (and when it should be used)
- Web Experience
- Triggered Experience

Another important area is knowing which out-of-the-box web experiences are provided and which aren't. I wrote these down in my notes, and found this knowledge helpful during the exam.

| **Template Type**    | **Disruption Level** |
| -------------------- | -------------------- |
| Alert bar            | Very Low (1)         |
| Corner pop-up        | High (4)             |
| Email capture bar    | Very Low (1)         |
| Email capture corner | High (4)             |
| Inactive tab         | Low (2)              |
| Notifications widget | Medium (3)           |
| Pop-up takeover      | Very High (5)        |
| Side bar             | High (4)             |
| Tooltip              | Medium (3)           |

Another helpful area to understand is the Cloud Portal permissions, though this isn't specific to experiences. Ironically, I recall a similar question in the XM Cloud exam. Understanding the differences between User, Developer, and Admin roles will prove useful.

Understanding conditions is another covered topic. You should know how to edit them, their limitations, and how to work with them effectively.

You should also understand the complete process of creating a web experience. My advice: log into Sitecore and practice the steps to make them easier to remember. Familiarize yourself with the reporting capabilities and how to debug your experiences. There are also performance recommendations for both experiences/experiments and decision models (covered in a later competency). Knowing these best practices will not only help you pass the exam but also be valuable when using the product.

If you've never used Personalize, you'll want hands-on practice with this section. However, compared to the next section with its additional rules and nuances, this section is relatively straightforward.

## Competency 3: Experiments

As I alluded to in the last section, experiments share many similarities with experiences. In fact, in the old Boxever platform and early versions of Personalize, they were set up exactly the same way within the product. However, there is significantly more nuance to creating an experiment compared to an experience.

You should understand the differences between a Web Experiment, an Interactive Web Experiment, and a Triggered Web Experiment. You'll also need to know about the `Classic` engine versus the `Optimized Statistical` engine. The simplest way to think about this (though I recommend reading the official definitions yourself) is that the Optimized engine leverages AI and automation. It can reduce the time needed to determine a winner in an A/B/n scenario because it dynamically adjusts traffic allocation—if a third variant starts performing better over time, more traffic will be directed to it to help reach statistical significance faster.

Understanding the reporting capabilities is vital for the exam. Operational data typically appears within 24 hours, allowing you to see how each variant performs against the others. You should also familiarize yourself with all steps involved in creating an experiment and know when to use various options.

A critical aspect is understanding the types of goals available and what constitutes a successful experiment. Consider what elements make up a good experiment design. I recommend opening the UI and experimenting with different confidence levels to understand how they affect results and experiment duration.

The exam also covers the two assignment methods: `Unique` vs `Universal`. This relates to how visitor traffic is identified and assigned during testing.

## Competency 4: Decisioning

Decisioning, or what's called a `Decision Model` within Sitecore Personalize, is a crucial topic because it powers the 1:1 personalization capabilities of this product. Understanding the Decision Model requires familiarity with several concepts and terminology. I strongly recommend trying it hands-on. You should learn how to create one, how it's assigned to experiences or experiments, and understand that a single decision model can be used for multiple experiences or experiments (a 1:many relationship). You should also become comfortable with decision model variants (which enable workflow management) and understand the various states a variant can have.

You should also understand the canvas, including what elements can and cannot be added to it. This is an area where you should familiarize yourself with performance best practices for decision models. For example, limit the number of nodes when creating a decision model variant. Understanding the ideal layout is also important—top to bottom is considered best practice. While placement may not affect performance, a standardized interface ensures anyone can quickly understand the data flow.

Familiarize yourself with testing decision template flows on your canvas and using the `print()` function to troubleshoot and diagnose issues. This debugging technique is essential for ensuring your decision models work correctly.

Finally, you should understand the Decision Table, a more complex node type that can be added to the Decision Model canvas. It's important to familiarize yourself with the various hit rules you can configure within the decision table.

I recommend spending time exploring the tool hands-on to become familiar with its components. Dedicate a week or two to thoroughly understand all elements of the decision model. Early in my experience, I participated in a proof of concept using the decision model, which proved essential for comprehending all aspects of this product feature.

## Conclusion

In conclusion, if you've had hands-on experience with Sitecore Personalize, you're already well-positioned to succeed—you'll just need to brush up on the terminology. If you're new to the platform, I recommend spending a few weeks exploring and experimenting with its various features to build familiarity. Good luck with your exam! I'd love to hear if this blog post helped you—connect with me on LinkedIn and let me know if you passed!

Taking the Sitecore Personalize Certification: My Advice

Welcome back, friends! It's been a busy few months working on various side projects, and things have been hectic at work (several blogs on those topics are coming soon). Keeping up with the latest trends has almost become an obsession for me.

Today I'm kicking off a series of blog posts about recent developments. This post focuses on the Model Context Protocol (MCP) and my predictions about its future direction. The current trend seems to be setting these `servers` up locally, which I believe is a flawed approach. In most cases, these servers simply expose details of an API that is already remotely hosted.

Local MCP servers make sense only when working with local systems, such as a file system. They're also useful if you're customizing an API or addressing a very specific use case. However, MCP server creators often configure them with a direct 1-to-1 mapping to the underlying API, which isn't always optimal. There are typically more performant ways to enhance your MCP server for specific purposes.

However, I believe the most common scenario is to host your MCP server remotely when you already have an API. Similar to an API, you would implement various authentication methods so the MCP server returns user-specific data. This remote approach embraces the SaaS/Cloud model we've grown accustomed to with web applications, offering clear benefits such as easier maintenance and the ability to quickly update the MCP server as needed.

In today's blog post, I'll show how I implemented this remote option for my MCP Server for Sitecore Personalize using Cloudflare Workers. I must admit I was relatively new to Cloudflare Workers when I started this project, which led to some challenges that experienced users would have avoided. I'm also introducing my Sitecore Personalize MCP server and will walk through the currently available tools. While it's simple at the moment, there's more to come—all made possible by my previous work with the Sitecore Personalize SDK. Let's jump in.

## Introducing Copilot

This isn't actually an introduction, but rather a re-introduction for those who missed my previous blog post: [AI Friday: Building a Hosted MCP Client and Consuming a Remote MCP Server](https://dylanyoung.dev/insights/ai-friday-building-hosted-mcp-client-consuming-remote-mcp-server/). You can visit [https://copilot.dylanyoung.dev](https://copilot.dylanyoung.dev/) to access my copilot application and review my last post to learn how to use it. In this week's blog, I'll be using this copilot tool, which is already connected to the Sitecore Personalize remote MCP Server that I'll be covering today.

In my prior blog post, I discussed how to add a Remote MCP Server. At that time, the only functional remote MCP server in the app was Fetch. Since then, I've added the Personalize MCP Server, which you can now use. For this blog post, we'll add that server and explore some use cases.

To add it, navigate to the MCP configuration page: [https://copilot.dylanyoung.dev/settings/mcp](https://copilot.dylanyoung.dev/settings/mcp). If you haven't already, click on `Add MCP Server` in the top right and select `Preconfigured`. You'll see several options, including the new Unofficial Sitecore Personalize MCP Server. If you don't see it immediately, it's also listed under the `Marketing` category. Click that option to configure it.

I'll assume you've already configured your Sitecore Personalize instance. If not, navigate to the Sitecore Instances section and configure Sitecore Personalize using API Keys or Developer Generated Tokens as I've shown in previous blog posts. You'll also need to configure an LLM—either Anthropic or Open AI will work—by navigating to the `API Tokens` section. I recommend exporting this configuration for easy restoration in the future.

You should now be all set and able to access the chat window at [https://copilot.dylanyoung.dev/copilot](https://copilot.dylanyoung.dev/copilot).

## Cloudflare Remote MCP Server for Sitecore Personalize

You might be wondering why I hadn't built an MCP Server for Sitecore Personalize until now. Well, I've finally created one—and it's hosted, allowing anyone to consume it easily using either SSE or Http Streamable. The code for this hosted solution is open source and available here: [dylanyoung-dev/sitecore-personalize-mcp-remote](https://github.com/dylanyoung-dev/sitecore-personalize-mcp-remote). Being hosted makes it function more like a server implementation than a typical MCP server. At its core, this MCP server consists of basic tool definitions, made possible by my previous work on the Sitecore Personalize Tenant SDKs. The repository enables users to pass headers containing their client Id, client Secret, and region—all parameters the SDK needs to initialize. After initialization, I define tools (listed below with brief descriptions) and provide functions that help the LLM understand which functions to call and what parameters they need. These parameters are passed to the SDK, which then returns the necessary data for whichever function or tool you're using. This approach is similar to what I discussed in my 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/). Function calling and MCP are quite similar—a function call is like a concrete implementation in your code, while an MCP server acts more as an interface, allowing you to potentially swap in different types of MCP servers for various use cases, without needing to implement each and every one yourself.

Here are the tools currently available in the MCP server (which I can update remotely without requiring any upgrade steps from users):

- Echo
- list_personalization_experiences
- create_personalize_experience

We'll be talking more about creating an experience today, but there is also the echo tool, which I set up just for testing the MCP server. You can ignore this tool, but you can use the list_personalization_experiences function to return a list of experiences you've created in your Sitecore Personalize tenant. There are many options available, and I plan to add many more. This was just a simple proof of concept, and I actually encountered several challenges getting this remote MCP server to work with headers. Now, let's go ahead and run a test chat.

You can also access the remote MCP server directly by going here: https://sitecore-personalize-mcp-server.dylany.workers.dev/

## Using the Copilot Tool

Now that we've covered the MCP server and how to configure the copilot tool to use the Personalize MCP server, let's walk through a specific step-by-step use case: creating a new experience in your Personalize tenant.

Once you've configured your MCP server and the instance of Personalize, as well as configured at least one token for either Anthropic or Open AI, navigate to the chat interface here: [https://copilot.dylanyoung.dev/copilot](https://copilot.dylanyoung.dev/copilot). If you've configured everything properly, you should see a chat window where you can begin your interaction.

Start by asking which tools are currently available. You'll receive a list similar to what I mentioned above, along with the parameters expected for each tool.

Since we're creating an experience today, try a prompt like: `I want to create a new Web Experience that should consist of a popup when a user first visits my website`. The system will respond with the parameters it needs.

For the assets, we'll leverage the LLM to create them for us. Follow up with: `Lets call our experience "test" and it's for the Web Channel, can you create the assets needed for our popup, display a simple text message, with a way to close the popup, and some sort of button CTA`.

Just like that, it will return suggested HTML, CSS, and JavaScript for your experience and ask you to confirm the creation. I'll confirm, but in a real scenario, you might want to provide additional feedback to refine the experience exactly to your needs.

To proceed, simply say `yes, lets proceed` and after a few moments, you can visit your Sitecore Personalize tenant where you'll find your newly created Experience. Pretty cool!

## Wrap Up

Well that’s if for this blog post, I do plan to continue this adventure, with more blogs on the copilot tool as well as I have plans to create new remote MCP servers that once you start to combine more than one tool from multiple MCP servers, you can start to create some pretty cool things.

Building a Sitecore Personalize Copilot with Streamable MCP Servers on Cloudflare Workers

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.

Hello

Latest posts

Unlocking the Future: Key Insights and Major Announcements from Sitecore Symposium 2025

Tips to Debugging Conditions in Sitecore Personalize

Taking the Sitecore Personalize Certification: My Advice

Building a Sitecore Personalize Copilot with Streamable MCP Servers on Cloudflare Workers

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

First Look: Sitecore Personalize Code Assistant