Dynamics Corner
About Dynamics Corner Podcast "Unraveling the World of Microsoft Dynamics 365 and Beyond" Welcome to the Dynamics Corner Podcast, where we explore the fascinating world of Microsoft Dynamics 365 Business Central and related technologies. Co-hosted by industry veterans Kris Ruyeras and Brad Prendergast, this engaging podcast keeps you updated on the latest trends, innovations, and best practices in the Microsoft Dynamics 365 ecosystem. We dive deep into various topics in each episode, including Microsoft Dynamics 365 Business Central, Power Platform, Azure, and more. Our conversations aim to provide valuable insights, practical tips, and expert advice to help users of businesses of all sizes unlock their full potential through the power of technology. The podcast features in-depth discussions, interviews with thought leaders, real-world case studies, and helpful tips and tricks, providing a unique blend of perspectives and experiences. Join us on this exciting journey as we uncover the secrets to digital transformation, operational efficiency, and seamless system integration with Microsoft Dynamics 365 and beyond. Whether you're a business owner, IT professional, consultant, or just curious about the Microsoft Dynamics 365 world, the Dynamics Corner Podcast is the perfect platform to stay informed and inspired.
Dynamics Corner
Episode 422: The Future of AI in Business Central: Balancing between Automation and Human Oversight
In this episode of the Dynamics Corner Podcast, Kris and Brad speak with Søren Friis Alexandersen to discuss the Payables Agent in Microsoft Dynamics 365 Business Central and its role in automating invoice processing. They emphasize the importance of human oversight in AI decision-making and address the challenges of building trust in AI systems. The conversation underscores the importance of clear documentation to ensure effective policy implementation. By leveraging historical data and balancing coding with natural language, they outline how AI can enhance compliance and accounting practices. Additionally, they explore the importance of experimentation and contextual awareness to improve the effectiveness of AI agents. Ultimately, they argue that the future lies in the thoughtful integration of AI while ensuring that humans remain involved for accountability and transparency.
#MSDyn365BC #BusinessCentral #BC #DynamicsCorner
Follow Kris and Brad for more content:
https://matalino.io/bio
https://bprendergast.bio.link/
Welcome to another episode of Dynamics Corner Agentic, trying to figure that out what it means to you. I'm your co-host, chris.
Speaker 2:And this is Brad. This episode was recorded on April 23rd 2025. Chris, Chris, Chris, I liked to hear you play the, what you call the ukulele. I call it ukulele.
Speaker 2:Ukulele. It doesn't matter, it doesn't matter, it doesn't matter. I've always wanted to hear you play. I know you have it, you play it, so we have to figure out. One of these times I want you to maybe get a secondary mic or something so you can play it and hear it too. But you mentioned agents. There's a lot of agents in this world. There's travel agents, there's sales agents, there's even AI agents. I'm not certain if you've heard of them, but today we did have the opportunity to talk a lot about the payables agents within Business Central and what goes behind it, what its features and intended would be With us. Today we had the opportunity to speak with. Good afternoon sir. How are you doing? Hello, nice to see you again.
Speaker 3:Good afternoon, good morning. Good morning Is sound coming through, okay.
Speaker 2:The sound is coming through amazingly well. That sounds amazing. And I'm always fascinated by your backgrounds is coming through amazingly well. That sounds amazing, and I'm always fascinated by your backgrounds with the guitars as well. Well, you gotta play with uh, play on every string you got right Like yeah you know, with so much going on, I always, I often wish that I played an instrument, but I don't have, or I don't want to say that I don't have the time, because time is what you choose to do with it, in my opinion.
Speaker 1:So it's you can still prioritize other things over.
Speaker 2:I want to play the piano or something.
Speaker 1:I think piano.
Speaker 2:I really enjoy piano music. When my daughter was growing up, she played piano and we had a piano in the house and that is probably the one thing that could occur that didn't annoy me. Oh, one of the one things that occurred that couldn't annoy me. Annoy me because she could play at any time and just hearing the piano music is soothing.
Speaker 1:And I contemplated just See, right, you got to do like a string instrument, then you could just learn four chords and then you can probably play quite a bit.
Speaker 2:I think I'm scarred because when I was a young boy I tried to learn to play the viola and I am left handed and back when I was young they didn't have a lot of left handed devices for anything, for sports, for instruments. The instruction didn't go too well because they were trying to teach me to play right-handed when I was holding it left-handed, so the viola was upside down in a sense, so it just didn't work out too well.
Speaker 3:If I could switch one instrument. I've often thought if I could choose any other instrument and be equally good at that instrument just by clicking a switch and trade off the guitar or something else, I'd go for the saxophone. I don't know Something in the saxophone, that's just amazing. Play some blues. Yeah, it's always amazing. I'm not complaining, I'm not.
Speaker 2:No, it's this. I'm finding more. I don't know if you get to a certain point. There's so much available to do in life and I want to do it all and it's very difficult to choose. Where do I focus my time so that I can get the enjoyment enjoyment even though I'd like to do everything I need to hang my stuff because I have them right.
Speaker 1:Oh wow, I got my ukuleles. I got a bunch of them right on the floor and I should be getting them off the floor well, maybe we could have you do a jam out session, chris, before we we finish.
Speaker 2:Uh yeah, the conversation. How are things going in denmark? The weather must be breaking garden getting ready yes, uh, amazing garden days.
Speaker 3:Today, a few days ago had a bit of rain. So april is always. April is always, uh, a bit of everything. I mean you can ever everything from almost summer like, and then you can have everything from almost summer-like, and then you can have almost winter-like some days. In a few weeks it'll be more stable, but today, which happens to be my birthday, happy birthday.
Speaker 2:Happy birthday. It will be a little bit delayed when we play this, but happy birthday.
Speaker 1:I hope that you have a great day to get to celebrate and enjoy.
Speaker 2:Yes, I was thinking of you. The other day I went to what I call the farm store and I'm toying with chickens again. No, a real farm like a farm supply store and we're a little bit late for where I am right now for chicks. But I was looking to see about getting chicks again because I had chickens for a long period of time. But I was thinking of you with the farming and how chickens would be great in your backyard there.
Speaker 3:I would love to and we definitely want to Maybe not this year, but I'm thinking next year we'll do it and see how it goes.
Speaker 2:Oh, that's excellent. That's one. That's probably one of the things that I can point back in my life that I say I enjoyed the most was when I had the chicken, so I think you'll enjoy it. It's, um, and I even raised some uh the chickens uh fertilize the rooster fertilized, uh, some of the eggs and one of the chickens decided to sit on them, so I was able to raise chicks, a a few chicks, which was interesting to watch, but I don't think we got together to talk about farming. We'll save that for another conversation.
Speaker 2:But before we jump into the conversation, would you mind telling us a little bit about yourself?
Speaker 3:Yeah, so great to speak to you guys again. So my name is Soren, I'm a product manager in the Business Central engineering team and the resource development team, if you will, based out of Copenhagen, denmark, or just north of Copenhagen, a small town called Lingby, and I've been with Microsoft for nine years and some months now, almost all of them minus one and a half years in the Business Central team, almost all of them minus one and a half years in the business team Before that in Microsoft Denmark in the sales organization as an account technology strategist. So I have sort of a broad IT background. I've been in IT the last 28 years, so quite a few ER, you know P systems under my belt started with Concord, xal, c5, then the whole Navision Damguard thing happened and, yeah, through, my first meeting with Nav was with Nav 5, or that was no 4, sorry my introduction. Then I had a few touch points with some early versions, but then everything from Nav 5 and upwards I've been working with end customers.
Speaker 3:I was self-employed, had a small partner business before joining Microsoft where I was sort of 80% engineer, 20% everything else. As you are, you're self-employed. Oh yeah, yes, speaking of time to do everything, mostly doing back then when I was self-employed, mostly doing web services integration from NAV to and from something else on the other side, joined Microsoft part of the sales organization one and a half years and then, yeah, eight years now-ish in the BC team, first doing localizations, rolling out BC to many countries and then switching to some onboarding five years ago now and did that until almost a year ago and then since about a year ago, everything now says AI, so taking over the finance area of BC since last fall and working on the payables agent.
Speaker 2:The payables agent. That opens up a whole conversation for me. With the payables agent we were all at directions. We had the opportunity to speak, we saw the keynote presentations on the sales order agent and there were other discussions on the agents and you also had a session on the payables agent. If you would, before I jump into it, I remember some of those names. Over at Microsoft, do they have a shrine to all the old versions of Navision where you go back from Navision 1? Like an install kit or something on the wall where you have all of the installed media?
Speaker 3:I don't know. We have the physical media like the DVDs and stuff and discs, but we probably have all the artifacts on some shared drive somewhere. But you could say that so many people in the BC team have been here for so long that the shrine is sort of made up of real people that have just been with the team since back in the day, right. So we have people who have been with the team like plus 20 years, like who remember you know stuff way back from the you know terminal-based client, even stuff like that. I mean, you'd be amazed, yeah.
Speaker 2:No, definitely it's amazing and as you're talking through it, it just it's, it's. It spans quite a bit of time, but it doesn't feel like a long time. It feels like a lot of this was just yesterday it's.
Speaker 3:I just had that discussion. It does feel like yesterday and it does. It's also amazing that you can like imagine bc now running in the cloud in this super complex infrastructure and services, global scale, hyperscale cloud, on a system that was, or at least inherited from a system that was basically built like 30, 40 years ago almost, but at least from a functionality perspective there's still remnants from that time and it just goes to show that some business processes don't change that much. Like core finance is still sort of core finance to a large degree. Of course there's some stuff you want to do and stuff you want to improve in your businesses, but to the core, we've been moving products around like as businesses more, or to the core, we've been moving products around like as businesses more or less the same way, uh, for the last I don't know many decades. Uh, it is, and I think that when I think a gl.
Speaker 2:when I think a gl entry, sales and receivable setup, purchase and payable setup, inventory setup, posting groups, like a lot of that stuff has been there, to me it feels like the beginning, but I can't wait to speak to you. We'll walk down memory lane the next time we have a conversation. The Pables agent, if you would. The whole world is talking about agents every day. I don't think I can go without shutting everything off. I don't think in the world that you can go an hour without hearing about something AI or agent related and the payables agents you have been working with. Would you mind telling us a little bit about the payables agent?
Speaker 3:Yeah, no sure. So, speaking of things that haven't changed in decades, companies have received invoices from vendors, like since you know or like all the time, and that process, like receiving and processing vendor invoices, has always been sort of prone to automation. We've been, you know, companies have been trying to automate that for decades, all the way back to the 60s with EDI started and, you know, as internet connectivity got better and various ways to get data into systems, out of systems, improved integrations, access points, what have you. So there's been sort of a push to automate that process for many decades, but it's always hit a roadblock when it hit that last thing where now someone needs to actually process this invoice and recognize what it is. It's been very mechanical and if you received an invoice that was based on, you had mapped up some of the information or the invoice to your GL accounts or to your items or things of that nature. Of course you've had OCR, optical character recognition, for quite some time, but still that helped you with getting the data into a sort of machine-readable format. But after that, what was actually on the invoice? Like having a system that could recognize. What is this even all about? What is this invoice about, without having to map anything and set anything up.
Speaker 3:That's been the hard thing. That's really where the Payables agent brings something new, which is we believe that not only can the agent get all the data in from your invoices and we'll be starting with normal PDF invoices but the agent will be able to recognize, from an accounting perspective, what's going on on the invoice. Is this a subscription that we've prepaid and thereby you need to defer the expense, or is this some other expense that we have? Something that's in our policy that says we need to post a certain way or so all that accounting knowledge, if you will, we imagine the ABLE will be able to acquire and utilize. So basically helping the accounting professional with doing that last mile registration of the invoice, if you will, and in time, also purchase order matching and sort of, in a sort of next phase. But that accounting knowledge piece has been the missing thing, the hard thing to do until now, until now with LLMs, basically. So we think we can make that work. That's what we're trying to do right now as we speak. So we're building the agent right now and focusing first on getting the PDF sourced, so from an email account or from a SharePoint or OneDrive folder where you might want to place your invoices, or from a SharePoint or OneDrive folder where you might want to place your invoices, or from an email account.
Speaker 3:Like a trip scenario. You forward or you get an email with an invoice from a vendor, or an employee forwards an invoice. We import that into what we call e-documents in BC and then the agent takes over and starts looking at the invoice and sees, based on a handful of different ways of processing this invoice, it tries to look at how did we previously handle this invoice? What does my purchase history say in terms of how to post it, how to register it, basically how to code up the lines for the invoices? Do we have a policy in place? Maybe you have a Word document, pdf document, that describes your accounting policy. When we post rent for the warehouse, how should that line look like? Is there a certain dimension that should be added? If you buy software licenses, does that need an allocation account to be split up against, you know, based on multiple deal accounts or dimensions or things of that nature. All of these things we're trying to look at in sort of combination and figure out sort of what is the best predictor for how should this invoice be handled. So that's really the idea and hopefully that will work out so smooth that you can be basically hands-off.
Speaker 3:Of course there'll be some corner cases that are that are hard for the agent to sort of say. You know, for example, let's say you've been doing it a certain way, posting rent for the warehouse a certain way for the last 10 months, but now suddenly last month you did it differently. Now what's the right answer? Is it what you did last month or does the 10 preceding months weigh more heavily? And so probably that's a human-in-the-loop moment where you want to say okay and you know. So probably that's a human in the loop moment where you want to say okay, the agent can't do a confident enough, uh, can't see confidence enough decision, so probably we need to involve a human. So human in the loop is a sort of a core concept. Um, and everything that is agents, it's built around human intervention, if you it is.
Speaker 2:I think of this when I hear the agents and get more familiar with agents.
Speaker 2:It's not just.
Speaker 2:It seems like it's the agentification I always stumble when I say that Agentification of the world, because everyone talks about agents to do specific tasks and listening to your explanation, it almost you start to equate to how people work in a sense, because if you have an agent that's responsible for receiving an invoice, taking that invoice or a document invoice of some sort, taking that invoice and then creating a purchase invoice within Business Central and then processing it according to some rules, you're in a scenario where, well, now we have a difference.
Speaker 2:What do we happen in a difference? It could even be the same case when you have a person doing that same or a human doing that same task that they may need to go speak to their supervisor, or they may need to speak to someone else to ensure accuracy of it, or there may be limits that you can put into place. Where you say the human and loop, I'm glad you explained that because that's also another term that I've been hearing quite frequently in conversations, I think more so in the business central community versus outside. But what the human and loop means is, in essence where humans get involved. If I'm'm correct, humans get involved into the operation to validate, confirm or be involved in a process or a transaction.
Speaker 3:Yes, and when it comes to human in the loop, it's it's super important that there's a it's very clear to the user or users or team or company when is an agent expected to do something and when is a human expected to do something. So there needs to be a very clear handoff, if you will, between well, the agent is now running with the ball, but gets stuck, and now it needs to involve a human. So we've designed with the ball but gets stuck, and now it needs to involve a human. So we've designed, as you've maybe seen, we've designed this agent sidecar on the right side, where there's this timeline, but the agent will describe anything that it's done in the process and the end-to-end flow, basically, and then the human will be brought in and will have a task to do if something is uncertain, if the agent cannot continue, or if you've opted in to be in the loop in a certain place. So human in the loop will definitely be like there will be configurable human in the loop moments where you can decide oh, I always want to be in the loop when the vendor is not a good match for what we have in our system, or the bank account doesn't match, or whatever, or there's an anomaly with the amount. It's suddenly twice as high as it used to be, things of that nature. But you want to maybe configure that yourself, or maybe you want to in the beginning to have low autonomy or be brought into the loop more until you feel comfortable with the agent taking some of those decisions by itself, and then you dial up the autonomy as you sort of go forward. But there will also be other human-in-the-loop moments where we will decide well, there will be human-in-the-loop when X happens, for example. That might be if it's sort of more risk situations or where the agent simply cannot just make a decision. And how will the agent know when to make a good decision and I think that's a concept that we're working on is what is that confidence level?
Speaker 3:So, as I mentioned before, let's say you had the purchase history, you had the policy you had. What if the agent suggests something? It suggests a GL account to post this rent for the warehouse, but for some reason the user doesn't agree and changes that to something else. That signal that the user changed it. It's also a signal for the agent to say, aha, my suggestion wasn't good enough. I can remember this scenario next time for this vendor for this specific type of expense.
Speaker 3:Correlate that with what does the policy say? What does the policy say? What does the history say? Are you also using recurring purchase lines? Maybe that's also something that should be taken into account of how to weigh all these things together. So how we weigh these things. That's then maybe the tricky part. Should policy have priority over history, or the other way around? And what about just pure LLM guesswork? So if you don't have any of these things, you don't have any history, you don't have any policy. Just let the LLM guess. Here's my chart of accounts. Which one is the best for posting rent to my warehouse? Probably the agent will have some kind of idea about that, because it does have some basic domain knowledge, if you will.
Speaker 1:I was just going to ask you about that, about the confidence level. You know clearly the human aspect of it, where you're interacting with it and it's interacting with your business. When do you have the authority? Or maybe changing that confidence is like okay, well, I'm not. You know, it tells me that it's 99% confident or 90% confident. Maybe I'm not, I'm not confident enough for that to just make a decision. Do you have control over that? I think that becomes a uh, maybe, a need, uh from a business aspect, like uh, maybe, maybe, when it maybe, when it's only 90%, I don't want it to do anything, I want it to ask me, right?
Speaker 3:That's an excellent question, Chris, and I think I totally agree, and that control first starts with transparency. So what we're looking at first is to so normally, a purchase invoice. So right now, what we do with these invoices we take them in and we create purchase invoice. So right now, what we do with these invoices we take them in and we create purchase invoice documents from the MNPC, and later we'll do PO matching and so on. But and right now a purchase order sort of a purchase invoice document is. You could say it's already a kind of a draft because it's not posted yet, but we needed a stage before that, a sort of a draft stage before that, before it becomes a purchase invoice, because someone might stumble upon it and wouldn't know if this invoice is ready for whatever the next step is. So we introduced a new purchase document draft stage, if you will, where we create the invoice based on all the information we have, as we talked about before, all the input and signals to how do we think this invoice should look like as a draft and there the user would look at it, and here we plan to incorporate some UI that says oh, we suggested this GL account because you have this in your policy. Or we suggested this yield account because that's the most frequently used for this type of expense on this vendor. So similar to what you see with. You've seen the new auto fill feature where it explains, with small icons beside fields, why was this predicted. Imagine the same thing happening here for all of the information on invoice. You could say, oh, it suggested this because it came from our policy document and it's to some degree certain about that.
Speaker 3:Of course, when it comes to actual percentages, that's going to be the tricky part. We need to figure out how do we like if something comes from a policy, are we then 95% certain or are we 85% certain? That's something we'll have to experiment with and build out some models for certainty or confidence. That is not an easy feat, so that's something we'll need to figure out. But we'll need to start with at least explaining to the user why these suggestions. Why does this invoice look like this on as detailed as level as possible, and then you can take a decision on great, that's fine. You might also be able to say in your configuration of the agent that the policy should have preference over history, for example, because you might have done a certain thing for posting rent the last 12 months, but now it's new fiscal year, Now you change your policy for some reason. So now it shouldn't rely on history, it shouldn't be the predominant signal. So we imagine you can sort of configure the hierarchy of how much should they weigh these factors. So it's not yeah, it's something we need to get some experimentation done with and get some feedback on.
Speaker 3:We have this private preview program where we want to let you guys and other people you know lose on the agent and try it out and see how does it work, Because you also have some obviously you have a lot of experience with from from from real customer scenarios how these things work. So, uh, so we're super excited and we think we can make this work. Uh, but it's all about trust. You need to be able to trust the agent. Definitely, you want to be able to trust it before you dial up the autonomy, and you also want to be able to trust it before you dial up the autonomy, and you also want to be able to trust it to just use it in the first place, like to get the value from it, and I think that's going to be the.
Speaker 3:So, knowing accountants, of course, you could say well, you've been automating this space for years, but those systems have been more sort of fixed and based on mapping, so you always knew what was going to happen. This is different, and our main challenge is to whenever AI is in place, is to say, however we posted rent for the warehouse yesterday, we need to suggest the same way tomorrow. It needs to be some consistency. We can't live with the normal co-pilot creativity, if you will. That won't do in accounting right. So that's what we're trying to do. We're trying to tame the wild tiger of LLMs here in Incense and get to some consistent results, and that's probably the hardest part of all of this.
Speaker 1:For sure, and I think there's a requirement for businesses to really document quite a bit, because we talk about agents and grounding them to. You know, with with some policies, as you had mentioned and I chuckle internally a little bit because any time that I've done implementations and I know in the past there a lot of businesses don't have actually written policies, right, it's, it's all like tribal knowledge. And so you know, as we go towards the agentic world, I think it's more important now for organizations to really write down and create those documentations or create those policies, so that when these things come out, you want to be able to ground them based upon those documentation, because there's so many tribal knowledge and you know we've all gone through implementations or, like God, that person knows about everything. It's like how come you don't know? Isn't it written? No, they just know. Right, it's tribal knowledge. So I think it's a lot more important now for businesses to really take the time now for businesses to really take the time.
Speaker 2:It is important. It lessens the risk, because the knowledge that you're talking about could be standard knowledge and the policies could be governmental restriction policies that you may have on top of organizational policies. So it's not like you have to draft everything, but you need to have those sources that you can reference, which are handy. And, chris, I completely agree with your point on so many times a lot of policies, a lot of procedures and a lot of why things are done are based upon. Well, chris has been sitting there for 20 years and that's the way that he's always done that and Chris may know the reason. But if somebody else doesn't know it, then when chris leaves for whatever reason, then everyone's stuck figuring out. Either we're going to still do it this way we have no reason why or we may do it a different way.
Speaker 2:I I'm listening to you discuss the agents and trust. Trust becomes a big thing, but I I try to take it back of agents will have a specific task which I I want to talk about where we come up with agents and how we draw the line between agents and use multiple agents with handoffs, and you have to have trust in them, but that same trust just because the agents seem to be doing more, as you said, not in like a fixed automation but in a variable automation because they can do a lot of ad hoc reasoning. I guess you could say Everyone's always had to have trust in systems because, look at, if somebody's going to a new ERP system from a spreadsheet, they have to go through a phase of. I need to trust that. Whatever ERP system that we're using, you know from just my passion, we'll say that everybody's implementing Business Central. There is a sense of trust that they need to have there.
Speaker 2:So I think it's also the messaging of a lot of this that we do. We already do with getting that trust with, as I had mentioned, you have the human in the loop where supervisors may come in and do some checking. And also, chris, to your point of grounding as the agent continues to do more work, it has more information to ground upon, just as if you were to bring on a new talented individual to help you with your payables or purchases for the agent. And the key point to this is the agents are tools to help humans do their job, whatever that job may be, to make it so that they can spend their time elsewhere, maybe in something that's more valuable for them to do, more thought-provoking, where an agent can't do the task, versus some of the repetitive tasks of new purchase invoice vendor number 10,000 or 1000, you know, purchased Athens chair, you know, for one it's. It becomes like that. So.
Speaker 3:No, that's, that's all true. And actually, when it comes to that trust so I'll come back and just speak to the policy part uh, because there are some things I didn't mention but but before I go there, uh, about this trust, you're so right. We, we've already today, placed this trust in the humans, who who do these tasks, and when I I've spoken to a lot of cfos lately and many of them say we, we actually have a hard time finding qualified accountants, finding that qualified talent, like just as humans. So a lot of mistakes are being made in these departments today, but maybe we have higher demands, higher expectations for agents and for AI than we have for humans, or at least we're not as forgiving when machines make mistakes as we are with humans, because the machine has to do it right and I expect it to work, and otherwise it's a buggy thing, and if it doesn't work, I'll maybe just abandon it, and will it ever a buggy thing? And if it doesn't work, I'll maybe just abandon it, and will it ever get a second chance? Like?
Speaker 3:We seem to be different towards machines, and that's something we need to get over. It's something we need to. It's something that challenges our mindsets when working with machines, but that is a new era that we're in. I think we all need to learn how to work with these machines in a way where they're also not consistent always so and with humans and not either, right. So you could ask Peter the accountant hey, how do I post this rent to the GL? I could ask him today, and chances are if I ask him in 30 days from now I might get a different answer. But we don't think of it that way. But that's the reality. He might have forgotten, or he's maybe suddenly in doubt because he slept in. There's so many reasons why humans have deficiencies as well.
Speaker 1:Sorry, sorry, it's just interesting. You know we're talking about trust with the machines I can't remember what movie it was where. And there's a reason why robotics they put like human faces, because then you have a better connection, because that's how we're designed right. We're designed to like trust faces, but when it comes to machine one mistake I will never trust're designed right, we're designed to like trust faces, but when it comes to machine, one mistake I will never trust it again. Right, like versus a human person. I get it, you're human, you'll make mistakes, but oh, you're a machine. You made a mistake. I don't trust you because you could make a mistake every single time now, so that's-.
Speaker 2:No, exactly, that's fascinating. I laugh because I say the same thing and even with some of the mistakes, I think some machines are more consistent than humans. In some tasks it's even yeah, it's a long way. It is an interesting. I think we'll get there. I think we're in the infancy and I think a lot of it is the fear, as far as fear, of what are these agents going to do to me, to my value, to what I need. So I think some of it may be driven from survival of I'm against the machine. That's not to come up with the rage against the machine. It's like the first thing I think of, but it's like you said it's. We don't have that level of trust yet. We have the trust in humans and, chrisris, I did see that as well as is.
Speaker 3:That's why they put faces on it, because it's supposed to be human, like with you, which um yeah, no, that's true and it's into, it's interesting, like we're it's and this is a primal thing, like we've had it. It's just the way humans are sort of encoded like we need faces, like that's also why, uh, our brain waves seem to sort of sync up where we, when we're in the same room, like when we look each other in the eye, there's so many things that we just that we don't see, that we don't like understand, but our brains just work in a very sort of, uh primal way in the sense, like we're not, like we've we've only been on this planet for such a short while, like in terms of evolution, that the things that, yeah, we're not trying to do, that that challenges, uh, challenge how we, how we work as humans. Um, I want to go back to the policy thing because, uh, I just want to say absolutely agree about companies not having their policies written down, at least not the size of companies we would typically work with. Maybe some of the very large ones have some very well documented and then again, in many cases they don't. It's still tribal knowledge.
Speaker 3:We could also play with the idea that if you have history, once you enable the agent, you could have a function that would generate a policy document based on your history, right? So use LLMs to generate a new policy document and say, hey, this is like we're basically drafting up a work document that says, based on your post-to-purchase history, this seems to be your policy. Go now and audit that and then, when it's ready, put that in place. And now you, of course, need to keep that up to date and you decide when you sync that back into BC or whatever you do, or let that be the new knowledge base. So we could play with that thought as well. Also, brad, you had an interesting point about policy. So it's not only like the company's own policy, it's also regulation, governance, of things of that nature.
Speaker 3:We also envision that in time, the agent will be able to say, oh, I don't know how it is in the US, but, for example, if you buy IT equipment over a certain amount in Denmark, you need to depreciate it over five years or things of that nature. So it needs to be a fixed asset. So things of that nature like very local to your business, maybe to your industry, like if it figures out that on the IRS website it says something about your industry and whatever an expense. However, a certain expense needs to be handled. That could play a part as well. That's further down the road, but we do want it to be your accountant guide. Basically, it should have that knowledge in some way or form. So those are some of the ideas for the longer term.
Speaker 2:I think that's a great idea because it can be where it's helpful, because that can help a business. It goes with. It's almost when we went from having encyclopedias on the shelf to having search engines where you could search for information to be able to see it quicker. But also now, if you can have an agent we'll talk about, since we're talking about purchases and payables or the payables agents tongue-tied this morning it can help you make the right decision so you don't risk any violations, because it also can help you reduce your risk, because now you have these policies and now you have an agent that can help you validate that the accountant that you may have, even if it's a new regulation or a new rule.
Speaker 2:I couldn't even keep up with what the IRS does over here. I think it's purposeful how confusing they make it. But if you have some new rules that come in that, as you had mentioned, that Peter the accountant may not be fully versed in, if he could have reference to an agent that can bring it to light, to where either it reviews it or alerts Peter to say, hey, there's a new rule or hey, this rule's here, and then he could investigate and determine does this fit the new rules or regulations?
Speaker 1:So it can be extremely beneficial in right for agent Because there's been an understanding or at least you know how people perceive this payables agent as just an automation thing, and I think maybe they're missing the point. Where the value comes is to be able to adjust and reason hey, there's an update for this, there's an update for your policy. We should update that policy Because, again, another component of that is a policy changes. Nobody updates the document. You know. Maybe they update three months later because now there's an updated policy, but the last three months they've been using the old policy. So I think that's where the value comes in for these agents is to be able to look at other areas and say, make some suggestions and you know, and again, like you said, brandon, it's to be able to make better decisions without you having to really interact or maybe research on your own. It's going to know that, hey, I should check this area first to make sure it's updated.
Speaker 3:Yeah, and there's there's. So, brad, you mentioned like rules, like just as a phrase just before, and I think this is something that this is where we've been really exploring the last sort of six months is how much of this should be based on rules that you set up somehow in BC. Like think, like your rules and outlook, when x is equals one, then do this. When you know expense equals rent, then do this. But it just seemed like something new that you had to maintain and set up and create and we really wanted to avoid that if we could. So that's's why we're now leaning on your history.
Speaker 3:Maybe recurring purchase lines, policy and policy I think I hope will become a big part, because policy can play a part in so many other areas, like autofill. Like, now you create a new vendor. Well, what if it figures out while you're typing that you're creating a new shipping provider and in your policy you have something that says, oh, when you create shipping providers, you need to fill out this and this and this, or you need to always use a certain posting group, or what, what have you like? There could be so many different uses for policies around the system for uh time registration, for almost anything like the policy concept. If it works, which we hope it will, then there are so many different applications that can use that concept when you create data, when you create documents and so on, not just in purchase, but in everywhere, basically.
Speaker 2:You have, I think of this and it sounds all logical and what I I think of and I could understand it and it makes sense that I always get stuck on. You know, maybe it's because understanding how llms work, how do you come up with the idea? Not how do you come up with the idea, not how do you come up there, you come up with the idea. Now you come up with the rules and the logic, as we talked about, to be able to look at the history, be able to look at external documents and policies. Put it all together.
Speaker 2:So you have, you know, if someone's going through to design and develop an agent, when to determine that, an agent that has, again, the variable understanding, the lack of better terms versus the setup where you said you have a fixed setup, turn on, turn off, do this, do that to where you can have that large language model, variability and, in essence, deep thinking. And then how do you implement it. And then to also to my point with this, I think of all the stuff that you're talking about. So now you have an idea that you're working with. Should this be an agent? Should this not be? Now I'm going to determine how to execute it, but to me it's almost difficult to plan because this whole agent space in large language models is changing so drastically each week, so that something that you may be planning and working on today, next week you may have to have a completely different plan. I'm not certain if I'm articulating this one, it's just my mind is thinking through this whole process of putting this all together while the bus is still moving.
Speaker 3:In essence, that is exactly right and that is what we're doing. Technology is shifting so fast these days that it's both good and bad. So what we thought would be a limitation right now may not be a limitation tomorrow or next week even, which is great. But there's a lot of experimentation and I think that because this field is also so new, like this field of large language models and the availability of it, like this field of large language marvels and the availability of it is like hasn't like two and a half years ago? It wasn't there, like none of us knew anything about this two and a half years ago. So it's like it's so new. We're all learning and we need to do a lot of experimentation. That's also why we're trying to implement sort of a ways to get functionality out to people like yourself, so you can test on bits and pieces that are very rough, so we can get some feedback that are not bound to the six months release cycle that we have now, because that's simply too long time to wait for pivoting and so on, so that, along with just doing a lot of experimentation, pivoting and so on, so that along with just doing a lot of experimentation, but there's, I mean, if I could give an advice to people out there who want to start building agents or even just some AI like Copilot features. Just describing what you want to do like write it down in a document, just write it out. Describing what you want to do like write it down in a document, just write it out For the payables agent. I wrote a two-page document that described what happens Like oh, an email comes in with the PDF invoice, what does the agent do and how do I envision it will do it? So once I had sort of a grasp on that, then if I couldn't describe that, then I didn't know my scenario well enough. That scenario I wanted to automate. I just assumed at that point that it could be done. I didn't know.
Speaker 3:The next thing to do could be to test if Copilot or the LLM or whatever technology that you're using, has some kind of base understanding of the domain you're building into. So, in my case, has some kind of base understanding of the domain you're building into. So in my case, I wanted to see if LLMs had sort of a base understanding of accounting with a purchase invoice. So I took a PDF of a random invoice, sent it to Copilot and said hey, I'm an accountant, I work in Business Central. What on this invoice should I be mindful of when I register it in my system? And one of the lines said something like support and service for six months. So that was my test, to see if it knew about deferrals, for example, and it did. In the answer it said oh, I looked at this PDF invoice. Here's the totals and here's the customer, blah, blah, blah, blah. Oh, it seems like there is something you need to create some kind of deferral for because it's a service and support for six months. That was my test of. Does it have some kind of base knowledge of this domain at all? Because there might be domains that are so specific that it wouldn't have enough training data to know.
Speaker 3:But this is such a well-known I mean, accounting on this level is such a well-known space that the LLMs know quite a bit about it. So at least we have a good starting point for probably understanding something like just take a look at this invoice, take a look at this policy, take a look at this policy, remember this policy, remember this chart of accounts. What's the right thing to do here? So that's sort of as a fallback. So the way we think about this.
Speaker 3:Let's start with the most specific stuff. If you map your yield accounts to some text on the invoice, maybe that overrides everything, because that's an explicit mapping Great. If you don't have that, maybe we'll look at the policy. If you don't have a policy, we might look at your history. If you don't have history, we might just default to. What does the LLM just think just off the bat, or that's my thinking right now, but let's see how this plays out right? So no for sure, and it's super tricky to build this. To be honest. I mean we're. I mean this is hard, this is hard to build.
Speaker 2:I can't put my head around it. I mean I can, but I can't because there's a lot of moving parts with access to data, access to external information, as you talked about, with local policies, even knowing where you are. Because now being able to, it's all mind-blowing to me, because, differentiating between US purchase rules in the state of Washington versus the Denmark, you know purchase rules that you may have. I'm not even certain if you do it by country, by county or region, or how you separate them in there, but that has to be taken to ticket.
Speaker 1:You could specify that from a prompt perspective. For example, if you build an agent, you kind of set the rules of this is your baseline prompt? You are an accounts payable, that is your role. You are based in Washington state. Consider the policy in Washington state. So that's kind of your ground, where it doesn't go anything beyond that. You know, don't worry about the other states, you are in Washington state. You know, adhere to the policies and all that stuff. So once you get that ground and and they could still go crazy too, I don't know LLMs, they can still hallucinate Right, and then they could like ah, washington, washington DC, is that what you mean?
Speaker 3:Not Washington state, no, that's exactly right, and I think that's also why if we were just relying on the LLM by itself, maybe that wouldn't cut it. So but because we also have history and you might have your own policy document, maybe those things in combination can help qualify the suggestions that it comes with. But that is the thinking, like exactly what you're saying there, that in time it could have sort of a local view of the world as well. But it's also, but there's, oh, but there's so many challenges that we meet there where we meet some of the inherent things that we're missing from a technical perspective in BC. So, for example, business Central is not inherently aware of itself in a sense of what is a product in Business Central. Business Central doesn't know that. And a developer needs to tell Business Central search the item table, and these are the seven tables, right, that are related to the item table, or how many it is. But if you have an extension that extends the item table, now it's not just eight tables, now it's nine or 10 tables that make up a product in BC. But Business Central doesn't know that. I can say to BC search products and then give me X, y, z. So Business Central is not self-aware in that sense, that's something we need to work on, to figure out how do we do that, because we also need to consider add-ons.
Speaker 3:You might have extensions that extend even your purchase lines when you register an invoice. You might have other fields on the purchase lines that we don't know from a Microsoft perspective, but the customers added. But we need to respect those as well when we suggest the purchase line for this newly received invoice. So there are many tricky things, those as well. When we suggest the purchase line for this newly received invoice, right. So there are many, many tricky things. Then comes we also don't know the industry of this company. Okay, that might be easier to solve. We could just add a new field to company information. You fill it in, you know, based on some predefined list, maybe, or maybe we just look up your company name online little and figure out what is the industry of your company, something like that, if that's reliable enough.
Speaker 3:Then comes things that are sort of user specific or role specific. We don't. So obviously we know what the role the payable agents has, but we don't really know whoever turned on the payables agent, what their role is. That might be a person wearing all hats in the company that turned it on. It might be the accountant who turned it on or some admin, ic, admin person. So there's so many things where we need to get a lot more context, and those are things that we're we're trying to work on to figure out how can we make BC more self-aware and context-aware. But this is just under the hood. So many things.
Speaker 3:I want to come back to one thing you mentioned, brad, so I think well, both of you mentioned it. Actually, no doubt we see an agent as having a specific role or specific business process to sort of fulfill, like handle this venture, invoice process from start to finish. Already, there we're able to define some context for this agent, to define some bounds for it to say, I mean, if it tries to do something, we can sort of rein it in or fence it in in a way, because we know the context. We don't imagine one agent, one super agent, that just does everything, has all permissions in the system, that can do everything. An agent needs to have some inherent knowledge about what is it there for, and so we're, yeah, and that also has, of course, some benefits in terms of permissions, because it's it's, it's a user in the by itself. You can set up the, the uh, what is what it has access to in pc, and so on, um, but in terms. So come back to your question brad about how to stitch all these things together. What is AL code and where does the agent instructions fit in? And when do we ask the LLM and where do we feed it data If it needs to search our purchase history? Can we just loop through 1 million deal entries or like all these things? And this is super hard.
Speaker 3:The one thing that we're experimenting with now, because we have our own agent framework inside BC. That is not Copilot Studio. We went our own way because we were waiting for Copilot Studio to bring some of the capabilities that we need. So right now, the sales order agent and payables agent in BC are built inside BC, if you will. Those agents work in a way where they can navigate the UI. So a bit like the client, like the business central client that you see in UI, imagine the agent being able to navigate that UI.
Speaker 3:So let's take a scenario where you receive an invoice. You need to figure out just a super simple example. You need to figure out if this bank account that is stated on the invoice is known to us on the vendor. We could do it in AL. We could just do a three lines of code in AL check loop through the vendor bank accounts and check if it's a match. Yeah, but that doesn't sound very agentic. In a way we could also tell the agent go to the vendor card, go to the vendor bank accounts, go through the bank accounts one by one and compare them to this bank account you have on the PDF.
Speaker 3:If we can make that work as instructions, like in a no-code instructions, hey, go check if the vendor bank account is known to us by going to the vendor card, blah, blah. Go check if the vendor bank account is known to us by going to the vendor card, blah, blah, blah. Then we've not written code Now. We've written natural language in an instructions prompt somewhere. So we always have these decisions to make and the agent say do we just code it in AL or do we try to push the agent to do it via the UI? And we try to do an agentic first motion here. Because if we can succeed with that then in time you can imagine just going into BC pulling up a window, describe the agent that you want and how it should behave in the UI and then it would just go do all these things, no AL code needed. Basically, it would just navigate the UI. That is sort of the thinking of our agents within BC.
Speaker 2:You said a key phrase in there, a key few-choice words, where you said with the AL code, we're writing code for a specific scenario and then now we can instruct the agent to work with the UI. Now we can instruct the agent to work with the UI. So is the agent working with the UI directly to perform its actions, or is it working with code behind the scenes? I guess you could say in a low-code fashion of concrete scenarios that it's going through and trying to find, and then also to the to tack onto that, what about the variability? I'm all for agents having specific tasks and then they can do those tasks.
Speaker 2:Well, similar to what we're talking we talked about at the onset, where there's so many things that we want to do or I'd like to do, but I can't do it all because I don't have time. Nor could I do be you know, for lack of better terms good at anything if I do too much, because I'll have no time to be able to focus on it. So agents can have specific tasks. How is it working? And what about variable scenarios? So today we talked about bank account. Okay, now we can put it in, we can teach it, and I do want to go back to the UI and how it interacts with it. But what if tomorrow it's our vendor number for a vendor?
Speaker 3:Yeah, let's maybe go to the UI piece first, because just a quick bit of explanation of how it works and I might I'll probably vastly oversimplify things here and if some of our engineers are listening to this they'll probably say, yeah, it's a bit more detailed than that. So think of a page object with all the metadata it has about which fields are on it and so on. Today, very simply put, all that data is being exposed to the client as some internals or web service or APIs. The client reads that and renders the page right. So that same API the agent now has access to. So the agent can just not render but read all that same information that's on the page. So when we say navigate to the vendor's page, it does so like the client would. In essence, there's no physical client spun up somewhere, it's just the agent consuming those same APIs and navigating. Seeing in code it's like the matrix. You see all that green text. The agent basically just looks at all the metadata and say, oh, there's a caption that says vendors there, let me try to navigate to that. So that's very simple. But the way the agent can sort of navigate the UI, you know, can say, hey, go to the lines and create a new line, add this value here, and that's also why it will always see what the user would see, if it has the access, of course, to that. So that also means that when we build UI for the agent to traverse, we need to remove ambiguity and need to remove stuff that makes it confusing for the agent, which happens to have the nice side effect that what is confusing for agents is probably also confusing for users. So if we can simplify some more, that's probably a good thing. Yeah, so that's just about how the agent will sort of work.
Speaker 3:Will we sometimes have to do things in AL instead? Have to do things in AL instead, where, because it's just like, for example, finding a certain record or things of that nature, might make more sense in some cases in AL instead of having the agent do it? That's also a cost concern or consideration we need to think about. Well, when the agent navigates the UI in this way, it uses the LLM, so inherently we will have a cost of running the agent, basically because that we wouldn't, in the same way, have an AL, at least not. Well, the machines where the NST is running is running anyway, but still there are many factors in this, in deciding do we go for AL, do we go for natural language? In essence, and we're trying to push more to go towards natural language. Sorry if I didn't really answer your question there, but no you did answer it and it's.
Speaker 2:I'm pleased to hear there's also a consideration today, because no one knows what the future would be.
Speaker 2:It's almost like I remember when the cell phone was invented and it was probably $300 a minute to use the cell phones. Now cell phones are fairly reasonably priced for unlimited text and data for a given month in the onset, while the technology is still new and it can be costly. In essence, to see that there are some considerations to appropriately use the agent in consideration for cost and function, not just to use an agent for the sake of using an agent. So it is nice to hear that those considerations are in there and I do understand now that it's working with the ui and that's how we can limit what it has access to and what it can do within the context of the user executing the agent and what they have access to, if I'm if I understood correctly yes, it's I've had conversation with some and there may be a misconception that you know agents are just, you know, co-pilot workflows or power automate flows or some fashion of that, and it's nice to hear the details, and I've been having conversations with everyone.
Speaker 2:It's a lot more than that and is that a true misconception? Or is it just somebody trying to knock AI similar to back? When I see Chrissy, as we say this almost every day, it's you use the appropriate tool for what you're trying to do. Asking AI to say five plus five and it and being able to make it do 11 doesn't do anything because you can use a calculator, or maybe there should be an agent for math versus an agent for payables. So it's speak. It's just like people or humans. I speak to a specific human if I need specific information. You know an electrician, a carpenter or something.
Speaker 2:I went on a little tangent there, but yes, you did answer my question.
Speaker 3:And I think that this is worth just drilling a bit more into like the role of an agent. I know we always spoke about that it has a certain role, uh, to, to, to play like. Uh, how that? Like, if you draw up an organization and you look at the agent landscape like, what, what should an agent landscape look like in in this organization? Oh, do I need a payables agent? Do I need a sales agent? Do I need, like, when is my plate full of agents that now all bases are covered in my company? And how do they hand over to each other? And do I have a master agent of all of them? Or do I have, like that sort of orchestrates it all or are they able to orchestrate between them and just hand over? And how small should they be? Like, also, when you consider that it's a user that they sort of emulate in a sense, should we consider that the classic sort of segregation of duties, all those things like do an agent map to a human one-to-one or like, and how does that look and how does that look like in this organization? So, and there are so many things like, we've only just begun, so I think that's something we need to get wise on as we go along.
Speaker 3:Personally, I don't see one super agent that does everything. I would rather go smaller agents, much more limited scope, because that also means we can define their context much more precisely. Much more limited scope, because that also means we can define their context much more precisely. So they're. They ideally wouldn't go out of bounds of what they're supposed to do so often.
Speaker 3:But then you could imagine having like, let's say, you had five finance agents. Then you could have an overarching supervisor agent within finance that could help sort of orchestrate between these five finance agents. Could also be you had a vendor communication agent that said oh, now we get an invoice in, this goes to the payables agent. But the next time there's an email from the vendor it happens to be a reminder that they haven't gotten our payment. So obviously that doesn't go to the payables agent, this goes to someone else, another agent. So who's orchestrating that if they're all monitoring that same inbox? That's stuff we need to figure out. But the discussions have started. How do we? What does the agent landscape look like? How do they hand over? Where do the humans fit in All of that? Where do we have the one overview to rule them all?
Speaker 1:and all that stuff. You need that business uh, orchestrated or that orchestrates all the agents. Right, like if, if I'm a business owner and I need it to do something, I I I'd rather just go to a single agent that can help me orchestrate to accomplish the goal of my business, rather than, yeah, my goal involves this and then I got to go talk to individual agents, versus going to a single maybe a tenant agent that lives in your tenant and it says I need to do this so it may pull in certain points of my applications, whether that's business central or maybe I need to interact with teams and whatever that is, it's much easier for me from a business perspective, much easier to go to a single agent that will orchestrate that.
Speaker 3:And that's a great way of thinking about it. And I think when I say that we I personally I'd like to componentize agents as much as possible, try them as small as possible. That doesn't mean you'll have 100 interaction points as a user. You could still have that one interaction point, as you say, like the master orchestrator agent, or maybe within that domain you work as a user, and then that agent will, will, coordinate with all the other users. So it will, it will have directs, if you will like. Uh, so it's. It's a bit the same kind of organization, yeah, same hierarchy, if you will. And so, and I think that that's, that's just some technicalities. We need to figure out how do you interact with an agent. It doesn't necessarily need to be a one-to-one representation of how are the agents represented in the system under the hood somehow. So, uh, you could have a one, one to twenty relationship, uh, between you and agents, but there could be a single pane of glass that will be that interface or whatever that would be super fascinating.
Speaker 1:It would almost really like it's a one-to-one human, like a true co-pilot, right. Like I'll have a co-pilot of a VP of operations, right. Like that would be the person that I would go to and say I need to accomplish this, how do I accomplish this in the system. And then that agent for that specific role for operations would then just interact with all the different agents. That also kind of follows the hierarchy within your organization. That's how maybe I'd see it, because then every role has a co-pilot.
Speaker 3:No, to me that makes perfect sense. And I think where we are now is that we need to start with we need to also be mindful of where we are and not try to build 100% automation to begin with. We need to learn and there's benefits in involving users more often to begin with, because there's a lot of learning moments when users are involved Whenever, as I mentioned 30 minutes ago, whenever the user changes some of our suggestions or the agent's suggestions, that's a learning opportunity. So there's sort of great value in having human in the loop and I think if we can combine it with the risk of being a little bit philosophical but if we can make humans and agents work together and complement each other's weak sides, that's that we would have a very well-working agent.
Speaker 3:Aiming for 100, I think. Think, of course I mean we wouldn't want accounts payables to be 100% if it's reliable and fast and well, maybe speed doesn't matter as much, but at least reliable. But I think that will take time until we get there and that's fine. If we can solve for the 75% of the normal day-to-day use cases, that's also super cool. And then humans can do the more complex handle, the more complex invoices and over time, as we get better using this technology, the agents can get better. Then probably we can increase that to I don't know 80, 90 percent, who knows if we get close to 100.
Speaker 2:There's so much in there and I think it's, you know, the future. Who knows where the future will be? And again, I do think we're at the point just in our society, just to go philosophical for a little bit because, realistically, some of this AI agent stuff, with it being so new and learning what it can do and seeing how it reacts, responds and works, is philosophical because we don't really know. But it would just be interesting to see where it will all be and how this will all work uh, in the years. And I think now we're just throwing a lot of agents against the wall to see which work, which stick, which are effective, and then also how to, to your point, maybe even break them down to have separate agents that have specialties or specializations, to be able to have them work together.
Speaker 1:You know, I think it's going to be.
Speaker 1:I would love to see it more of a role specific, because, if you look at the way I use agents or co-pilot, right, for example, in my day-to-day it's typically around my role, and so it would be interesting to see if this is maybe where you guys are heading toward, where Microsoft is going towards, where there is a co-pilot working along with me, because then I can have my conversation with my CEO or your president or anybody else in your organization is more strategic, strategic, right.
Speaker 1:There's something that us humans are more creative and more strategic about things, that we you know what we do in the business, where the hard, you know, the tedious work of getting to do things is where the co-pilot comes in, where, hey, I need some data, you know, give this information to me while we're trying to make a decision of where the business is going. I think that would make a lot more sense that you'd always have a co-pilot with you, based on the role and, of course, structurally in terms of hierarchy within the system. It also makes sense because we understand that your agents are based upon a role, right, because it's UI driven. I think it's limited to a specific role, and so maybe that's where it is, because now you have, you know, an AP payables agent, now you did accounts receivable agent and so forth, sales agent and so forth. Maybe that is where the structure is. To me it makes more sense because my area of focus is just that's, my interaction anyway.
Speaker 3:No, and I think that makes perfect sense, and I think that this is why we've all chosen this path and chosen sort of well-known scenarios, roles even you can say they're even more narrow than a role at this point, because a payables agent, like a real accountant, might do more, or an AP clerk might do more than just register invoices.
Speaker 3:I guess it depends also per company, and I think what we're doing now is a lot of experimentation, and I think that's the only way forward. As you said, brad, like we try to create some agency which ones work as the technology improves, as it does every day, and I think we also just need to be honest that I mean, as I said, two and a half years ago this field didn't exist, so there are, by definition, no experts. We're also learning, right, we're just working on this all day, every day, so we get a lot of exposure to it as technologists. So we get a lot of exposure to it as technologists, but experts, I mean I would like to say we're getting there, but you know who can be an expert in two and a half years of exposure to something? So this will take time, so we're all learning right and an expert on something that's changing daily.
Speaker 2:So it's not only that it's new. Generally speaking, it's in its infancy. But it seems every time I wake up and put on the morning finance news, they're talking about some new LLM, local large language model, some new agent, some new version that it's very difficult for anyone to keep up, which is also important to mention. Some are talking about that it may be too late to learn or too late to get into it, but everybody's in the same boat because everything's new.
Speaker 2:So no one has missed the agent experimentation phase, even Copilot Studio, as you had mentioned.
Speaker 3:they keep adding features and changes, so and get in and start working with it yeah, and this is, of course, a much larger challenge that we, like the industry, face, and all companies out there wants to consume all companies out there who wants to consume AI or to consume features within their ERP system or whatever. So, on one side, we have a higher than ever before desire to experiment, test out things A B test, try out things with real customers and so on, and that will only increase Our desire to do that will only increase, and we need that because technology is changing Every day. We look in the toolbox, tools look different, work different. So on the other side of that, you have customers who need predictability, they don't want to be disrupted, they value business continuity, all these things. So how do these two ends meet? We need experimentation and what you call fail fast or adapt fast or pivot fast Customers. They just wanted to work the same way as they did yesterday. So how do they meet? And I think that comes back to, at least for Business Central specifically, we need to figure out ways where we can create test rings and let people opt into being early preview testers or maybe test experimental features in a sandbox or what have you, so we can get some some feedback.
Speaker 3:Yeah, but this is, this is a challenge, for sure. And also when it comes to adoption, as we spoke about an hour ago, like if it doesn't work or not in terms of a bug, but if I don't get the result for of a feature that I expected of this agent, will I abandon it or will I give it a new shot tomorrow where we've maybe changed some stuff and updated it and all of that. You had a great episode recently about change management, which I loved. That was just. All of these things are just more important than ever, and I think we have some part of that that we need to do Educate, explain value even in the UI, make it evident what is the value for you as a person, not only for the company, but also for the company. This is going to be even more important than ever and super hard.
Speaker 1:Yeah, I think I mean just thinking about just going back to the hierarchy component and you brought up the adoption. You know, a lot of times you know employees or users of an application or even within the business itself. It typically bleeds from what you do on a personal side of things and then you kind of bring that into your business. So, for example, I'd call that. You know I use Copilot or ChatGPT or whatnot and when you chat right, you have different chats. Typically, when you're creating your chat you ground it of what that role is. You are my finance manager and I have this situation and I need you. It's almost like that, right, with Business Central. I would think that's where we're heading.
Speaker 1:I can't foresee that. I'm just thinking out loud here where I would love to structure it that way where what I do now personally I could do the same thing in Business Central. I'm going to add an agent. You are this agent. I need you to do this. It's almost in that way of easy for people to kind of understand because that's what they do. Now I mean, it's becoming a day-to-day occurrence. I chat with my chat GPT or grok or whatever AI that you use for chat. But again, I can't predict that. Just the way I do things in a day-to-day, it may bleed into Business Central. I don't know.
Speaker 3:Yeah, but I think it makes sense. And if you think about the way that the agent, like you, have a bunch of agents enabled for your organization. They work for different teams, for different users and so on, and at the end of the day, there would be supervisors of agents, like human supervisors of agents, that would work with agents, make sure that the wheel's always spinning, that the agents are not stuck on anything, of course, with all the business approvals built in that you typically want. When you need to approve a new vendor that's great in the system, or need to send the PO for approval, all that stuff still works as it used to. The agents don't change that. All that stuff still works as it used to right the agents don't change that. It might be that you can have agents that will help these approvers as well. Like you can imagine an agent that says you know, here's a new approval request from Chris who wants to approve this purchase order of $10,000. Well, based on history, there's nothing to worry about. You can easily go approve this one. Should I go approve it the next time on your behalf?
Speaker 3:There are many applications where you can think about agents kicking in and learning from the history and, looking at you know, try to identify risk, because if there's no risk, why stop at all? Why not just go ahead and and um, yeah, but let's see how far we can. We can drive this automation because it is automation brad you asked about. Was this just a glorified flow? Depends on how you look at it. I mean, from a conceptual standpoint, you could say yeah, uh, but it's a flow that's able to handle much more variability, in a sense, like where flow is very deterministic. You put a stick in the wheel on a certain point it just breaks and falls apart. Where here it's a bit so yeah.
Speaker 3:A guy said to me some months ago well, this is like when you build houses in areas where you have a lot of earthquakes you build them so the foundation can sort of move and the house can move. It's a bit like the same thing. You need to build in some wiggle room so the agent can take some decisions within a certain context, within certain constraints and so on, but not break when something doesn't follow the sunshine path Understood. It's not a bunch of ifs and thens yes, it's.
Speaker 2:No, it's. I mean, I guess, ultimately, I guess any workflow is a bunch of ifs and thens. It's just a matter of which ifs and thens and whens you can react to, or respond to without breaking. So we've talked a lot about the payables agent. What is the current state of the payables agent as far as availability and what are the short-term future plans? I know nobody can plan too far into the future because something could change tomorrow, but to anybody listening, we've been talking about it. What is the current state and availability for it?
Speaker 3:Yeah, great question. So because the agent navigates the UI, as we've talked about, we've had to improve some stuff in sort of the base application, especially around e-documents. We've had to build a connector where basically JobQ, or the agent, via the JobQ, could pull in an invoice that comes in on a certain mailbox or on a SharePoint folder and so on. So we've done some components that the agent will use and those are right now, and we'll call sort of private preview where if you're on a certain list, your tenant is on a list, then you can get access to some of these components and try them out. This is not in any way any agentic experience yet. This is just some improvements to the base product and we'll keep doing those over the next sort of few months and the idea is that we'll add the first sort of version of the agentic experience, enabling the end-to-end flow, creating the invoice and so on, with the next major release.
Speaker 3:That is the next. That is the plan. So end of year, this calendar year, basically, how much will it then support in terms of how much accounting knowledge we'll have? Well, that's what we need to figure out from now and until then. Will we have the policy concept working? Will we have some learning concepts working Well? How much would we look at purchase history when we try to determine what the invoice should look like, and so on? So that's to be decided. But ideally we would have the first version working with the next major release and in US and maybe some other English-speaking countries to begin with, and then it's going to be an iterative process, adding more capabilities, adding more countries and so on after that. But yeah, keep an eye out for the next major release.
Speaker 2:That's the current plan Always a lot of great things added to each of the major releases, and well, so we appreciate you taking the time to speak with us today. It's always a pleasure speaking with you, whether it's either on the podcast or in person, or even in some remote conversations. We do appreciate you taking your time to speak with us and we appreciate all that you do for the community and as well as all of what your team is doing for Business Central for the users of the application. If anyone has any questions or would like to learn more about the Payables, agents or other initiatives that you're working on, what's the best way to get in contact with you?
Speaker 3:Well, this moment there's probably two good ways. So one is on the Yammer site or Viva Engage If you're a partner. Reach out there If you have questions that you don't want the world to see. Otherwise, feel free to hook up with me on LinkedIn. It's the only place that I'm sort of active from a sort of social media perspective, so feel free to send me messages there or tag me in the post or whatever, and I'll be there.
Speaker 2:Great, Thank you very much for taking the time to speak with us again, and I hope you get some great gardening into the season as well.
Speaker 3:Thank you so much, guys, pleasure all right, thank you so much soon ciao, ciao, bye.
Speaker 2:Thank you, chris, for your time for another episode of in the dynamics, corner chair, and thank you to our guests for participating thank you, brad, for your.
Speaker 1:It is a wonderful episode of Dynamics Corner Chair. I would also like to thank our guests for joining us. Thank you for all of our listeners tuning in as well. You can find Brad at developerlifecom, that is D-V-L-P-R-L-I-F-E dot com, and you can interact with them via Twitter D-V-L-P-R-L-I-F-E dot com, and you can interact with them via Twitter D-V-L-P-R-L-I-F-E. You can also find me at Mattalinoio, m-a-t-a-l-i-n-o dot I-O, and my Twitter handle is Mattalino16. And you can see those links down below in the show notes. Again, thank you everyone. Thank you and take care.
