Hello. My name is Jason Hein, And I'm the Global Director for Product, Content, and Search at the B2B Ecommerce Association. And it's a privilege to be here today as part of Coveo's Relevance 360 Workshop Masterclass to discuss getting ready for the agents. How to get ready to move from data to action. Now if you had asked me twenty five years ago when I got started in this business what kind of presentations I would be giving, I guarantee you it would have been around something like "How to pick the right two part epoxy for a marine application" or "matching the appropriate rake angle to a cutting material in turning." It wouldn't have been to prepare your digital business for the coming robot invasion. But, nevertheless, here we are. When you think about all of the AI agents that your internal teams are building, now take a moment and think about all of the AI agents that your customers, your partners, your suppliers are building because they wanna interact with you. This is the reason why developing an agent directory is so important. And we're gonna talk today a little bit about MCP. Which is one of those formats for an agent directory. MCPs are great because they represent a controlled way to manage the way in which all of these partner agents interact with company and with your business. Let's take a little bit to talk about tools. So you'll hear people talk about MCP servers. So these are the platforms that store the information that these third party agents want to interact with. They store your pricing, they store your product data, they store your customer information. Not every platform that is out there has native built in MCP integration capabilities. Coveo is one of them, but not every platform does. So, some platforms have it as a native feature, but sometimes you might need to explore options like middleware or iPasS systems in order to do that. But regardless, the server is where lives natively. The next part of the lingo here is understanding MCP tools. The tools are the things that you give these third party agents in order for them to do what they've been tasked with doing on your website. They really represent the activities, the tasks that they've been assigned to do pulling data from the MCP servers. And lastly is the MCP directory and this is what we're gonna talk about today, the rule book that defines how agents can access MCP servers and accomplish tasks using these MCP tools. You can think of this like the MCP server is a collection of restaurants. The MCP tools are the menu items available at those restaurants. And the MCP directory is kind of like one of those dining apps like an Uber Eats or a DoorDash, where I can go to one place and identify and find any different type of food that I want and get matched with where I can get it from. To make an MCP directory work, you need to have two fundamental components. You need to have a product data model. Which defines, basically "what exists?" Of all of the products that we have available in our commerce experience, the product data model defines what those categories are as well as what defines each product within that category. An action model then represents "what can be done" by agents on your site. So let's dig a little bit into each of these. First of all, the product data model, the definition of what exists. A Product Data Model has three fundamental components. The first and the most important is the Category Taxonomy. It's the navigation system for your website. Your Category Taxonomy is incredibly important, not only for agent success on your site, but also for human users. It exists as, in some cases that list of categories that you drill into in your left hand navigation on your website, it might exist within a PIM or an MDM system as a hierarchy of increasingly specific levels of that describe the products you sell. There are a few best practices around designing a Category Taxonomy that we'll talk about here. First is the concept of MECE. Meaning, It's Mutually Exclusive and Collectively Exhaustive. Fundamentally, what MECE represents is that every product has one place in your taxonomy where it can get classified. And two, everything that you sell has a place in your taxonomy. It's the good old, a place for everything and everything in its place. If you don't have a taxonomy that is mutually exclusive, then what can happen is there might be two different parts of your experience where a human user or an agent could go to find that product. Since an agent is probably going to stop looking once it finds one place. By spreading selection within a category between one or more similar categories, you risk the full extent of your selection not being exposed to that agent or that human user. The next element, "collectively exhaustive", means if you don't have a category for a product that you sell, it can be very hard for the agents to find it because it's not gonna be classified to where it thinks it will be. Another concept is the number of levels within a taxonomy. Most taxonomies start off with very very high level categories at the top and very very specific categories at the bottom. It's important to be flexible when designing a taxonomy. Some of them might only have one or two levels because you don't have a lot of selection that needs to be differentiated. But the more products you have and the broader variety of products you have in any one category, you might need to go to four or five levels deep in order to make sure all similar products are collected together. Next. A legacy of many historic ecommerce B2B websites from back in the day, before best practices around taxonomy design became common, is the presence of miscellaneous or other categories. This is sometimes a way of working around the whole collectively exhaustive requirement. "Oh, don't have a place for this product so I'm just gonna create a miscellaneous category and we'll dump it in there." Just like the junk drawer in your kitchen, over time these start to accumulate more and more products and become essentially unnavigable, whether it's to an agent or to human users, either way. And the last best practice to keep in mind is that when you have a subcategory under a main, you wanna be mindful about how many subcategories you have on the same level. It's one thing as an agent or a human to walk through one door and be exposed to five doors where I could go next. But if you expose me to twenty five, thirty different subcategories all at once, it can get very confusing and very overwhelming. So try to keep it no more than a dozen options under a given category. The next step of a data model is the attribution schema, and this is where we get into the specifics about one the products in one particular category. A couple of elements of a good attribution schema. One is to think about the attributes and how you want to use them in your experience, and how you want agents to use them in your experience. Navigation attributes are the attributes that are generally used, you can think of it for faceted search. What are the attributes I wanna let my agents filter selection by? Oh, I only wanna see product that meets a certain specification, made of a certain material. This is about getting those agents from a category page to a detail page as quickly as possible. Display attributes then are what you show up on the detail page. These are the attributes that show the differences between specific SKUs within families. One thing to keep in mind about all attributes regardless of how they're being used is "are these required?" "Do we have to have this attribute populated for this SKU to get loaded?" If an attribute is being used as a navigation attribute, it should probably be required. If it's not and it's only a display attribute, it might be okay for it to be optional. So here's an example. If we look at industrial fasteners like a machine screw, we might have a number of different navigation attributes like material, thread type, head style, finish, and drive style that get us from a category page to a group of products. Maybe all the different sizes are shown all together as variants. But looking at that table that's displaying all the variants on that product page, that's where we show the display attributes that show the difference between every SKU. Length, diameter, tensile strength, package quantity, whatever differentiates product at that level. One other interesting element about attribution schema is that it oftentimes requires specific metadata. Because agents use data about product in very specific ways as part of their function, it's important to create rules around the values that we're assigning to these attributes. At a minimum, the examples of Attribute Metadata include "what type of data is it", is it text? Is it numeric? Is it an enumerated where I can only select from a set number of values? Is it Boolean? Yes or no? Next, what kind of units of measure are we going to make available and useful for this attribute? How are we gonna format them? The nice thing about the metric system is that, you know, millimeters is pretty standard. But in imperial, we have Inch, Inches, quotation marks. There's a lot of different values. So trying to set rules around what are the acceptable units of measure for a given attribute is often another element of metadata that can be encoded in the system. And also, is it if it's required, yes or no, that can also be very valuable metadata. Some companies will also even put definitions of the attributes in metadata, which given the powers of LLMs that are being used to drive some of these agents can also be helpful. Secondly, action models. So action models are the things that define what can be done by these agents, what are the things that we're going to allow them or support them doing on our website. So let's take a little bit of time to talk about what an action model is and maybe what it isn't. So an action model is just a definition of a business function, of a task, of an action that you want to support third party agents being able to do on your site. In order to run these successfully you have to define a lot of information. You have to define what kind of inputs are agents who do this action going to need from your different MCP servers. You are going to need to define what an output of an agent doing this action is going to be able to come away with, and you're gonna need to understand what is the intent behind it. Writing down all of these tasks can be a little difficult for some companies coming out of the gate if they haven't necessarily thought in detail about the specific nuances of these actions even for their human partners, much less AI agents. Another element here is to think about any sort of preconditions that are necessary for agents to have access or to bring with them before they accomplish the task. Also, what happens if the agent comes and tries to do an action but it can't? It fails. Maybe because the necessary product data isn't available or is inconsistent or confusing. You want to define what the failure stage looks like. Does the agent then say, "oh, this didn't work, please reach out to customer service" or "please reach out to a human." and bring a human into the loop at that point. The implementation of these action models is very much a part of building and launching an MCP directory. And so therefore the goal is to try to create a set of processes that third party agents can do which is very controlled, very predictable and enables the agents to be capable for the tasks that they've been assigned by their creators. Now, let's talk about what action models aren't. First of all, this is not just sort of some random free form AI prompt. We do not want third party agents to come and basically talk to our in house version of ChatGPT which is just going to figure things out. Because of the direct impact on business that that sort of interaction could have, we wanna try to minimize that whenever possible. It's not that we don't want these third party agents to be able to improvise on our site, ideally. Most of them shouldn't. A good AI agent coming from the outside should have its own rules around what happens if things don't go right, what happens if the data is not there. So by baking this into your MCP directory, you can help to keep that under control. It's also not a replacement for human judgment. An action model is probably not going to be able to cover every single edge case, there is going to be a need for humans to supervise and review. So, don't beat yourself up if you implement an action model and you still have instances where agents come in and fail. It's also not really an unlimited capacity. Right? Action models are designed for specific tasks. And so the goal is to define action models for the activities and tasks that you think AI agents are gonna do the most, because those are gonna be the ones that will have the biggest impact on your business. Those are the ones that you'll be able to take off of your inside or outside salespeople and have handled by agents. One guideline that can help make people feel a little better about agents on your website is that most AI agents shouldn't be able to improvise. It's not to say that they can't be written to do that, but one of the things that you wanna try to work on with your partners who are creating agents and sending them to your site is to have what those agents do comply with the action models you've built standards for and limit the other ones when you can. It's not to say that it can't be done, but it shouldn't be done. And communicating with your partners who are setting these up is important. So let's look at an example of an action model template. So this is an action model for an action called track order status. So we're gonna define the intent and say, "hey, we want to get an understanding of this order that we placed, where is it? Has it shipped? Is it in transit? Has it been delivered? Has it been lost?" We lay out the required inputs for this product, for this action, that the AI agent is should have and should be able to tap into in order to find this order. Maybe it's an order number. Maybe it's a PO number. Maybe it's products that are on that PO number. We can then also lay out what an expected output looks like. It should contain the PO number, to confirm and validate for the agent that this is the right shipment, it should contain a tracking number, it should contain the source information, where did the shipment originate, and it should contain the destination, where is it going to. And lastly, error handling. What happens if we submit a PO number and it's not in the system? What should the agent do next? Maybe it should go back to its library of other agents and activate a different agent for order confirmation just to validate that it happened to begin with. Maybe it's about getting a human in the loop at that point. Regardless. These four elements are the four basic ingredients that go into an action model. So one of the things that's important to keep in mind about both of these aspects of building an agent directory is you want to proceed modularly when it comes to rolling them out. It is not realistic, nor is it very practical to say we're gonna try to boil the ocean and create perfect data models and perfect data for every one of our actions that we wanna support. Not every action is going to be equally used by each of the agents your partners, customers and suppliers are sending to you. So ideally, want to try to match the agents, the actions that you are defining upfront with the activities that these agents are doing to try to do most of the heavy lifting as you can. So start with the ones that are going to be the most meaningful and take off the most busy work to begin with. Maybe start with three or five actions. Don't try to solve every problem all at once because you're also going to learn a lot by defining those first few actions and seeing them all the way through to completion. It's also important to note, the action models that we build are going to be highly dependent on the product data that we have available. So this is one of the reasons that it's important to define the product data first before we dig into building action models. The action models that we build, some of the inputs that go into those are going to be fields that exist in the MCP servers for product data, which is usually the PIM. So one of the things that we wanna do is establish in the product data model "these are the attributes that we wanna control, define and populate" so that those can be available when we're designing action models. Last piece of element here is the idea of governance and rollout. So a couple of things to keep in mind. AI agents have the potential to be very impactful on the business. They can do a lot of things at scale, which if not adequately controlled, could really create some harm. So a couple of things to keep in mind. First of all, one of the things that I like to talk about when it comes to product data quality what I call the 5Cs of product content. Building a product data model essentially is simply defining the standard to which we're going to hold product data to for every category in our offering. But that is not to say that every skew across our entire product catalog needs to be held to the same standard. There's a tiering of product data quality. The most important is the data needs to be correct, obviously, if the data's wrong we're gonna have a bad time. But next is the product data needs to be complete. If we're populating an attribute that we're gonna use to drive a navigation search attribute, then it's important that every skew in that category have that attribute populated. If I'm selling fasteners, and only sixty percent of the SKUs in my category have a value for material, then anytime an agent comes and filters by material, they're going to lose forty percent of the selection. The forty percent that doesn't have that attribute populated. Completeness is really important. Consistency is also important. Once all those fields are populated, making sure that we have eliminated and solved that problem of is it six inches? Is it half a foot? Is it six quotation marks? All the normalization that comes with product data. Consistency is the element we're trying to manage there. Then you have clarity. Is the language we're using to populate these attributes something that a regular non expert would do. In B2B in particular, this can be a significant challenge. Because a lot of companies who manage and supply data like to use their own terminology. But in order to facilitate comparison, having a uniform, consistent, very clear approach to language can be useful. The last element here is contextualized. And this is one that is relatively new coming around because of the growth in capabilities from a lot of the search and merchandising platforms to do things like change relevance and ranking rules depending on which segment this customer is in. Having an understanding of all of the information that we have helps us to track which products are getting bought together, but also to understand why. And so when we're looking to implement a more contextualized experience for our customer, the more product data that we have, the more consistently it's filled, the clearer the language. The better job we're gonna be able to do serving up a truly contextualized experience. Now, on the agent permission side, obviously we wanna be really really careful about the permissions that we let agents do. Different agents might have different permissions based on the types of roles that they have, based on the types of tasks they're trying to do. And these are a couple of very high level principles and guidelines around setting those up for agents. You know, giving them the least amount of privilege that they can, don't give them powers that they don't need. Making sure that the permissions and access that each agent has are tied to the type of action that that agent is trying to do. Being able to give very granular permissions, being able to give agents different kinds of permissions than a human user coming from a particular customer. And of course being able to audit the results afterwards. We wanna learn from the activities that agents are doing on our sites and be able to audit and update those rules over time. So when it comes to setting up one of these MCP or agent directories, where do you begin? Obviously, the phase one here is working on establishing your product data standards. So making sure that you have a very clear definitions around your product taxonomy, your attribution schema, the metadata associated with every one of those attributes, that represents the vision of what you want to get to. So go ahead and define that now. And then you have to actually go and apply it to the selection that you have. There are two parts to the product data server. One is defining the standard and then establishing rules for which categories you're gonna prioritize and hold to a higher standard. And some of the long tail product categories that maybe you have but aren't super important to your business, those can wait until later. Phase two in the action planning. Well, once you have the attribution model set, now you can start looking at actions and defining those actions in an action server. Making sure that you have all of the attributes defined so that the inputs to these actions can be accurately and consistently described in those definitions is very important. And lastly, make sure that we publish the directory and start testing it with the various MCP servers that we have in our system. Most importantly, this is a modular approach, start small. Start with a couple of categories. Start with a couple of actions. Test and make sure that the way you're setting this up is gonna scale. It's much easier to go back and redo a data model for a couple dozen categories than it is to try to do it across six thousand nodes of a master taxonomy at a giant industrial full line distributor. So if there's any takeaways from this that I hope you carry with you. First of all is start with your product data. I've said that many times. I will say it again. It is the most important thing to begin. Once you've done your product data foundation, then start iterating on action models. Yes, you can think about starting with that internally. Maybe doing a customer digital journey, journey mapping exercise with your team, but also make a point to go out and visit your customers, visit your suppliers. Talk to them about what kind of agents they are building, what are they trying to do with those agents. The better job you can do with communicating with them about what they want and you can communicate with them about what you can build, that's a win win situation. They're gonna learn that you have an interest in being a partner with them, and not every one of their partners might be willing to do that. Making sure that you're controlling access of what these agents can access and what systems, what servers they're allowed to engage with. Very very important. Not only from a business perspective, from a security perspective, especially when you're looking at a global situation where some countries might have different rules about access, and permissions. And lastly, whatever you're doing with product data, action models, start small, iterate, look at the results, and test. So your challenge coming out of this discussion today is to start the internal conversations about where are we going to begin. Yes, That entails also a conversation about "are we ready to begin at all?" But increasingly, the question shouldn't be "are we ready?" but "where do we begin?" If at this point you are still thinking, well, I'm not sure if this is the right time for us to begin. I would challenge you to think, if we're not ready, are we opening the door to our competitors to supplant us in terms of what our customers, what our partners, what our suppliers can do. The perception of just starting to have these conversations might position you better than just deferring for another year. So with that in mind, thank you for your time today. Go ahead and get that project started and thanks again.