Interview: Patrick Mouwen — Commerce, MCP and the API layer underneath

Hi and welcome to Dynamic Subtate. We have a new episode today from sunny Slovenia at the Dynamic's Minds and we'll be as usual. Gustav Sundod. Hello everyone. How are you this sunny morning in Slovenia? I'm a bit tired. It's got a bit late. Yeah yeah. And you can hear it from my voice as well. So it's about otherwise it's fine. It's amazing. We also have a guest here in the room. That's fantastic. Hello Patrick. Welcome to the show. Thanks for inviting me again. Thank you. Second time exactly. Patrick Bowen. Commerce hero. I would say community commerce hero. Don't go do it. We said the expectations high. Yeah. No, but I mean Patrick, you are here and you had a presentation on the MCP and the Commerce API. So we're going to talk about that shortly. But you're also known for a document doing what Microsoft should have done from the start really like documenting all of the commerce CSU API. So that's a real contribution. That's why I used the hero term, right? But it's a huge contribution. I've used it. I know a lot of people who use it that makes life easier. So that's really thankful for that. But tell us about your session here and what you're doing in Slovenia. Yeah, so commerce is unfortunately a bit understated on this conference. Yeah. So I was happy to jump in. And my session was actually about Commerce MCP. So Microsoft currently have Commerce MCP in private preview. Yeah. But if you look at it, it's only very, very tiny subset of the APIs that are actually exposed as tools, as per that Commerce MCP. It's only nine tools of 650 operations. Yeah. It's kind of a pity and it's not moving fast as it seems. Because in the previous version, there were only eight tools and the version before six. Yeah. Because I'm always looking into the latest code. I have been looking into the V48 preview. Yeah. So but already last year we would be working on an alternative. And in a nutshell, and we can go into more detail if you want. But in a nutshell, we are actually using Azure API management as a façade layer, as a publishing layer for most of our clients' APIs. Yeah. And that includes commerce, but also other IBSs and other APIs. Yeah, not Microsofts. Exactly. Yeah. And what I demonstrated in my demo was that if you do that properly following yeah, best practices that are out there in the market, layer by layer, from DTO to API to MCP, etc. And also the system prompting on the agent level. Yeah. And then you are able to actually use Azure API management both for your API publishing as well as for MCP. Yeah. So basically it converts to make it simple. It converts the API, the well-documented API and notwithstanding to an MCP, to the MCP protocol really. So it can be leveraged in agent scenarios, right? That's really cool. And back back to your point, you sneaked it into your center, the documentation's key. Exactly. So that features GA has been introduced, Jan this year, a GA by Microsoft for Azure API management, but we started using it already last year when it was in the preview or in beta. And it works really well. Yeah. Of course, if you want to have a full-blown MCP server fully in control, this could be an option. You can also, of course, host a proxy MCP server behind Azure API management, but what we demonstrated was that we just took the commerce APIs and we had a set of 40 and also some FNOA for address updates. We wrapped that into one API with the 40 operations in API management. Then we used the conversion, as you outlined, to publish an MCP server from the same APIs. And then we started leveraging or actually consuming that from a cloud desktop. We also tried co-pilot studio with the GPT engine, but the results were a bit disappointing. Okay. Was it because of the model you think or did you try out using the cloud model within co-pilot studio? Because then I mean, you would in theory at least get similar results as with the cloud, but that's not everyone has those activated, of course, in their tenants. So that's a completely judge. I wasn't on the time, on the time pressure, but I think one of the yeah, the size effect was the model. Yeah. Because we struggled in co-pilot studio, we struggled to get it working with actual workflows. I did. Yeah. If you ask a more sophisticated question, like, okay, I want this item to be added to a new card, but at the same time, same prompt, pick my last four sales orders, advocate the lines or the line quality. So that lines are not duplicated or itemities don't end up on different lines. No. And then add them to the same card. That's a lot of API requests behind MCP tools. But in co-pilot studio, it was very difficult to get that working. Yeah, because it was stuck. It was stuck and it didn't select the correct APIs and the correct SQL, because that would be my concern. My concern about MCP and agents in general is that kind of in these use cases where you want, it's very deterministic. You want the customer to be able to place the order at the correct price and so forth. So it's really, it's a perfect fit for an API and a front end where you really control what the customer is doing, right? Prompting it, I would imagine that's the challenge, right? Even if you convert to MCP, you have to be very clear about the skills and the instructions and the guardrails. So what's your experience there and then the trials with using an agent with commerce APIs? Yeah, maybe for the audience, also good to give some tangible. Yeah, exactly. Your example. Yeah. So what we demonstrated as well was a scenario where a call center employee was actually working on behalf of a B2B customer and switched during the session. So the agent was actually impersonating a B2B user and then acting on behalf of it. So we took, for example, a quotation document that was sent out to the customer, 50 line document and the agent could read the content and then ultimately create a card at the card, prepare the card basically and then either the call center agent or sorry, the cause and the employee could actually finish it and check it out. So that was basically a document to order version or it could prepare the card and then dispatch it back to the client. Yeah, finalize the flow basically. Yeah, then finalize it. So back to your point, guardrails are really important because you want to have predictive outcomes in an enterprise environment and yeah, that's where we experimented. Yeah. Because you can do a lot in the system prompt. So if you're going to co-pilot studio and then the agent definition, then you can write a prompt but the longer it gets to the more instructions, the slower it could be because I learned on this conference, actually not during experiment with being here, that the full instruction set is always consumed by the model with every prompt, every action that it takes. So it's a high total consumption and it's not the format. No, exactly. And that's what we found out but we didn't have an answer. The only thing we ended up doing is moving in a broad desktop and luckily we minimized the instructions. And then I found out that if we put more metadata in the MCP tool definition, so one layer down, then it's actually much more performant. Yeah, so I'm also from a token consumption perspective. So consumption is better as well. And at this conference, again, I learned that there is a six layer so we were actually working from five layers of the data. Mystical six layer. The six are the skills. Yeah, exactly. And what I learned is that skills are not consumed every single time the action is actually executed, but it's occasionally. So when the agent finds out, I need the skill now, then it's loading it. So that's much more efficient and in the next iteration, the problem also is that it loads the skills into the context window and eventually the context window will be purged or compressed and then it will lose some of the skills. And hopefully it will understand that they need to read them again, but it might be. But I'm drinking on what you said about reading like a quotation document because these are the things that AI is perfect for understanding human text and sentences and words and whatever. When you need to do a workflow, they are usually maybe not as predictable as a script or as a power ultimate flow or something else that you can actually make very descriptive. A very strong point because what I found out as well with commerce, when you are customer facing, it's different than when you use the MCP server. If somebody is filling around with the dynamic MC server, then it's not really a big deal, if some things happen of course, it can have big impact. Yeah, and you can control it with security roles. And customer facing, you're talking about your brand, you're talking about your reputation. And maybe you picked it up yesterday, but I could even ask technical questions. - That's right, exactly. - How does it work? - Yeah. - Is there a workaround? Can you give me a zero price? Exactly, yeah. - So that's the point where the instructions come in to the metadata at the various layers are so important. And back to the use cases, what I really liked, but that's more into the call centers, you know, is that the agent without asking was actually spotting a lot of master data issues. - Yeah, exactly. You mentioned as well the address. That was really cool. And you can get those fixed. But then you were actually using the Dynamics ERP connectors right to go and fix the address or the APIs in commerce. - So since all the data is actually staged, right? - Yeah. - It's usually database, the address information as well. - You could change it there, yeah. - Yeah, but we decided for, because in commerce there are basically two options to update the address information in the back-end. You can do it asynchronously or synchronously. - Yeah. - We decided to do it synchronously because in a lot of client context, there are multiple systems updating addresses. And then the actuality. - It might be at the context, yeah. - Yeah, it's really important. - After the context. And what I like about this entire scenario is, not only your demo, but from a commerce perspective, is that commerce in itself, in the application, is really locked down as the wrong word, but it's context-sensitive, right? So you have all of these APIs, and you've always checked some balances on what an employee is allowed to do, what an application is allowed to do, and what you're really doing is just adding the MCP layer to handle the interaction here, but the security and the checks are still there, because again, my worry here, as you mentioned as well, if you have an agent and you don't have that control, it can wreak havoc on both your brand and your ordering, because you might get incorrect prices. You've seen horror stories of people cheating the agents by fooling them and getting a discount that they're not allowed to get, right? But as long as you, but in this scenario, that wouldn't really be an agent problem. It would be a configuration problem on your end. You've set it up incorrectly, because you allow people to do overrides that you shouldn't allow them to do. So as long as you have your commerce set up properly in place, which is a completely MCP-agnostic thing, right, then you can enable APM on top and then using APM. So how much did you have to massage the APIs to get it working properly in MCP? - Yeah, so not too much. So your question is really good, but it has a lot of, you know, left-setting rights. So let's start at the basic level. If you look at the 650 operations that I called out earlier, they're not technically document. You can extract a swagger from what does it use you, but it's a technical swagger. Well, what I mean by that is if you do a commerce product search, for example, or search criteria, you can have various requests for the same API. You can search by item ID, you can search by record ID, you can search by condition, all on top of the same API. So it's very important, especially for an LLN, to understand if I take this request for the same API, what is my output, and what can I do with the output? What are my subsequent steps? So it starts with having the API well documented and that's missing already. So if you compare to a mock architecture, right? So API first, the hacker is the-- - That is architecture. - Et cetera. They benefit because from the ground up, when these APIs are defined, they're well documented. Go to the Shopify website. - Yeah, exactly. - You will find them very easy with the LLN, with examples, yeah. - So converting that to MCP is a piece of cake. But if your APIs are basically designed to serve dynamic software like-- - Yeah, it's already integrated, yeah. - And it was a platform, and the dynamic was POS. And there was no need to actually go-- - No, there was no, exactly. - Because there was always-- - It weren't supposed to be used by Spine, anything else. - It was just an internal use. - I heard the same, actually the same discussion yesterday, because I talked to one of the Microsoft guys who were here. And we talked about X++ development. And when he mentioned that when he was taught to develop X++, they would say that, take the label text and put it in the description field for that entity in the X++, because you never used it. Anyway, you just need a descriptive text. But now it's like the more text you put into the description of the field, the better the MCP will be able to tell the LLN what it actually can do with the field. - Yeah, it's spot on, but it's require-- - Because the description is no longer for people to read. It's for an LLN to read. - So we are-- this was kind of a negative angle, not a positive, because the framework of commerce is absolutely so fundamentally strong. The security is really good, because if you take a customer role, it is baked into every API which supports customer interaction. Then it automatically filters all the data out, which is not relevant in terms of commerce. So it's not solely you giving you access. It gives you a specific context, contextual access. That's exactly what you want in an LLN scenario. You never want the customers or the data from customer A to be in the hands of customers. - No, that's what I mean. The controls are already there. The context is there as well. I am a customer. OK, great. I am a customer from an agent perspective that makes total sense. - So security wise, it's really strong. Performance wise, you see, it's really strong. There are lots of APIs. It has a broad coverage. It's fantastic, actually. The only thing that was missing as we just pointed out was the metadata. But if you look into the DLLs of commerce, so you go to the DLLs, you would compile them. Which I normally do, because I want to know. - There you can see. - Exactly. - At the nitty gritty detail, then you see that the labels that you were referring to, they are there. So there is an entity's DLL. If you unravel it, you will find it. And you just have to extract that metadata. Which is not done. So it could be an idea. - So pointers to Microsoft, exactly. They already have the data. They just need to give it to you. - The only thing that they don't have is these specific request response patterns and what they do. And that's even more important. So I call that my layer one, if I take the layer model that I've presented here. The first layer, the DTO layer, is the object layer. So if you have a product, the product is 50 properties. For example, the labels that we just refer to, those are sitting in the entity that you deal with. So they are there. The product definition itself, fine. So at DTO level, we have the information. It's only not exposed. Then if you go one level up, the API itself, we don't have much metadata baked in to the CGU, unfortunately. So what I saw, and now Microsoft are actually working on that commerce MCP, it is hard coded in the CGU. - Yeah. - And they now add that metadata. - And what's exposed there? - Because the tools, yeah, exactly. - The only downside is that if you leverage that second layer as a customer, your hands are quite tight because it suffers as a service. So you would need a code update through Microsoft, or there would be extensibility at some point in the near future. But even then, you would need a code iteration, a code deployment, which is what I deal in an agent world. Because you need a lot of iterations to optimize the other layers as well. So what we did is we actually lifted that over to actual management. And then you're in control. Because then you can manipulate the open API spec completely. And you can put your tool descriptions in there. - Yeah, well that's irrelevant. I mean, for anyone using APIs, regardless if they only have the CSU using API management and kind of exposing all of your APIs and can not canonize format across the organization, it's a good tip for anyone who's not doing it anyway, not regardless of the CSU. But what you're saying is that it also opens up capabilities for you to describe the APIs in a way that's more than out of the box Microsoft, right? - 100% so it works for external APIs, custom APIs, dataverse APIs, inventory visibility, name it, non-microsoft, maybe even SAP. You could even build it agnostic that the NCP servers are no longer system oriented. Because now we are presenting, we have an MCP for data for us. - Yeah, yeah, yeah. - But they domain oriented. I've got an MCP server for cart handling. I've got one for a few. - Exactly. - One for customer management. I've mostly of the systems, which are actually delivering or providing the data. - Yeah, that's what I love about your presentation as well. You went into that kind of best practice. It's hard to say best practice because you might differ of course, but that domain split where you have, you might have 60 APIs in total covering your business. But for performance reasons, secure the reasons. Many, like just understanding what you're doing reasons. It's a good thing to divide them into domains, as you mentioned, parts. And that doesn't really matter if it's three systems underneath or one system underneath, it makes total sense to do that division from a manageability perspective. That was a really good tip, I think. - Yeah, so we are all hearing, right? - Yeah. - Yeah. - And I learned a lot of years ago. which we could have done better but I'm already very happy with the result because we deliberately capped the number of tools to 30, 14 in this case, but I undertake the view, working with 30 and I think that's quite the maximum because over 30 it starts to hallucinate and it starts to do things that you know and it's slower. But I think also if you go higher in the number of tools you also need to restrict it more in form of skills and system problems and you need to give it more detailed. I mean because if you look at the regular toolbox there are things that basically from an abstract level does exactly the same but they don't do exactly the same because they do slightly different things and in order to be able to use this tool you need to know when is this tool applicable instead of this one and it's the same thing here that the description in the skills and the description in the tools will probably hint at the model that if you're going to do this specific operation then this tool is the optimal one and if you have more a more generic description then that won't happen. You won't end up in a situation where it deterministically can choose the correct tool. So my advice 100% agreed with what you just said is keep the number of tools per MCP server limited and share that you optimize your metadata for each and exactly as you state when you consume it you can have multiple MCP server connections but ensure that the agent is constructed in a way that it knows what to call when and then the multi-agent set up right with some agents can also be very useful there. So in larger configurations I think for my demo it wasn't even required. It was a simple use case right not a simple use case but exactly what you say it goes from the MCP it's kind of like object oriented it's the same approach we always had to take like group whatever logical components you have into manageable pieces same with agents if you have an agent it's better to group it into a sub agent that has a clear purpose and task we did the Minecraft presentation right so we had one agent scanning for quotes and then connecting to Minecraft much I had much better output when we split it up so the one agent actually scanned the quotes and then passed off work to the sub agent and that's you could do it in one but then you run a higher risk of the agent not mixing things up and trying to do things in another MCP server so it just goes across the board right try to split things up and ensure I have an agent taking orders I have an agent answering questions about orders perhaps those should be split right because it makes sense yeah but that's also at the same time it's it's making it really complex yeah there are so many parameters which can influence performance or total usage yes and I think the next stage of AI adoption is not about getting things working or getting things done the next stage is to optimize cost definitely and optimize performance because that was one of the initially maybe a story to tell I recorded all my demos not only because I talked about it but also because I wasn't so sure about the performance but then actually on Monday until the day before my session I learned a lot of stuff which we already implemented by updating and tweaking yeah so I was working until 12 30 the day before my session yeah and then I found out I'm now at the stage that is it's performing so well and I can ask literally any question I'm not going to show my recording I will do it live yeah yeah yeah yeah yeah yeah yeah yeah that referral that brought as a song kind of guideline yeah no guts no glory but that's so they work perfectly in the demo at least I was sitting in the audience who I saw it it's a very good demo so that proves that so with only one day time span yeah and a lot of iterations during the day you can make use progress so so the flexibility the agility of how you maintain that metadata and how you could treat it how fast you could treat it that is in my opinion decisive yeah so that's why I think hard code in the MCP circle may not be the right way I think it would be better to detach the metadata so you can update it outside code yeah but it's a new role right being like an MCP because was news to me I worked with APM but I didn't know the flexibility of like spinning up the MCP based on the APIs in APM was more into like building MCP service as you should stand alone really but it opens up a new like ballpark same as we as dynamics consultants right we end up in situations now where we are expected to be experts but no one is an expert yet on age there are many experts of course but it's a hard it's a new area to explore and what domain knowledge perspective it can become kind of a tricky gray area right same with the MCP service on because APM would be something you put on integration developers you manage our APIs right but now they need to also manage the MCPs and that becomes a pretty much a new role right because you might need to understand more about the process than you normally expect an integration architect to do it's a vast new world and it's ever changing it's what I'm saying so when not only looking at it technically you we need to think about who will manage these things who is the MCP owner that's that's a whole you know digital functions and roles that that you require in that domain which which you open up now exactly because I was attending a session yesterday about 365 agent yeah that's a new tool which was originally used by Microsoft internally yeah but now it's actually the bridge to secure the to interact secure your your agents to ensure that so originally the term shadow it was raining out of the now the term shadow exactly yeah so people can build agents in hours released so how do you keep it in control yeah and then you know it has a relationship with defender with in June yeah so yeah there's so much to it everybody needs to find it out there's so many parameters yeah exactly that's why I can imagine that customers think like I don't want to maintain it myself I don't want to have it in my tent and give it to Microsoft software as a service but that comes with a cost right yeah the cost of license but also the cost of flexibility yeah so it's weighing pros and cons and I think I see more more customers move toward use of Azure API management for as a base layer a professional enterprise ready management player it's also enterprise secure yeah it's it supports trolling which is also important perfect for a perfect with dynamics exactly yeah so there are also benefits and it's actually kind of low-code because the policies in there can now easily be updated with the use of code code or anything else you can see ICD it yeah so the overhead which it was kind of recognized by the community is getting lower and lower but the benefits are increasing because now you can use it for MCP as well yeah exactly it ties it together but it's empty light because I was yesterday I was at the meeting there they went to the roadmap of MCP because MCP is a protocol that's actually also important and and that's where they they build an MCP from the ground in you know full loan so and then you can also define pros there are ways they're way more functions within the MCP project that you can leverage yeah and that's not available yet in the environment but what I found out is I think for most customers those people are not fired so if you compare a full-blown MCP to the light vision which comes out when you convert your desk to be on APM yeah that is even a better business guys yeah and it's a maturity thing right a lot of business are in different areas of maturity with AI adoption right so most likely it doesn't really matter if they don't have the latest and greatest for most customers I would I wouldn't actually say right and the commerce use case again going back to that one is so perfect because as we said you already have the control in place within your API so by just exposing them to through APM you have even more control because then as you share you have throttle capabilities you have your you have control of the layer and then spinning up the MCP on top of that you that's a good area to store exploring the AI use cases if you haven't done them already because you have the control the agents might formulate things differently but if you built it correctly they won't be able to mess things up using the commerce APIs and the control that we have within commerce I think that's a good use case yeah you kind of maximize the software as a service component yeah exactly and the component that needs flexibility yeah we start with the SAP tool definition that's what you keep in your own tenant in your own control and the cool thing about this this whole architecture for commerce is that if you build your own front end if you still want to build your own e-commerce platform where I want to consume these APIs in Shopify or in Adobe Commerce or whatever in a hybrid setup you can do it by tapping into the AI layer and if you want agents to view the situation. - It's the same underline. - Yeah, it's just more described, exactly, so. - Stable frame, then you take the MCP cherry on the cake. - You have both, exactly. - Under the hood, it's still utilized the same idea. - Exactly, it's the same performance. - For people, don't realize yet are some people that MCP is actually API plus, it has some meaning. - Yes, it's basically an API with descriptions. - Yes, it's an instruction manual. - Yeah. - Pretty much. - Of course, it's an API with a new instruction manual. - The MCP guys, they will tell you that it's-- - It's more. - Way more than that. - Yeah. - And it's also moving forward into a very sophisticated-- - Protocol, yeah. - Protocol, yes. So I think it will remain, because there are also lots of statements on it. - Yeah, it seems like the MCP won that, yeah. The battle off, I didn't even know what, there are many other protocols, of course, that LLM is gonna understand, but MCP seems to be the winner here when it comes to adoption, I would say. So the time is kind of running out, but looking in the future, or in the AI world, their future might mean just a week ahead, right? (laughing) But future-- - Tomorrow morning. - Tomorrow morning, or like an hour from now. - Something new has shifted, but where do you see commerce going from an AI adoption perspective like near future, any takeaways? - Yeah, so in my vision, I also shared that in all the chats. It's, I think, agented commerce will break out of the corporate enterprise boundaries. Meaning, if we shop now, then we visit a website or a web shop, and we start clicking things together, adding the basket, or things to the basket, et cetera. But in the future, that UX, I think, will kind of disappear. - Yeah, I mean, they have already, they have already launched and discussed the ACP protocol, which is the agentic commerce protocol, which basically means that you can have agents that purchase things for you instead with the protocol. - Yeah, so for coming up to your question, that public facing capability, exposing the products that you are able to sell hide yourself through sub-parties, that will become more important. So opening up those APIs, you know, to actually expose, will become more important. So eventually back to your point, you will have an app, and you're actually not knowing who is going to source or fulfill. - No, exactly, a personal shopper agent, and it just connects to anyone who has this ACP enabled, and you have maybe a global payment ID or something like that, it handles all the payments, and then it's just brand agnostic. You might see the brand in the app, right? And then you need to really be, as a company, you need to be there in that list of companies supporting it, right, that's the whole point. But yeah, it sounds like a reasonable future, very maybe two weeks from now. (laughing) - We'll see. - So you need to hand your credit card over to the agents. - I already did a long time ago. They have all my payment information. I just, I don't know, I just have to remember to look at it once a month, see. - What do you do by this time? - Yeah, and I have kids as well, you know, so I just, I need to scrutinize that anyway with controls. - I heard this discussion, this story the other day that someone actually had like an open closet up at home, and it was listening in on their chats with his wife, and his wife told him that we have a problem with the sink in the kitchen, so the open closet picked it up, and it actually ordered a carpenter coming to fix it, a handyman coming to fix it. So he just showed up on the doorstep and was like, I'm going to fix your sink. Okay, who ordered that? - Who's listening in? - Yeah, exactly. - So apparently the agent actually had access to credit card or to like contact information, so it actually called a carpenter. I mean, it's a great idea. I mean, don't get me wrong. I would really like to have an agent, which I can tell the sink is not working. Could you just fix it? But it's also extremely scary because we are not there yet from a maturity perspective. - And then as a company, if you leverage commerce and dynamics going back to time together, baby, ensure that you have these controls in place to avoid these scenarios that you don't want customers to experience, then you're probably at least safer to start elaborating with these things because then the agent can only do so much as the agent is allowed to do. That I think would be the takeaway from this that don't be scared, but ensure that you have your controls in place. - Yeah, the whole framework, the stable rock solar framework here, you only need just that flexible topping, the topping layer, that's what we outlined today. - Yeah, thank you so much, Peter, for joining us. - Thank you very much. - Looking forward to connect again in the future. And again, the future is very, very close. - Thanks for having me. - Thank you. Take care. - Bye-bye. (upbeat music)