The Death of the Workflow: What Agentic B2B Commerce Really Looks Like

Frédéric Bélanger
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 it 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.
Samuel
Today's guest is Frédéric Bélanger, leader of the AI Innovation Team in the Microsoft Business Unit at Talan, where he focuses on agent transformation, specifically around Microsoft Dynamics 365 and B2B commerce. Frédéric has spent years architecting business-to-business commerce and procurement systems, so 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 end-to-end agent-driven buying, what it takes to make your data and systems agent-ready, and how to deploy AI agents in enterprise environments safely. No theory, no slideware, just real architecture questions and hard lessons. Now, let's dive in. Hello, Frédéric. Welcome to the show. Really happy to have you on today. I know you've spent a lot of time in the trenches, architecting business-to-business commerce and procurement systems. So I'd 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 end-to-end agent-driven buying and what it really takes to make AI agents safe and deployable in enterprise. Before we jump in, can you please quickly introduce yourself and maybe tell us a bit about what you do at Talan right now?
Frédéric Bélanger
Well, thank you for having me. So my name is Frédéric. I am the leader of the AI and Innovation Team in our Microsoft Business Unit. So I work in empowering both our internal team and our customers in taking this agentic transformation, specifically around the business application solutions of Microsoft Dynamics 365.
Samuel
Let me start with the first question, or what I've noticed personally, is that in our personal lives, buying has become almost invisible in the sense that you can now buy from the click of a button. When you're trying to make a decision about what you'll buy, it might be a product or a service, you can now ask an LLM. It's very low friction. But at work, we're still navigating portals, re-entering data, often for things that we've ordered every month. And as someone who architected these systems, why is buying at work still this painful? And is this fundamentally a technology problem, or is it an incentive problem?
Frédéric Bélanger
The first thing to say about this is there has been a trend for the past few years, probably decade, where the B2B experiences in the commerce space are trying to mimic the B2C experiences. We've seen customers wanting to get the same type of experiences, which is not exactly always possible, but still the concept or the overall ease of use 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 are multiple reasons for that. One of them is because it just makes sense to make life easier for people, but also because, as we evolve, as we grow, more younger people come to be buyers or to work in these companies, and they expect more in general of the technology. And we hear a lot of clients say that we can do this in technology, but then your technology cannot do that. These types of things make it that the need of having experiences that are more B2C-like 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 functionality, right? You still do the same as the B2C commerce. You have 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 client. So that's why there's commerce engines 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 good experience and everything, but that is a bit more complex to tailor. And really there's the concept of cost in your 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. And that's what makes it, in the context of buying in the B2B space, that buyers have to 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 that's what makes it a bit more complex. Even if all of the portals were B2C-like with a lot of frictionless experience, you would still experience some friction by having to communicate with all of the different portals in the market.
Samuel
And you've mentioned that people have already been working with systems for years, if it's not been decades in some cases. If you look at most of the business-to-business e-commerce platforms today, what core architectural assumptions were they built on at that time that AI is now completely invalidating?
Frédéric Bélanger
B2B commerce right now assumes that there is a UI with a human behind it that clicks. We used to spend so much effort and so many dollars in having the right experience, UX. There used to be a whole industry, and that still exists, right, to kind of make this work. And at the core of it, it was to place the human behind the clicks, right? So it was 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 without the agent transformation is to take the user by the hand and do it step by step with them, guiding them through. You come on the website, 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 your user will evolve throughout their experience. So you pre-build an experience in a workflow. It's not based on intent. It's based on what I want you to do at what step, based on the general intent or general, I want to buy something, but it's not based on what the user wants to do or the moment they want to do it, right? So we're shifting from more sequence and workflow type of experience to more intent type of experience. And we can see some examples like the catalog, so just browsing products. Browsing products in today's portals or today's reality is really, really crafted so that you can find the exact, you can drill down your search to the exact product that you want to do, and I guide you through this to get the exact right product. Now, if you have an agent on top of it that does it for you, that does the reasoning for you, it will communicate with those systems differently. It will communicate with the intent in mind and not just the step by step. So that brings how your commerce engine will work, instead of providing 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 and are intent-based.
Samuel
So the user won't have to care anymore about the workflow itself or what it does have access to or not, because it will all be managed by the agent that will understand the intent of the user and act on it.
Frédéric Bélanger
Correct. And the reason there's a workflow right now is for removing friction, right? You don't have to input your shipping address before you actually need to buy, which in the user checkout, that's today's mindset: I'm not even going to ask for anything about it unless I really need this information or when I need this information in the flow, to kind of funnel the user and push it through. But if you work more than 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 this agent will communicate with my commerce engine to complete or to execute the actions based off what I want to do.
Samuel
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 giving 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 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... I'm saying old, but that's what we're doing.
Frédéric Bélanger
Soon to be old.
Samuel
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. We won't face those boundaries that were forced by those systems, by the interface itself. So before we get into the architecture of it, can you walk me through a concrete example? For instance, someone will go into an agent and type something like, get me what we ordered last quarter, but I need it faster, into an AI interface. So it won't be the standard UI. We'll go to a chatbot, and Copilot, for instance, will type it in. It's connected to a third-party vendor. What does the system 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?
Frédéric Bélanger
So with the intent being the start of the conversation, it shifts from 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 it. So usually it's landing on websites, but then you get all of that, how do you land on websites to start your experience there. So right now, or with the intent, agent, there is no start. You start wherever the user wants to start. 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 that means is that the agent needs to analyze what you're asking for and make sense of the different actions or different things to do in order to complete 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, faster, just the word get me, we have to understand, the agent has to understand if the intent is to fetch some information, see what I bought, but not really buy it, or if I want to rebuy again, right? So get me what we ordered, what we ordered means order history. So okay, I need to go back to the order history, find the related information based on the context that I'm providing to complete this action. Last quarter is our time frame. So the system will go, OK, I need to find information about order history for that time frame. And then the faster, or I don't know how you put it, but something around delivering. I guess in your example, it's the most interesting part is what does faster mean in this context, right? For you and for me, it might be different, right? So by seeing that, am I asking the system to buy or to view what products? Is that the exact same product 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 faster or get in two weeks earlier, maybe I want to suggest to you this instead of the one I already bought. And then I need to do that. I need to understand the concept of delivery time and shipping time and everything that is usually available. But the agent will analyze all of these little pieces and kind of break that down into different actions to do and will then 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? You go back in the system, find the information about products, return this information and use it to generate the next step. And then, I need faster. Okay, maybe I need to find another SKU or another product somewhere, but what's faster? Faster is about delivery time. Okay, so need to find 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 at this point is when I say, I understand this because of my intent, understood. Here's what I suggest we do next. Understanding the intent is kind of at the core of what LLM does or the agent does. It's kind of why we're using them. And then it's orchestrated with the different actions you can execute to actually do what it's supposed to do. But in order to support that, right now, if we use our system as is, it will work. But our systems, the way we traditionally used to interface with them was meant for, again, that workflow type, step one, step two, step three, where it's not about what I want to do, it's about what I am actually doing. So we'll need to expand 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 an order history, right? The easiest one or the classic one, if today you were to build an interface within your system, is you would just go and get all the order history and then search through it. That might get complex if you do that in agent, because every time someone asks a question about order history, you would do these types of things. 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 orders through what you bought by SKU, by date, by type of products, by family, by products, 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 to get me all of my orders to you with pagination, we're moving from this to I need to provide intent-based APIs where I can search through by SKU or I can search by time or I can search by order number or whatever the search is. So you're providing and you're changing level. The core itself, the commerce engine itself, the way it works and the business processes that there is in there doesn't really change. It's how you expose it. You give more options and a broader catalog of things that you can do, or you can interact with the system instead of being the classic API that we know. You just, you have one for each and that's it. And the famous CRUD operations type of API, 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 concept of data. Data is really important with agents. It's been important for a while, right? It hasn't changed, but it's even more crucial now. 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 the concept. It can even look online to get definitions. But if your system gives you, when action uses the name, so I'm not even at the content of the data, how you structure it in the name of the fields and what it returns as an API. If the field name is different across different actions, you just will not perform in a perfect way because it's going to be a bit lost in all of these different terms. So you have to have good data, good structured data, but that works well in an unstructured way. And again, if you don't implement those changes, 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 changes happening or those different ways of communicating. And the data again is really at the core of everything in the way it's structured. Even like database fields, if you ever have a system or an agent that communicates and gets, for whatever reason, some of the raw table names and column names, all of that is used by the LLM to understand what it is. So if you use smaller, shorter names with layers that are removed and acronyms, it's going to be harder for the LLM 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, but if it's a clever name or intelligible name, I will be able to understand what it is. So all of these little things that we didn't care about, the table names before, well, now we do. We didn't care about the answer of an API field 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. All of these little things have an impact on being able to execute the intent better and also in a sense understand the intent better, because if there are multiple steps to understand the intent that require some of the data, the data is important to get the right thing. And if in the prompt you talk about products, for instance, and then nowhere in none of your APIs, none of your 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.
Samuel
So if I summarize, your agents need to understand the intent based on your use case, based on your industry and 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. The example I used was purposely vague because that's what I'm expecting an end user to ask. And it's important, I think, for our organization 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, a description of your action, I will suppose, if we're talking about autonomous or generative orchestrations. If the underlying data is not good, the output won't be good. So those are the three main pillars of building or architecting an agent, right?
Frédéric Bélanger
Yeah, exactly. And the intent is probably the one that's the hardest to understand because we're so drilled about the workflow and feature type of thing. And then I want to do this. What's the workflow? I'm going to go if then else. We're drilled for that, especially in the implementation and the consulting world and everyone that works in technology anyways. We've been doing this for how many years, many decades now, right? So the concept of intent, I can create an intent to an agent in this case and I have what I want to do done with that, is complex. But when you give intent, when you 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. You have to kind of guide the agent to better understand the intent. So the context, what you're trying to do, that's why agents are really contextual. You really build up for something specific. It's never really just really at large, but otherwise the intent understanding will not be as good as it could if it was more precise.
Samuel
Building on what you said about action, 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 action it can accomplish. What's the hardest integration problem that you run into? Because not the slideware version of it, the real one, because I know that marketing teams out there have been very good at showcasing products like it's a two, three clicks process to put an agent in place, but 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?
Frédéric Bélanger
Technically, there's the social portion of it, which is adoption, is for now too in every question and every change. But on a more concrete integration, real work answer, obviously it's the data in every sense of what data means. Data is king. If you don't have the right data, if you don't have the right consistency, you're going to get some integration, but not some good integration. So integrating with systems, as long as they're not too old, it's kind of not that complex, but getting an integration to be meaningful is I think where it's 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, what's the business process? And the answer is, it's in the head of this person. That's kind of where it's a bit more complex to, okay, well, how can the agent use the data efficiently if the process around it is not really known? It's kind of impossible for another system, like it would be for another human, to understand it if you don't know exactly how it works. But other example, like multiple sources of data, usually you don't get one. Now in the modern architecture, you try to centralize the data to have MDMs and stuff, but most of the time 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 the ideal state for consuming by an agent is probably the hardest part of the integration. And then, like I said, there's also like if the system is a bit older or there's no ability to connect. Usually that's not too much of an issue because if you get any APIs or anything that are more on 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 the integration methods are being thought of by or for agents, right? For the reason I was explaining, right? Because now your way of doing the system and communicating 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. So it's going to be a bit easier if you have all of that in place. But in terms of integration itself, it's pretty straightforward to connect systems together. It's what it does, the power of it, of the output, that's important, right? Just connecting is easy, but having a connection that's useful, that's the most complex thing, and it relates to data and availability of connectivity.
Samuel
Not thinking of old systems, but for newest systems, do you think MCP servers might be a solution to that, like facilitating integration?
Frédéric Bélanger
Yeah, well, MCP in the end is a protocol, right? It's just, hey, we need a structured way to have agents being able to call, in a sense, APIs. The way I explain MCP usually to my clients is see MCP as APIs. It is not exactly the same thing. It's a simplification for sure, but it's a way that we can see it. The 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 servers if they already have some 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 connectivity. But MCP or other, because there might be other in the future, other protocol in the future that arises. But I think it's a path to have created a protocol standard basically that we can use across any technology or any platforms that use agents, and that for sure is actually right now helping agents build better because it's kind of impossible to create your own connectivity. It really streamlines this connecting part. That's what I'm saying earlier. Integration is not the hardest part. You have to have relevant actions in those MCP servers, the 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 just a way to expose to the agent, hey, here's what you can do with me. You can add to cart, you can search by keyword, you can search by SKU, and then you can log in. What do you want to do? And then the agent chooses what actions to execute based on the intent of the user. So it's really like an easier way to expose intent-based actions to agents, no matter the technology you're using.
Samuel
You've mentioned the data. Obviously that's the foundation of everything when it comes to AI in general. So if a client reached out to you and he's ready to go all in 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?
Frédéric Bélanger
It's a good question. I don't believe it's either-or situation. You might have 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? But in a simpler way, it's not a good AI case, or it's more of a data architecture problem, 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 it goes in some kind of black box type of thing and you don't really know what happens, just compute a price, then you have data architecture problem because if no one knows how to make sense of the data, the agent won't make sense either. So it's really like the simplest way just to put it. However, on the other end, if you do know how to compute it, it's just really, really complex, takes some time, tedious, errors, that's where AI can come in, right? The output might be the same as you get wrong prices on both. But one is because you have a data architecture problem and one could be solved by AI, could be pretty helped by AI. So AI is really good at understanding complex things or pinpointing in a big lake of information what's the right thing that's needed to complete an action, being able to kind of, if that process is slow and tedious and is prone to error, that's kind of three things that tick the boxes to, that's a good AI opportunity. And in a sense, you can also look at from a decision perspective or reasoning. Reasoning is a big word that we're using with agents. We want agents to reason and give us the reason. If you can say that if you could reason in some use cases, but you're not able to make a decision, that's where you get the data problem. In other words, if you were able to make a decision, but the decision made is often wrong, you get an AI case.
Samuel
Okay, that's a really good framework. I think there's a big, big difference in retrieving data, asking a question about your pricing, your cost, and then a human being is using it to answer the customer directly, for instance, and having an agent that executes transactions against your live pricing contracts and whole fulfillment logic that will affect 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 stories of agents taking very bad decisions. How do you prevent that?
Frédéric Bélanger
The good question is probably the question that is the most asked by all our clients overall. This is kind of the big question that people are like, this is really great technology. This looks really, really great, but it also looks a bit scary. When I say that agents are non-deterministic, usually that's the point where everyone kind of says, 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 what we need to kind of work on, but also work on the safe portion of it, right? It has to be safe. And I'm not sure if safe is the right word. Maybe guarded is a better word or something. But it comes down to the architecture and how we implement the agent, what decision 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. 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. You have to guide them in a sense. But just that is not enough because we've seen all of the cases and the stories of people being able to go around the instruction of an agent because you can trick them. They're better at not being tricked right now, but it's still possible. And I'm sure we're going to see more cases in the future. So you need, in the sense how you built it, not just an instruction, but everything that goes around the agent. So obviously you get controls and you need to have control systems in your environment. Same way you do for the laptops or all your employees, right? You have systems to control them. We have the same thing for agents, right? You don't want to have the chaos and the free-for-all 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. And these are going to evolve. They're going to evolve in a sense where it's going to help larger organizations to manage larger agents. But there's two concepts that are important. The first one relates to something we already discussed, the data. And we're never going to say enough. The better data you get, the better output you get. That goes with safety as well. 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. So this is also really important to have the right data in order to minimize the guessing and make sure that your intent and how to answer it is in part what you want it to do. And with the data, in 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, not the right one, is going to make a bad decision because it didn't have the right data. The second thing that's really important, and I think it drives more of how we design it, and by design I mean how you place the agent in ecosystem and how you operate it, is the concept of human in the loop. That's a concept that's really important, something that we place first on everything that we do, 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. It feels not too tangible. But when you think about it, it's something tangible actually. It's just a concept of saying, keep the human in the loop. Keep the human part at every step. Every time you have a change of feeling, have a human validate, have a human be there, have a human guiding and taking the hand of the agents and make sure that they don't do something stupid. There are things that have less risks, 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 customer wanted to buy with the prices that they provided is the right one. So it's already in the mechanics 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 you don't get bad results or 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, can tell them I want this and that, and they can put it wrong in the system and then you'll have to manage it and you'll have to say, I didn't receive the right thing. Oh, because you didn't order the right thing. Well, who did what? What's the problem? Can I ship it back? All of that. Rolling back, it's going to be the same idea, I think, as what we do today, more manual processes and everything. But the goal is to lower this to the minimum by adding the right guardrails around the experiences.
Samuel
And if we push this forward in a world of agent-to-agent commerce, and not looking for the optimistic answer, what still has to be solved? 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 still needs to be done?
Frédéric Bélanger
I kind of want to say everything, but that wouldn't be a complete answer. No, there's a lot of work still to do. So you're referring to agent to agent. That's the concept of we've been talking about agent in the B2B commerce world, where a user initiates a request: buy me this, buy me that, or where's my order, 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 human that communicates with agents, right? You can have another agent. I can have, to relate to the beginning 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 have their own agent, I could create my own agent that communicates with all of the agents differently and kind of be streamlining this process of communication with my vendor. If I want to shop across multiple vendors, then I can. Then I'll have to log into every portal to get, is there inventory for this product? I want to look for the one that's faster to get to my clients. I can look for multiple vendors at once because I have an agent that connects with other agents. And then that opens so many questions. How does that work? Non-deterministic agent on one side that talks to a non-deterministic agent on the other side. You might add all 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 talk to each other, and what if it fails? What happens if an order has not been placed correctly? Who's responsible? And that's true not just for agent to agent, right? When agents will make mistakes, like big mistakes, who is responsible? Who is liable for it, right? How do you fix that? My view on it is it's still early because people are still trying to figure out how to use this agent in these types of scenarios. It's still not too advanced. It's getting there, 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, the contracts that you have with your vendor will include some kind of liability, maybe insurances, services that's going to be added. We have liability insurances for everything. Why not agents? You know what I mean? So this is something that's going to, in the future, evolve and be determined, I think. Yeah, and then the next step after that is if you have an agent that negotiates.
Samuel
So we're at this stage right now, right? Now it's human interacting with agents and then the next step will be, so we'll figure out when we're at that point.
Frédéric Bélanger
But I think it's important to ask the questions now though. It's important to understand that these are risks and these are things that need to be discussed 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 start small, we start with what we have right now, but we have to foresee what's in the future. We have to implement it with the future in mind, where one day it's going to be that. And one day is not five years from now. One day is a few months from now, or maybe a year, maybe two. No one knows. But this is coming soon. So we're implementing it with a concrete mindset, but we also keep in mind. So these questions are important to ask.
Samuel
Yeah, agreed. Our CEO of AI, Mustafa Suleyman, just posted, I think last week, that he expects in the next 12 to 18 months 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.
Frédéric Bélanger
What's important to note is AI by itself, not LLMs and agents, has been there for a while now. And we've already kind of started some transition around using AI technologies. So self-driving cars is an example. I'm not sure we even fixed it right now, but these are the same exact questions that we were asking for when we saw the first, or the car sharing of this world, applications. 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 important to talk.
Samuel
We're almost at the end of our time. 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?
Frédéric Bélanger
Yeah, it's about the prompt, right? Right now, everything's about the prompt. I'm 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 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 what we're used to about search engines, keyword searching. We're used to Google and Bing and going online. I remember when I first started using search engines, we had to learn what the plus is and the quotes and everything to kind of refine your search. But it's, we use the keywords that you think is going to be the most present. Well, it's intent-based now. It's not keyword-based. So we have to provide context and constraints. The way I see it is you have to see the agent as an intern or as a junior 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 the situation. Here's what matters. Here's your goal. Agents are already goal-driven. You have to tell them when their job is done. And here's what I'd like you to do. So you have to give more things instead of just saying, search for this. So it's really like looking at the prompt as if it was an intern or another human being and explaining all the concepts and the constraints, I think, is a good tip.
Samuel
Love it. Actually, exactly what I'm teaching my customers and when I'm giving training. I have a full video of it on my YouTube channel. So love your answer. I totally agree. If you look 10 years ahead, how do you think AI will reshape the way we transact, we live, work?
Frédéric Bélanger
You can ask six months from now and I don't even know, so.
Samuel
I'm asking a question.
Frédéric Bélanger
I know, and I've watched some of your videos and I kind of knew this question was coming. Ten years from now 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. 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 natural language, talking to them either by text or voice. But that's kind of the only way they can communicate directly. In some scenarios, we've put so much effort in UX in the context of today's discussion about portals and B2B portals and everything and even B2C websites. We've put so much effort in being better at communicating with having the experience and more frictionless experience and all of that to communicate with other systems. And now we're back to only text. So something around that does not make too much sense to me. This is going to evolve. But as part of it, we can also foresee that agents are not just in our phones, in your laptop, could be everywhere. It could be your car, it could be your house. And what technology have we worked on in the past few decades that now is really, really good? Robots, right? So what happens when you put agents inside robots? And I like to kind of play the game and see, what could it be? Humans are good at creating industries and stuff. How will we make money out of it? So sometimes I think of what's going to be in the next few years where we might all have our own robots in our house and say you need a plumber. Well, you go back to the vendors of your robot and you buy the plumbing package, let's say for two hours, and then it fixes your problem. And then you monetize knowledge and monetize intelligence.
Samuel
If you listen to Elon Musk, it's for the next year, I think 2027, that every household will have.
Frédéric Bélanger
Yeah, Elon Musk is really optimistic on the timeframe, but I don't think he's been that wrong yet. So some people say it's a bit like maybe three to five years. Let's say two years. Superintelligence is something that's some day, which is on the way. Obviously not in 10 years, like in 10 years, we're going to be used to using this technology and then society will be different, right? If you have robots to do plumbing, you don't have plumbers anymore. So all of these jobs in your society, there's a new old 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 a society. We're going to invent something new, something that we didn't even think can exist. Like we don't even think it now. Ask a hundred years ago if you had an industry of IT and do this later. They didn't know 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 what's exciting me is, like, I'm really eager to see what's the future because no one absolutely knows where it's.
Samuel
I love your last point about where we'll 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 would never imagine that prompt engineer would be a skill at all. It might be not necessarily needed in a close future, but still something else will come from it.
Frédéric Bélanger
But in 10 years, it will be, some way or somehow. Even communicating with agents through senses. Touching, eyes, I don't know.
Samuel
Maybe not.
Frédéric Bélanger
I like to play that game of trying to see what it could be and then not bet too much money on it because I'm pretty sure everyone is wrong.
Samuel
Thank you so much for the insightful discussion. I think that the leaders and users listening to this episode will have a better understanding on what's coming actually and how you can start using agentic workflows inside of a B2C setup, B2B setup. Well, thank you so much for your time, Frédéric, and have a great day. Before we wrap up, here are four practical takeaways from my conversation with Frédéric Bélanger. First, we are shifting from.
Frédéric Bélanger
Well, thank you.
Samuel
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 to them properly. Fourth and last, agent-to-agent commerce is coming and we need to start asking the hard question now. Who's 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 ya.