What if the biggest obstacle to AI in your business isn’t the technology, but the way your systems were built to assume a human would always be clicking?
In this episode of Mastering AI with the Experts, I sit down with Frédéric Bélanger, Leader AI & Innovation at Talan. Frédéric has spent years architecting B2B commerce and procurement systems, and he knows exactly where the friction lives and why it has been so hard to fix.
We go deep into what actually breaks when you move from portals and workflows to intent-driven buying, what it takes to make your data and systems agent-ready, and how to deploy AI agents safely in enterprise environments. No theory, no slideware. Just real architecture decisions and hard-won lessons.
You’ll learn:
1. Why B2B commerce was built around a human clicking, and why that assumption is now a liability
2. What shifts when you move from workflow-based APIs to intent-based APIs
3. How to tell if you have an AI opportunity or a data architecture problem
4. Why data field names and database column names now matter more than ever
5. What human in the loop actually means as a design decision, not a marketing phrase
6. How MCP servers simplify agent integration without requiring a full rearchitecture
7. What agent-to-agent commerce looks like and what questions we need to start answering now
8. Why non-deterministic tools in enterprise environments are manageable if you build them right
Whether you are a business leader evaluating AI investments in your commerce stack, or an architect designing the next generation of B2B systems, this episode gives you a practical framework for building agent-ready enterprise environments the right way.
Learn more about Talan’s AI Commerce Agent for B2B Buyers: https://bit.ly/4kZRDTj
The way I see it is you have to see the agent as an intern or as a junior employee. B2B commerce right now assumes that there is a UI with a human behind that clicks. Whoa, you’re telling me that I’m going to put a process in my business in a non-deterministic tool? Well, yes. When agents will make mistakes like big mistakes, who is responsible? Who is liable? If no one knows how to make sense of the data, the agent won’t make sense either.
Today’s guest is Frédéric Bon, leader of the AI innovation team in the Microsoft business unit at Talan, where he focuses on agentic transformation, specifically around Microsoft Dynamics 365 and B2B commerce. Fred has spent years architecting business-to-business commerce and procurement systems. He knows exactly where the friction lives and why it’s been so hard to fix. In this episode, we get into what actually breaks when you move from portals and workflows to intent-driven buying, what it takes to make your data and systems agent-ready, and how to deploy AI agents in enterprise environments safely. No TR, no slideware, just real architecture questions and hard-won lessons. Now, let’s dive in.
Hello, Frédéric. Uh, welcome to the show. Really happy to have you on uh today. Um, I know you’ve spent a lot of time in the trenches architecting like business-to-business commerce and procurement systems. So, I like the discussion today to stay practical like no theory, no slideware. What I’d really like to unpack with you is what changes when we move from portals and workflows to intent-driven buying and what it really takes to make AI agents safe and deployable uh in enterprise. Before we jump in, uh can you please quickly introduce yourself and uh maybe tell us a bit what you do at Talan right now?
Well, thank you for having me. Uh so my my name is Frédéric. I am the leader of uh AI and innovation team in our uh Microsoft business unit. So I work in empowering both uh our internal team and our customers in taking this agentic transformation specifically around the business application solutions of Microsoft Dynamics 365. Uh let me start with the first question. Um what I I’ve noticed personally um is that in our personal lives buying has become almost invisible in the sense that you can now buy from a click of a button. Uh when you’re trying to make a decision about what you’ll buy might be a service, a product or a service, you can now ask an LLM. So it’s very low friction. But at work, we’re still navigating portals, re-entering data, uh, you know, for things that we’ve ordered uh, every month. And as someone who architected this, these systems, why is buying at work still this painful? And is this fundamentally a technology problem or is it an incentive problem?
Well, the first thing to say about this is there has been a trend for the past well few years probably decade um where the B2B experiences in the commerce space is trying to mimic the B2C experiences. We’ve seen customers um wanting to get um the same type of experiences which is not exactly always possible but still the concept or the overall ease of use um is something that if you build a B2B portal today you would need to invest a lot of time in the UX and the experiences to have something that is more B2C like and there’s multiple reasons for that. One of them is because it just makes sense to make lives easier for people. Uh but also because you know as as we evolve as we grow um you know more more younger people uh come to be buyers or to work in these companies um and they expect or they expect more in general of the technology and you know we hear a lot of of clients say that oh we can do this in technology but then your technology cannot do that. These type of of of things makes it that uh the need of having experiences that are more B2C like um is there. However, that being said it’s not true for everything for multiple reasons. The complexity of B2B is — yeah, we have to see B2B as B2C with extra features, extra functionalities, right. You still do the same as the B2C commerce you have to to build carts and to buy but you add a layer of complexity on top of it that’s business-driven and that is specific to each uh client. So that’s why there’s commerce engines in in the market that specialize in the B2B market just because there’s some functionalities that go on top of the B2C experiences that you can still do with with good uh experience and everything but that um is more a bit more complex to tailor. And you know really there’s like the the concept of cost and you know aging technologies where sometimes you have something for a long time you don’t want to invest in new technology you don’t see the return on investment. Um, and that’s what makes it in the context of buying in in the B2B space is that buyers have to uh consume portals of their vendors and they might have multiple vendors, 15 vendors, 20 vendors and they all work differently. Some of them are more modern, some of them are less modern and they have to learn for each vendor how to use them and and that’s what makes it a bit more complex. Even if all of the portals were B2C like with with a lot of of friction-free experience, you would still experience some friction by having to communicate with all of the different portals in the market.
And you’ve you’ve mentioned that people already been working for systems for for years if it’s not been a decade in some cases. If you look at most of the business-to-business e-commerce platforms today, like what core architectural assumptions were they built on at that time that AI is now completely invalidating?
B2B commerce right now assumes that there is a UI with a human behind that clicks. You know, we used to spend so many effort and so many um dollars in having the right experience UX. There used to be like a whole industry and this still exists, right? To kind of make make this work and at the core of it, it was to place the human behind the clicks, right? So, it was like by design this concept, but this assumes you have workflows, you have sequence, you have a funnel. So the UX experience that we build right now um without the agentic transformation is to take the the user by the hand and do it step by step with them guiding them through. So you you you come up on the website there’s there’s a full concept of user journeys that are really important in commerce in general not just B2B but B2C specifically where you define how um your user will will evolve throughout their experience. So you pre-build an experience in a in a workflow that’s not based on intent. It’s based on on what I want you to do at what step based on the general intent or general um you know I want to buy something but it’s it’s not based on what the user wants to do at the moment he wants to do it. Right? So we’re shifting from a more sequence and workflow type of experience to a more intent type of experience. And we can see some examples like um the catalog. So just browsing products um browsing products in today’s today’s portals or today’s uh reality is really really crafted so that you can you can find the exact you can drill down your search to the exact uh product that you want to do and I guide you through this to get the exact right product. Now if you have uh an agent on top of it that does it for you that does the reasoning for you it will communicate with those systems uh differently um it will communicate with the intent in mind and not just these step by step. So that brings how your commerce engine will work. Um instead of providing actions or APIs to a UI that is meant for step one, step two, step three — to change and wrap it differently to provide some actions you can do in the system that are not necessarily guided — it’s intent-based. So the user won’t have to care anymore about the workflow itself or what it has access to or not because it will all be managed by the agent uh that will understand the intent of the user and act on it.
Correct. And and you know the the the the reason there’s a work right now is for is for removing friction, right? You don’t have to input your shipping address before you’re actually ready to buy which is that usually in checkout. That’s that’s today’s mindset — I I’m not even going to ask for anything about it unless I really need this information or when I need this information in a flow to kind of funnel the user and push it. But if you work more in intent, if you want to start the conversation by I need to buy something for this warehouse I’ve already provided my shipping address I don’t need to wait for step number 18 or whatever number of the step to do this action right. I want to provide to the agent that will reason and then that this this agent will communicate with my commerce engine to complete or to execute the actions of what I want to do. I can see it will remove a lot of friction. I’m the first one being very frustrated when I have to type in information that I’ve been given again and again and again. I have so many examples of I just get frustrated being asked the same thing and I feel like in this fast-paced world where I can get any information from — you know I was I was about to say by typing it but nowadays I can even use my voice to get any information that I want. It’s frustrating having to use the old old system. I’m saying old but that’s what [laughter] we’re doing here.
Soon to be old. Yeah, exactly. And I like what you’re mentioning. We’re going from a world where we were navigating to a world where it will be an expression of intent of what we want to achieve and we won’t be — we don’t face those boundaries that were forced by those those systems, by the interface itself. So be before we got into the the architecture of it. Can you walk me through a concrete example like for in instance someone will go into an agent and type something like get me what we ordered last quarter but I I need it faster into an AI interface. So it won’t be the the standard UI. It will go to a chatbot and Copilot for instance. We’ll type it in. It’s connected to a third party vendor. What does the system will actually have to do with that request? And then from a system standpoint, what has to change under the hood if something has to change to support that at scale.
So with the intent being uh the start of the conversation, it shifts from from the the workflow where we used to guide the user or to know where the user needed to start from and kind of have a start with them. Like, so usually it’s landing on websites but then then you get all of the how do you land on websites to uh you know to to to start your experience there. So right now in in — or or with the intent um agent um there is no start, you start wherever the the user want to start right, so there’s no one first point. And really what needs to happen is we need to understand what the user wants to do, what’s its intent, in order to serve it. And what does that mean is that the agent needs to analyze what you’re asking for um and make sense of what’s the different actions or different things to do in order to complete uh this intent and it could be multiple actions and it could be anywhere in the purchasing flow in a sense, right? So when you say something like get me what we ordered last quarter but faster — just the word get me uh we have to understand or the agent has to understand if the intent is to fetch some information, see what what I bought but not really buy it, or if I want to re-buy again, right? Um so get me what we ordered — when we ordered means order history. So okay, I need to go back to the order history find the related information based on on the context I’m providing to do to complete this action. Last quarter is our time frame. So the system will know okay I need to find information about order history for that time frame. And then the — you know — faster — or I don’t know how how you put it but something around delivering. I guess in your example it’s it’s the most the most interesting part is what does faster mean in this context right? Um, for you and for me it might be different right. So by seeing that — am I Am I asking the system to buy or to view what products? Is that the exact same products I want? Or maybe I want something different. If I had options that have a different product, but it’s similar, but it’s going to get there uh faster or getting there two weeks earlier. Maybe I want to suggest to buy this instead of the one I already bought. And then I need to do that. I need to understand the concept of um delivery time and in and shipping time and everything that that is usually available. But the agent will analyze all of these little pieces and kind of break down that into different actions to do and will not do that in sequence for you. Right? It will go get your order information from your system first. Then it will analyze, okay, what do you want to do? Okay, is there any other product? Go back on the system, find the information about products, return this information and use it to generate the next step and then oh I need faster. Okay, maybe I need to find another SKU or another product somewhere. [snorts] But what’s faster? Faster is about delivery time. Okay, so I need to find a delivery time, compare that and do all of the work for you to kind of give you a recommendation. And usually what we want to do is at at this point is we want to say okay I understand this and because of of of my — the intent I understood — here’s what I suggest we do next. Understanding the intent is kind of at the core of what the LLM does or the agent does. It’s kind of of of why we’re we’re using them. Um and then it orchestrates with the different actions you can execute to actually do uh what it’s supposed to do.
But in order to support that um right now if we use our system as is it will work. Uh but our systems um the way we traditionally used to interface with them uh was meant for again that workflow type step one step two step three where where it’s not about what I want to do it’s about what I am actually doing, right? So we’ll need to expand um the functionalities of — specifically in our case we’re discussing here the commerce servers — to move away from a more action-based API to a more intent-based API. So getting more possibilities. There’s so many ways you can find products in order history, right? The easiest one or the classic one if today you are to build an interface with another system is you would just go and get all the order history and then search through it. Um that might get complex if you do that in agent because every time someone asks a question about an order history would do these type of things. You know agents are not there to cache data. Agents are not there to understand the data or to store the data. They’re just there to call actions and get information. So maybe you want to find, you know, order history or or what you bought by SKU, by date, uh by type of products, by family products, you know, by categories. And then you want to provide to the agent all of these different types individually so they can choose the best one in the context of your intent. So instead of saying I need an order history API that gets me all of my order history with pagination, we’re moving from this to I need to provide um intent-based APIs where I can search through by SKU or I can search by time or I can search um by order number or whatever the the search is. So you’re providing and you’re changing at the core level — the commerce engine itself — the way it works and the business processes that there is in uh in there doesn’t really change. It’s how you expose it. You give more options and a more broader catalog of things that you can do or you can interact with a system instead of being the classic API that we know which just you know you have one for each and that’s it. And the famous CRUD operations type of APIs — I think it’s kind of moving away because I don’t want an agent to decide I want to create an entity. I want an agent to ask my system a question basically or do something specific.
There’s also the the concept of data. Data I mean is really important uh with agents. It’s been important for a while, right? That hasn’t changed, but it’s even more crucial now. Um, having accurate data but data that behaves well in an unstructured manner because your agent doesn’t know what the product is, doesn’t know what a variant is, doesn’t know what an item is, doesn’t know what a SKU is — you can infer it based on concept, you can even look online to get definitions. If your system gives you uh when when an action gives you — uses the name. So I’m not even in the content of the data, how you structure it in the name of the fields and and and what it returns as a as an API. Um if if the field name is different across different actions, agents will not perform, you know, in a perfect way because it’s going to be a bit you know lost in in all of these different uh terms, right? So you have to have good data but well-structured data but that works well in an unstructured way. And and again if if you don’t implement those changes um you can still do some of the things with agents but in order to perform it well and to kind of go to the next level you’ll need to have those those changes uh happening or or those uh different ways of communicating. And the data again is really at the core of everything and the way it’s structured — even like database fields — if if you ever have a system or or or an agent that communicates and gets for whatever reason some of the the broad uh table names and column names, all of that is used by the agent to understand what it is. So if you use like um you know smaller shorter names with like letters that are removed and like like acronyms it’s going to be harder for them to understand what is this column. The same way if I put the database viewer in front of a user and I say what is this column if it’s BK123, I don’t know what BK123 is you know. But if it’s a if it’s a clever name or intelligible name I will be able to to understand what what it is. So all of these little things that you know we didn’t care about — the table names before — well now we do. We didn’t care about the name of an API field like because you can always when you consume it I’ll document it I’ll tell you this field is this field anyways you’re going to do a mapping. Well, we’re not going to do mappings anymore. So this — all of these little things have an impact on uh being able to um execute the intent better and also in a sense understand the intent better because if there’s multiple steps to understand the the intent that requires some of the data, the data is important to to get the right uh the right thing. And if if in a prompt you talk about products for instance and then nowhere in none of your APIs, none of your uh actions available, you get the word product — it might just not — that’s where you start hallucinating, like it doesn’t know what to do in a sense.
So if I summarize — you have your agents need to understand the intent based on your use case, based on your industry and you know the work you’re doing, so that’s first. Then you have the tools or the actions that the agent can do. And then you have the data, the underlying data, so it can understand. And the example I use was purposely vague because that’s what I’m expecting an end user to ask, right? And it’s important I think for organizations to understand that it’s not as easy as giving it access to two, three tools and expecting for the best. It needs to have a real architecture, like well-built instructions, description of your action — I will suppose if we’re talking about agentic or generative orchestrations — if the underlying data is not good the output won’t be good. Uh, so those are three main pillars of building or architecting an agent, right?
Yeah, exactly. And and the intent is is is probably the the one that’s the hardest to understand because we’re so drilled about the the workflow and feature type of thing and then I want to do this. What’s the workflow? I’m I’m going to code if-then-else. We’re drilled for that, especially in the implementation and in and the consulting world and and everyone that works in technology anyways. We’ve we’ve been doing this for how many years? 70 decades now, right? So the concept of intent — I can create an intent to uh to an agent in this case and I have what I want to do done uh with that — is is complex. But when you give intent or when you um try to understand intent, it’s important also to tell the agent what to do and what not to do or how to interpret it and how not to interpret it, right? Uh you have to kind of guide the agent to to better understand the intent. So the context, you know, what you’re trying to do — that’s why agents are really contextual. Uh you really build up for something specific. Usually it’s never really just really at large because otherwise the intent understanding will not be as good as as it could if it was uh uh more precise.
Building on what you said about action, um it it means that it will integrate with other systems, right? Your agent will maybe integrate one system, but maybe multiple systems as part of the actions you can accomplish. What’s the hardest integration problem that you run into? Because not the slideware version of it — you know the real one because I know that marketing teams out there has been very good at um showcasing products like it’s a two, three click process to put an agent in place but I I know it’s not true. So what’s the main integration problem you’ve run into in trying to give access to those systems by your agents?
Technically, like in the most — there’s like the social portion of it which is adoption which is for now true in in every question and every and every changes uh but on a more uh concrete integration real world uh answer — obviously it’s the data in every sense of what data means. Um, data is king. If you don’t have the right data, if you don’t have consistency, you’re going to get some integration but not some good integration, right? So integrating with the with systems as long as they’re not too old is kind of not that complex but getting an integration to be meaningful is I think where is the hardest part, right? Because you need the right data you need the right business processes around the data as well. We have some clients sometimes that you ask you know what’s the business process and the answer is — and it’s in the head of this person. [laughter] Um that’s kind of where it’s a bit more complex — okay well how can the agent use the data efficiently if the process around it is is not really known, right? It’s kind of impossible for another system — like it would be for another human to understand it — um if if you don’t know exactly how it works. But you know other example like multiple sources of data, right? Usually you don’t get one — well, now in the modern architecture sure, you try to kind of centralize the data and have MDMs and stuff, but most of the time you you come to an ecosystem and the data is everywhere. It’s never in sync really. So, who’s the master for what? It depends. The master changes based on your application. So all this reality of your data being not in like the ideal state for um consuming by an agent is probably the hardest part of the uh of the integration. Um and then like I said there’s also like if the system is a bit older or there’s no ability to connect. Uh usually that’s not too much of an issue because if you get any APIs or any things that are more on the API side or some kind of connectivity to connect from the outside, you can always find solutions to connect. But the best obviously integrations will come when um the the integration methods are being thought of by uh or for agents, right? For the reason I was explaining, right? Because now your way of integrating the system and coming with the data is intent-based instead of just being I want to get this entity, I want to get this other entity and I want to write to this table. Um, so it’s it’s it’s going to be a bit easier if you have all of that in place. Um, but in terms of integration itself, it’s pretty straightforward to to connect systems together. It’s what it does. It’s it’s the the the power of it of of — or of the output — that’s important, right? Just connecting is easy but having a connection that’s useful — that’s the the most complex thing and it relates to data and availability of connectivity.
Not thinking of old systems but for newest systems do you think MCP servers might be a solution to that, like facilitating integration?
Yeah. Well, MCP — well, MCP in in in the end is a protocol, right? It’s just hey, we need a structured way to uh have agents being able to call in a sense APIs. The way I explain MCP usually to to my clients is MCP as APIs. It is not exactly the same thing. There’s a — it’s it’s not — it’s a simplification for sure, but it’s a way that we can see it. And um what’s good is you can create MCPs on top of existing APIs and add your intent logic in there. So it’s not that complex for products to provide relevant MCP uh servers if they already have some you know good APIs and everything because you don’t have to change the whole architecture. You just have to add another layer of logic on top of your APIs to kind of create this intent-based uh connectivity. But MCP or other — because there might be other protocols in the future that that arise — but I think it’s a good uh good path to have created a protocol um a standard basically that that that we can use across any technology or any you know platforms that use agents. And that for sure will — well, not will — is actually right now helping agents build better because it’s kind of impossible to kind of create your own connectivity. It really streamlines um this connecting part. That’s what I’m saying earlier — like it’s integration is not the hardest part. It’s that you have to have relevant actions in those MCP servers and actions that are useful in order to have the agent doing something useful. But connecting them together using technology like MCP it’s pretty straightforward for now anyways because I foresee that MCP will complexify over time, will have a bunch of other functionalities and might become a bit complex. But at the core of it what it does basically is it’s just a way to expose to agents hey here’s what you can do with me — you can add to the cart, you can search by keyword, you can search by SKU and then you can log in, right. Um, what do you want to do and then the agent chooses um what actions to execute based on the intent of the user. So it’s really like an easier way to expose um intent-based actions to uh some — to to agents no matter the technology you’re using.
You’ve mentioned the data um obviously that’s the foundation of everything when it comes to AI in general. So if a client reaches out to you and is ready to go all in uh with AI powering buying but their ERP and their pricing data are not agent-ready. How do you determine if it’s an AI opportunity or if it’s a data architecture problem?
It’s a good question. Um I I don’t believe it’s an either-or situation. Um, like you might have a data architecture problem but still be able to have AI opportunities — maybe even around those problems you can use AI to kind of identify and then evolve out of it, right? Um but in the more simplest way it’s not a good AI case or it’s more of a data architecture problem if if you can say that there’s no data — no data or no answer to your question. So a good example is if you ask someone how do you calculate the price for something — if the answer is it depends or I’m not really sure and then it goes in some kind of black box type of things and you don’t really know what happens, just computes a price — then you have a data architecture problem because if no one knows how to make sense of the data the agent won’t make sense either, right? Um, so it’s really like the simplest way just to put it. However on the other hand — if you do know how to compute it, it’s just really really complex, takes some time, tedious, error-prone — um that’s where AI can come in, right? Um the output might be the same — as in you get wrong prices on both — but one is because you have a data architecture problem and the other could be solved by AI, could be really helped by AI. So AI is really good at understanding complex uh things or pinpointing in a in a big lake of information what’s the right thing that’s needed to complete an action. Um, so being able to kind of — if if that process is slow and tedious um and and is prone to error — that’s kind of three things that tick the box as to oh that’s a good AI opportunity. And in a sense you can also look at uh from a decision perspective or reasoning, right? Reasoning is a big word that we’re using with agents. Um we want agents to reason and and give us the reason. Um if you can say that you could reason in some use cases but you’re not able to make a decision — that’s where you get a data cure [UNCLEAR: “data cure” — possibly “data quality”] problem. In another sense if you were able to make a decision but the decision is often wrong — that’s where you get an AI case.
Okay. That that’s a really good framework. I think there’s there’s a big big difference in retrieving data uh you know asking a question about your pricing or cost and then a human being is using it to uh answer the customer directly for instance and having um an agent that executes transactions against your live ERP, you know, live your live pricings, contracts and you know your full fulfillment logic that will affect uh basically what will be accomplished later on. So architecturally what has to be true for this second kind of agent that is taking action to be safe and deployable? Because I think we all heard those um stories of agents taking very bad decisions. How do you prevent that?
It’s a good question. It’s probably the question that is the most asked by all of our clients overall. This is kind of the the big question that people are like this is really great technology. This looks really, really great, but it also looks a bit scary, [laughter] right? Um, when I say that agents are non-deterministic, usually that’s the point where um, everyone kind of say, “Whoa, you’re telling me that I’m going to put a process in my business in a non-deterministic tool?” Well, yes, because it gives way more out of it. But that’s — that’s what we need to kind of work on, but also work on the safe portion of it, right? It has to be has to be safe. And I’m not sure if safe is the right word. Maybe guarded is a is a better word or something. Um, [clears throat] but it comes down to the architecture and how we implement the agent, what decisions we make — because agents anyways for now are not just going by themselves and doing something. They’re guided by what we tell them to do. Right? Like I said earlier, we have to tell them what to do or how to think and how to not think and what not to do, right? You have to guard them in a sense. But just that is not enough, right? Because we’ve seen all of the cases and the stories of people being able to go around the instruction of an agent uh because you can trick them. Um they’re better at not being tricked right now, but it’s still possible and I’m sure we’re going to see more more cases in the future. Um but so you need — it’s it’s it’s in a sense how you build it, not just on the instruction but everything that goes around the agent. So, obviously you get controls, you need to have like control systems in your in your environment. Same way you do for the laptops or all your employees, right? You have systems to control them. Uh we have the same thing for agents, right? You don’t want to cause the chaos and the free-for-all in in this in this sense and you want to be able to assess them, right? So, there are tools that exist on the market that go with the technology you’re choosing to be able to do that, right? And these are going to evolve. You’re going to evolve in a sense where it’s going to help larger organizations to kind of manage a larger agent fleet. But there’s kind of um I would say two concepts that are important.
The first one relates to something we already discussed is the data, right? Um and we’re never going to say it enough. Better data you get, the better output you get, right? That goes with safety as well. And how it goes with safety is about guessing. If my data is unstructured and doesn’t use the same keywords, the agent will need to do more guessing. And more guessing equals more chance of being wrong, right? So, this is also really important to have the right data in order to minimize the guessing and make sure that your intent in how to interpret it is on par with what you wanted to do, right? And and with the data, right? And in the terms of commerce, it’s like you need the actual prices to be the right prices for you. The agent, if it gets another price at the right one, um is going to make a bad decision because it didn’t get the right data.
The second thing that’s really important and I think it drives more of of how we design it — and by design I mean how you place the agent ecosystem and how you operate it — is the concept of human in the loop, which is a concept that’s really important, something that we place first on everything that we do. Um every agent that we build or every presentation that we do — it’s human in the loop. And at first when I heard that human in the loop I really thought it was marketing based like it feels not too tangible but when you think about it it’s it’s nothing — actually it’s just a concept of saying hey keep the human in the loop, keep the human part of every step, every time you have a chance of failing have a human validate, have a human be there, have a human guiding and taking the hand of the agent and make sure that they don’t do something stupid. There are things that are less um — have less risk — so you probably want to have less human in the loop just because why are we validating things that are not that important? But in a commerce scenario it’s about making sure that we have the right people along the way that will validate. And in a sense this process specifically in B2B already exists — when a client passes an order to their vendor the vendor will confirm the order back. They will already validate that what the uh the customer wanted to buy with the prices that they provided is the right one. So it’s already in the mechanics of of the flows that exist. It’s just that with the agents you have to find the right places to put those validations so that you ensure that uh that you don’t get bad results or bad um bad decisions or bad actions based on bad decisions. Now if they do happen it’s like any other thing, right? Today you can call someone, you can call your vendor by phone, you can tell them I want this and that and they can put it wrong in the system and you’ll have to manage it and you’ll have to say hey — and receive the right thing — oh because you didn’t order the right thing, well who did, what was the problem, you know, can I ship it back? All of that rolling back it’s going to be the same idea I think as as what we do today with more manual processes and everything. But the goal is to lower this to to the minimum by adding the right guardrails around the experiences.
And if we push this forward um in a world of agent to agent commerce and not looking for the optimistic answer, what still has to be solved uh especially you know everything around trust, liability and how contracts will form between autonomous systems, like before this becomes enterprise reality. What’s missing and what’s still need to be done?
I kind of want to say everything, [laughter] but that wouldn’t be a complete answer. Um, no, there’s there’s there’s a lot of of work still to do. Um so referring to agent to agent — that’s the concept of um you know we’ve we’ve been talking about [clears throat] agent in a B2B commerce world where um a user initiates a request, you know, buy me this, buy me that or where’s my order or blah blah blah and then the agent goes back to the commerce engine to kind of consume the information or do the action. But there’s no reason that’s only humans that communicate with agents, right? You can have another agent. So I can have — to relate to the beginning of of of of our conversation — and I said you might have 15 different or 20 different portals to log into and you have to learn them all. Well, if all of those 14 vendors had their own agent, I could create my own agent that communicates with all of the agents differently and kind of be um streamlining this process of communication with my vendor. If I want to shop across multiple vendors, then I can, right? Then I have to log into every portal to get is there inventory for this product. I want to look for the one that’s uh faster to to get to my client. Um you know I can I can look for multiple vendors at once because I have an agent that connects with other agents. But then that opens so many questions right. Um, how does that work? Now you get a non-deterministic agent on one side that talks to a non-deterministic agent on the other side. You might add all the the the guardrails that you want and the security and the safe concepts and human in the loop and everything. You’re still going to have two agents talking to each other and what if it fails. You know what happens if an order has not been placed correctly? Who’s responsible? Well, and and that’s true not just for agent to agent, right? When agents will make mistakes like big mistakes, who is responsible? Who’s liable for it? Right? How do you fix that?
My view on it is it’s still early because you know people people are still trying to figure out how to use these agents in these type of scenarios. It’s still not too advanced. It’s getting there. Uh but it’s still at the early stages. So these questions are kind of starting to be raised. I think they will be — one day, not too far from now — we’re going to have some answers. We’re going to have some, you know, the contracts that you have with your vendor will include some kind of liability, maybe insurances — that’s going to, you know, services that’s going to be added. We have liability insurances for everything. Why not agents? You know what I mean? Um, so this is something that’s going to, you know, in the future evolve and and be uh and be determined, I think. But yeah, um and then the next step after that is if you have agent to agent that negotiates — we’re not right now, right? It’s like now it’s human interacting with agents and then the next step will be — so we’ll figure out we’ll figure out when we’re at that point. But I think it’s important to ask the questions now though. It’s important to understand that these are risks and and these are things that need to be discussed and and defined because otherwise when we’re ready to do that technology-wise we’re not going to be ready with all of these little things. So this is coming up. We have to — and it’s the same thing with agents — like we we start small. We start with what we have right now. We have to foresee what’s the future. We have to implement it with a with a future in mind where one day it’s going to be and one day is not five years from now. You know one day is a few months from now, or maybe a year, maybe two — no one knows — but um this is coming soon, right? So we implement it um with a concrete mindset but we also uh keep in mind — so these questions are important to ask.
Yeah, agreed. Our CEO of AI, Mustafa Suleyman, just posted, I think last week, that he expects in the next 12 to 18 months, uh, everything could be processed by an agent. Let’s see. But it’s coming fast. It might be not in 12 to 18 months, but it’s coming fast. So, yeah. Um, what’s important to note is, you know, AI by itself, not not LLMs and agents, has been there for for a while now, and we’ve already kind of started some transition around using AI technologies. So, self-driving cars are one example. I’m not sure we even fixed it right now, but these are the same exact questions that we were asking when we saw the first — or or the uh the car-sharing of this world — applications. You know, who’s liable for it? Well, okay, we made a system because it’s just our system didn’t know what to do with it because it didn’t exist. Now, we just need to kind of come up with our own solution. So, it’s it’s important to talk about it.
We’re almost at the end of our time. Uh I have my two last signature questions. Can you share just one practical tip that helps you be more productive every day when you’re using AI?
Yeah, it’s about the prompt, right? Um right now everything’s about the prompt. Not sure in the future, but right now everything’s about the prompt. Productivity equals efficient agent and an efficient agent is made out of an efficient prompt. So it’s really about how you make a good prompt. And the tip that really helped me uh be better and in a sense be more efficient — but I also share that with a lot of people — is try to move out of or move away from the philosophy or the what we’re used to about like search engines, keyword searching, right? We’re used to Google and being — and you know going online and I remember when I first started using search engines you know we had to to learn what the plus is and the quotes and everything to kind of refine your search but it’s — use the keywords that you think is going to be the most present. Well, it’s intent-based now, right? It’s not keyword-based. So, we have to provide context and constraints. So, the way I see it is you have to see the agent as an intern or as a junior uh employee. What would you tell a human intern what to do to accomplish the job? You have to give them context. You have to say, well, if you want to do this, you have to go to this system, right? Because otherwise, it doesn’t know where to go, right? So, here’s a situation. Um, here’s what matters. Here’s your goal — because agents are already goal-driven. You have to tell them when their their job is done and here’s what I like you to do, right? So, you have to give more things instead of just saying search for this. So, it’s really like looking uh at the prompt as if it was an intern or another human being and explaining all the concept and the constraints — I think is a good tip.
Love it. Actually, that’s exactly what I’m teaching my my customers and what I’m, you know, I’m giving training. I I have a full video of it on my YouTube channel. So, love your answer and I totally agree. If you look 10 years ahead, how do you think AI will reshape the way we we transact? You know, we we live, work. You can ask six months from now and I don’t even know. So, [laughter] that’s why I’m asking the question.
I know. And I’ve watched some of your videos and and and I kind of knew this question was was coming. Um, 10 years from now is is uh is decades in this technology so you don’t really know but I like to play the game. I like to play the game of where it’s going, right? And where I think — and this is just me, obviously — I think that the way we interact with agents will change. Um that’s why I said earlier prompt — I’m not sure if in the future it’s going to be that important. Right now we do it through through natural language, talking to them either by text or voice. Um, but that’s how it’s kind of the only way to communicate it directly. Um in some scenarios we’ve put so much effort in UX in in the in the context of of today’s uh discussion about you know portals and B2B portals and everything and and even B2C and websites and we’ve put so much effort in being better at communicating with uh you know having a better experience and a more frictionless experience but in — and all of that to communicate with with um other systems. And now we’re back to only text. So something around that does not make too too much sense to me. This is going to evolve. But as part of evolution, we can also see that or foresee that agents are not just in our phones and in your laptop — could be everywhere, could be in your car, could be in your house. And you know what what technology have we worked on uh in the past few decades that now is really really good? Robots, right? So what happens when you put agents inside robots? And I I like to kind of play the game and see think what could it be like — humans are good at creating industries and stuff — how how will we make money out of it? So sometimes I think of of what’s going to be in the next few years where we might all have our own robots in in our house and say you need a plumber? Well, you go back to [clears throat] the the to your vendors of your robot and you buy the plumbing package, let’s say for two hours, and then you fix your problem and then and then you monetize knowledge and monetize intelligence. If if you listen to Elon Musk it’s for next year I think, 2027, that every household will — yeah, Musk is is really optimistic on the time frame but I don’t think he’s been that wrong yet. So um some people say it’s a bit like maybe 3 to 5 years um it’s — well some of them say two years um — you know superintelligence is something that’s coming someday which is on the one — obviously not in 10 years — like in 10 years we’re going to be used to use this technology and then society will be different, right? If you have robots to do the plumbing we don’t have plumbers anymore — so all of these jobs in your society don’t need — what did they do? We’re not just going to leave them on the bench in the park and not doing anything. We’re society — we’re going to invent something new, something that we didn’t even think exist — like we don’t even think it now. Ask a 100 years ago if if you had an industry of IT 100 years later. They didn’t know what it what it means to use electrons and wires to build computers and networking and everything, right? So, it’s things that we don’t even know could exist that’s going to get invented and that’s that’s what excites me — is like really eager to see what’s the future because no one absolutely knows where it’s going.
I I love your last point about we will find new ways of working or new things to do because I’m not doing my job like I did four years ago. I can tell you I will never imagine that prompt engineer would be a skill at all. It might not be needed in the near future but still something else will come from it. But in 10 years it will be somewhere somehow — you know even communicating with agents through senses, touching, eyes — I don’t know, maybe not. I like to play I like to play that game of of trying to see what it could be and then and then don’t bet too much money on it because pretty sure everyone is wrong.
Thank you so much for the insightful discussion. And I think that leaders and um users listening to this episode will have a better understanding of what’s coming actually and how you can start um using agentic workflows inside of a B2B setup. So thank you so much for your time uh Frédéric.
Well thank you. Yeah and have a great day.
Before we wrap up, here are four practical takeaways from my conversation with Frédéric Bon. First, we are shifting from workflow-based systems to intent-based systems. Traditional B2B commerce was built around guiding a human through a sequence of steps. Agents don’t work that way. They need to understand what you want to accomplish and figure out the steps themselves. That changes how you expose your APIs, how you name your data fields, and how you design your entire commerce architecture.
Second, data quality is not optional. It is the foundation. If your data is inconsistent, poorly labeled, or scattered across multiple sources with no clear master, your agent will guess. And more guessing means more errors. Clean, well-structured, intelligible data is what separates a useful agent from a dangerous one.
Third, human in the loop is not a marketing phrase. It is a design decision. You need to identify the right moments in your process where a human validates what the agent is doing, especially when real transactions are on the line. The good news is that in B2B, many of those checkpoints already exist. You just need to wire the agent into them properly.
Fourth and last, agent to agent commerce is coming and we need to start asking the hard questions now. Who is liable when an agent makes a bad decision? How do contracts form between autonomous systems? These questions do not have full answers yet. But the organizations that start thinking about them today will be far better prepared when the technology catches up.
If you found this episode useful, please subscribe to Mastering AI with the Experts wherever you’re listening to me and check out my newsletter, Mastering AI for Productivity, for more insights like these. See you.