The brain of your business, built into Business Central.

Introducing Volt Cortex by Volt Technologies. Our frontier engineers at Volt Technologies built an agentic platform to run our consulting operations. The platform was built primarily in Copilot Studio and holds everything our organization knows about Dynamics three sixty five Business Central implementation and continuous improvement, meaning the skills and departmental context our people work from every day, and it executes and monitors the agents across every lane of our business. Cortex was built for two outcomes, faster implementations and instant break fix support. Both were achieved. Initial data migration on a Business Central implementation now runs roughly five times faster than it did before, with data migration agents running agentic loops, iterating on self healing SQL scripts, and configuration package imports. A reported issue or requested enhancement moves through from initial requirement to not only AL generated, but also instantaneous deployment to the customer's Business Central Sandbox environment in minutes, not days. All with GitHub's application life cycle management strategy being strictly followed. Cortex quickly became the hub of our operations because it just worked. It eliminated not only the friction of a connection between real Business Central work and an agent harness. But because of the intelligent context management, it understands our business, our customers' environments, their integration architecture, ISV landscape, custom code, plus Business Central source code. Plus, being published with an MCP, it is enabled for external use anywhere. Then we noticed something. The platform was not just transforming how we work. It was able to transform how our customers could work as well. So we bottled it up, and we gave Volt Cortex to customers in private preview. Today, it is reshaping how they run their business on Business Central. Copilot is at the core of all of it. Every Business Central license Volt sells now ships with Copilot attached, not as an option, as the foundation. If you run Business Central with Volt, you run it with Copilot. And Cortex is what turns that Copilot into a workhorse that knows your business and can run your business. Check it out for yourself at cortex dot volt technologies dot com. Volt Technologies leading the frontier of Microsoft AI business applications.

In 1971, the Nobel Prize winner Herbert Simon observed that a wealth of information creates a poverty of attention. Let that sit for a minute. He wrote that more than fifty years ago, and we've now watched this play out through expansion of the Internet and social media ever since. We've been operating in this attention economy that he described, and every single one of us knows this to be true. And here is my belief that in a world where intelligence is now abundant, AI is creating the sequel to Simon's observation. A wealth of intelligence now creates a poverty of judgment. And that's what I want this whole video to be about. And I think it's the most important thing for anyone that's running a company to understand today. And I call this the human judgment premium. I'm Mason Whitaker, the president of Volt Technologies. We are deploying agents into production inside real businesses every single week. These are not demos and not pilots, So everything I'm gonna tell you is what I am watching happen on the front lines on the ground. And here's what we're gonna cover in the video. Number one, why intelligence just became abundant and trending towards free. Number two, what the human judgment premium is and why it compounds instead of fading away. Number three, what we're seeing firsthand in our own deployments and what the gap between people actually is. And number four, the problem that almost nobody is planning for right now, which is the path to building judgment is actually disappearing. And number five, it's four principles to build for that disappearing of judgment deliberately. So let's start with where we are today. Here in 2026, we have instant access to tools that just a few years ago, we would have called artificial general intelligence or AGI as everyone calls it. Take a second with that because I think we really skipped right past this. These tools can now perform most tasks better than the average human, and they are remarkably inexpensive relative to work that they're replacing or they're augmenting. In my own line of work, we're putting agents inside of production, inside real businesses every single week, and we have tasks that we would have seen humans take previously weeks, if not months, now accomplished within minutes and hours instead. This is only when applied in the right way, though. In that sentence is the the whole thing. This is not something that is a caveat that I'm, you know, asterisk trying to protect myself. That's the entire variable. So here's the question that matters. What determines whether something is categorically correct or right? It is the human that matters the most who is in pointing these tools towards an expected outcome and directing them along the journey. Nothing else in this whole system decides that. So in a world where we have, access to these AGI level tools in an almost unending fountain of intelligence growing at now an exponential rate, the scarce resource has become the human who can apply their own judgment to achieve a specific outcome. And if you're an executive listening to this, notice what happened to your constraint. It's no longer capability, and it's no longer capacity. Your constraint is direction and human judgment. So this is what I call the human judgment premium. And this is not a slogan. It is really an economic observation or principle, and it's the reason that I'm confident that this is gonna be permanent rather than just a phase in the market. History has proven that when a resource becomes abundant, like we're seeing intelligence trending towards free, the value migrates to its compliments. And that is not theory. That's what happens every single time. When something gets very cheap, whatever is pairing with it becomes valuable. Intelligence is this resource that is getting cheaper, but judgment is the complement that actually makes it valuable, which means that as intelligence continues to compound, and it certainly will, the premium compounds with it. The abundance story that people are saying is that machines are gonna handle everything. And the doom story that people are saying is that machines are gonna replace everyone. Both of those stories are dropping the human out of the equation. Economic principle says actually the opposite, that the human is becoming the main staple in the equation. Now let me show you what this looks like inside a real company because we're seeing it firsthand. Access to these AGI level tools is abundant. You can get it off the shelf from any frontier model provider. Yet the difference in outcomes comes down to the person who's directing the tool. Across the technology implementation ecosystem today, we're seeing individuals given the same tools, the same training, same shared access to context, and, you know, they have the same role and department, really the same everything. And without fail, certain individuals substantially increase their capacity as well as the quality of their outcomes, while others struggle and stagnate. So this is the same tool, but a wildly different outcome every time. And for a while, I thought the natural, you know, thing is the assumption is that, well, this is a training problem, and it is not. What we have found in our own deployments is that the gap is not prompt engineering or know how to better instruct the AI. It's... And it's not having a deeper understanding of the tool itself or or usage of the tool for that matter. It's the ability to understand what should be done and why. Having this clear picture of the outcome is what enables a person to know what good looks like. And then when the tool is complete, to validate what it produced. So think about how much rest on the second half of that problem. So the validation. If you cannot tell whether the output is right, then speed is not helping you at all. It's just moving you in the wrong direction faster. So the ability to think critically about a goal, understand why it matters, you know, visualize that outcome and what that should look like, that's the clear differentiator now. And so the model has never been the differentiator. The judgment that's directing it is. And here's the part that honestly concerns me the most, and almost nobody is planning for this. Judgment of this caliber is not something that's just built overnight. It takes years of training and activity to develop this domain expertise, to understand what good really looks like, and to know where you should be pointing the tools. You don't get this from just taking a course online. You get this from doing real reps. And here's the new problem. The very activities which always were used to build that judgment within someone have now been delegated to the tools. So think about that for a second because it's it's a genuine paradox that we're dealing with. The work that made people good at knowing what good looks like is exactly the work that we just handed off over to the machines, like grinding through reconciliation of data, building out models by hand, owning outcomes when things go badly. This natural path of learning judgment is disappearing, and the gap between those who have judgment and those who do not have judgment is gonna widen in the years to come. The good news though is there is a way to build for this deliberately, and here's four principles for you to enable this. The first one, principle one, hire for judgment and train for tools. Tool fluency is a commodity that you can train on and install in in really just weeks. But direction and judgment, that's an asset that has to be acquired over time. So it's important to hire for that. Principle two, arm the people who already have judgment in your team that already have shown that they can do this, have the domain expertise, arm them with these tools. The returns that AI has concentrate where judgment already exists within the organization. So a strong operator enabled with agents doesn't just get incrementally better, they get categorically better. Principle three, you wanna manufacture these judgment reps. You wanna put juniors inside real decisions early on, make them articulate the why of the task, and then focus on what they're visualizing the outcome should be before any tool moves to execute. And that sequence, that building of the judgment is is now the Principle four, you wanna measure direction direction and not activity. So output volume and execution is is now nearly free. What's important is that we measure did the right thing happen, and did it happen for the right reason? So four principles. And notice not a single one of those is about model advancement, and that's really the point. So here's what the human judgment premium really is. It's the recognition that machines are making execution and activity almost free, but they made the right people priceless. With access to these tools commoditized, an organization's people will be the main differentiator. It's my belief that they always have been. So three things to remember here in the end. Number one, a wealth of intelligence now creates a poverty of judgment. So your scarce resource in your company is now the human who can point the tools to the right outcome. And number two, the premium compounds now because value is migrating to the complement of whatever just got cheap. So as intelligence trends towards almost free, that judgment is gonna be the premium. Number three, you wanna build a judgment learning pipeline very deliberately, because this path that used all through history of building judgment is now gone or it's disappearing. So that is, you know, something you should be investing in very deliberately. So thanks for listening. Hopefully, you got some value out of this. Subscribe and and follow for more insight because there's a lot more to come.

If you are already live on Business Central, changing partners feels risky. It is risky. I'm not going to tell you otherwise. But the risk is usually not where people think it is. It is not the contract, and it is not the timing. A real risk is that somebody else built your system and that they know things about it that are not written down anywhere, why a field was set what way, what that extension is actually for. And on the day they hand it over, most of that leaves with them. So that is the problem. Here's what we do about it. I'm Sam Van Heukelom, director of operations at Volt Technologies. Taking over environments we did not build is a large part of what my team does. So I'm going to walk you through exactly how it works. Five things. One, why companies actually make this move? Two, the handover itself, step by step. Three, how did we learn a system we did not build? Four, what the first ninety days look like? And five, the two questions everybody asks me about code and about licensing. So why do companies actually make this move? Most support relationships do not change because somebody's bad at the work. Usually, the relationship has drifted out of shape or the team that fit the implementation is no longer the fit for what your business needs after it has been live for a while. The first pattern is a coverage gap that nobody owns. If the people who know your system have very little overlap with your working day, a question can move back and forth over several days, even when each individual response is reasonable. The second pattern is a ticket that goes quiet. The request has not been refused, but you cannot see who owns the next action, where the work sits, or when you should expect an update. The third pattern is product knowledge without enough operating context. You may have to explain how your apparel, distribution, or manufacturing process works on every ticket before anyone can get to the Business Central issue underneath it. The fourth pattern appears in configuration, shortcuts, unnecessary customizations, and master data that partly supports the process. In one anonymized case, OnTAC setup sent a large batch of invoices to the wrong recipients. The pattern connecting all four is that somebody inside your business quietly becomes tier one support. That person fixes what they can, translates every issue, and escalates only what they cannot solve. So the operating costs sit inside their regular job and never appear on a support invoice. Now for the handover, step by step. The handover has seven steps, and some belong to the incoming team while others require action from your business. You want to assign the owner at the beginning because a transition usually slips when everyone knows a step exists, but nobody knows who is responsible for completing it. First, the service agreement and the support addendum are signed. Second, your business accepts the Microsoft reseller relationship, which is an action that has to be completed inside your Microsoft account. Third, Volt sends the delegated administration request, and your Microsoft administrator accepts it so the support team can work in the environment. That delegated access does not consume one of your Business Central licenses. Fourth, you grant read access to the code repository. Fifth, you provide the documentation and standard operating procedures that exist for the system, including things like integration notes, process guides, and prior design decisions. Sixth, Volt grants your team access to the support portal. Seventh, work begins with the access baseline documented and the open issues ready for triage. The steps that usually take the most coordination are the Microsoft relationship, delegated access, and source repository access. They require a global administrator inside your business, and for some code, a release or permission from the organization that controls the repository. So those owners should be identified before the transition date rather than while the first ticket is waiting. The elapsed time depends on how quickly those permissions can be completed, which is why the useful measure is not a generic duration, but whether every required owner and approval has been named. On day one, the incoming team needs access and a baseline of the environment. Documentation can follow during the first few weeks, and it is usually thinner than people expect. So the next step is designed to create the system record that may not exist today. So how do we learn a system we did not build? There are two separate parts to learning the environment. Discovery maps your business and the systems around it at no cost, and the diagnostic is the paid technical audit underneath that map, completed before the support process is fully underway. Discovery produces a business model showcasing things like your legal entities, inventory locations, sales channels, and intercompany flows. It also produces a system model of everything connected to Business Central, including whether each connection is manual or automatic, and whether information moves one way or in both directions. Those models are orientation tools. A consultant who has not seen your business before can use them to understand where a transaction starts, which system changes it, where it enters Business Central, and which legal entity or operating process owns the result. Diagnostics then creates the technical working set. That includes a source code register for every extension in the environment, a defect in open issue backlog, a support runbook, a risk register, as well as a thirty, sixty, ninety day plan for sequencing the work. That list is not unusual from a buyer's perspective. A company running a formal selection process has for almost the same set of documents because a finance or operations leader needs an inventory of the current environment before approving changes to it. The source code register also states which extensions are running in the tenant when the source code cannot be obtained. You want that limitation recorded at the beginning, along with the extension's purpose and business dependency instead of finding it when an update or defect requires a code change. The audit typically surfaces things like customizations that repeat standard business central functionality, integrations that are running without monitoring, and platform conditions that have not been reviewed. One example is storage consumption that increases over several years without an alert or a documented plan to manage it. So discovery tells the team how your business and systems fit together, and the diagnostic tells the team what is actually present, what is missing, and what needs attention first. Together, they replace undocumented knowledge with artifacts that can be reviewed and maintained. What do the first ninety days look like? The early work needs to move through four phases, and each phase needs an exit criterion rather than a general statement that the transition is progressing. The dates can vary by environment, but the order matters because later improvement work depends on control and stability first. Phase one is take control. You obtain access to every system, the code base, credentials, integrations, and third party applications. And the phase is complete when the support team can independently reach the required systems and a written environment baseline exists. Phase two is stabilized. You triage the inherited defects, validate the integrations, and work through a clean month end close with a completion defined by a close that finishes on schedule and does not contain unexplained variances. Phase three is simplified and hardened. You review conflicting third party applications, remove redundant components where that can be done safely, and document a decision for each one so the integrations can run without somebody monitoring every step by hand. Phase four is build forward. Once the environment is controlled and stable, you can plan things like reporting, historical data, automation, and the capabilities your business wanted before support work took priority. Each item then has a roadmap position, a sequence, and an improved estimate. For the finance team, the first clean month end close is usually the point where the transition becomes operationally real. It demonstrates that the team can support the complete cycle, not just close individual tickets, and it gives you a baseline for the next month. Build forward does not have a natural final phase because the road map changes as the business and business central change. That continuing work is the subject of the third video. So now for the two questions everybody asks. The first question is what happens when the source code for an extension is not released? You can still analyze the environment and inventory the installed extensions because they are running in the tenant. So the register can show what exists, what it does, and whether the source is available. If source genuinely cannot be recovered and the extension later needs to be changed, the affected capability may need to be rebuilt. That work is scoped and estimated as a separate project before it begins, so the missing source is documented as a known dependency rather than discovered after a change has already started. The second question is what happens to licensing? The support relationship and the license administration do not move on the same day, so support can begin after the required access is approved, while the existing licensing arrangement continues through its applicable term. Microsoft provides a way for you to authorize a new organization to support and administer your environment during that period. In practical terms, your administrator approves the relationship, the support team receives delegated access, and your users keep working under the licenses already assigned to them. So there are three separate tracks, support, licensing, and source code. They can move on different timelines, and you do not need to treat them as one event that has to be completed in a single step before any part of the transition can start. Each track needs a named owner and decision. It needs a place in the plan. So that is the transition start to finish. Three things worth remembering. First, the risk in changing partners is knowledge, not paperwork. Everything we do in the first month is about writing down what was only ever in somebody's head. Second, you will get an actual inventory of your own system, the extensions, the integrations, the open defects, and the things we could not recover. Most companies have not had that documented, including the ones who are happy with their partner. And third, none of this has to happen at once. Support, licensing, and code can move on separate timelines. If you've been putting this off because it felt like one enormous decision, it is not one decision. Do you wanna see what the support relationship looks like once the transition is done? That is the first video in this series. And if you want to know what we do with the rest of your system after that, watch the third one.

So how do you evaluate AI readiness within an organization? It's difficult. It's honestly very challenging to figure out if your company is gonna be ready to tackle something as big and hairy and scary as as AI is. And you can do this pretty methodically. You can look at this through three different lenses. The first being people, the second being process, and then the third being technology. And you have to look at this in that order. It's important. I'll get to why. You wanna start by looking at your people. Do you have your teams organized in a way that is intelligent? Do you have the structures of their job responsibilities and their job descriptions very clearly outlined? Do you know what your people are actually doing? And are they actually ready for a change like introducing AI into their business process? A lot of organizations, they are used to doing things the way that they've always done them, whether that's paper based or manual or, you know, maybe done in just an electronic fashion. Maybe you're a little bit more modern and tech savvy business owner. You have to take a hard look at your people and understand what's gonna be the lift from the change management side of things for this this project of implementing AI. Because implementing AI really is a project. It's it's no different than implementing any other system as you would have previously. And McKinsey has published a research paper that says that seventy percent of change management programs fail to ever go live, specifically system implementations, not because of the technology, but purely because of people adoption on the client side. So you have to take a hard look at your people, and you have to understand what are their current skill sets, what are their capabilities. You have to map out individual plans for each of your different departments of trying to level them up and get them ready for this change. So coming up with a plan and addressing each of the individual skill sets is gonna go a really long way. Also identifying within your people who the champions are gonna be is really important. It's not just gonna be you as the business owner or the CIO or IT director that's gonna be pushing this throughout the organization, you're gonna want people that are on your team that are excited about this technology that they can drive this through the rest of the organization. So identifying those champions up front, getting them really excited about the technology, showing them proof of concepts, and things like that, it's it's gonna go a long way as well. And you wanna look at how ready those people are as a measure of your evaluation if you're ready for AI or not. The second aspect is gonna be on the process. Within every single business, there is a process that you go through to perform something to be able to have an order come in and then collect cash in the end, or to be able to have a service performed and then cash collect At the end of the day, you can break down any business into a series of processes. And how well defined you have those processes, that's really gonna determine how ready you are to adopt AI. If you just have Janet who works at your company that she knows everything in the business and she essentially is your repository of processes, it's gonna be very difficult for you to apply AI to that scenario. So you wanna make sure that you have things documented across standard operating procedures of, you know, when this happens, then I need this to happen. So triggers and actions across your entire business. Getting that very clearly outlined from the offset, that's gonna enable you to springboard your AI usage because you're gonna be able to tell the AI exactly what you need to do along the entire way. And a recent MIT study came out that shows that ninety five percent of AI projects are failing to meet expectations of customers, which is pretty dramatic. So having these processes fairly clearly defined and written out is gonna be a huge enabler of success for you with these these AI implementations. And then the last thing that you wanna look at in all of this is the technology, and that's both the data and the system side of things that you wanna be analyzing. And starting with the data, if you're not capturing data in some sort of system of record or some area, like, if you're not you know, even if it's, putting things in filing cabinets, at least there's data there somewhere that you can capture capture and scan in with OCR and things like that. But if you're not capturing data on your business, then how do you expect AI to make decisions or perform processes based on data? It's just not gonna be possible. IBM estimates that bad data cost businesses three point one trillion dollars per year. So what you wanna do is you wanna look at those areas of where you have data in your business. Do you have clean data? Do you have reliable data? Like, what's the integrity of that data? If you can't trust it, then you're not gonna trust the AI then either. And so you wanna make sure you have a solid framework of your data and that you're collecting these things and putting it into a a manner that is reliable and accessible. Accessible. The other side of things is the system. You wanna have transactional systems that are accessible by modern AI applications, meaning that they need to be cloud enabled or AI enabled. So that way these AI tools can hook in and be able to understand what's going on within the system, perform actions on your behalf inside of the system, or do inquiry down into those systems to pull things out. If you have a system which is maybe just paper based, you're literally on a ledger, you know, writing out what your chart of accounts or your financial reports are, AI is not gonna be able to adjust that information or perform actions on your behalf. It's not gonna pick up a pen and and write down the ledger for you. You need to have a system that is cloud enabled or has modern accessibility into it. So looking at things like modern platforms like Microsoft or within, you know, any any modern application really is gonna have these API accessible features. And so you wanna look at it in this way. You wanna start with the people. You wanna go look at your process, and then you wanna look at the technology. And you can look at all three of these main categories as a score and create scorecards across each of how ready you are. And your goal should be able to max out that score. So you should have your people who are excited about the change. You have your power users or your champions identified. You have your organization really mapped out in terms of, like, your org chart, your job descriptions, what you guys do that is all clearly defined. And then within your processes, standard operating procedures across all of your different departments. So what are all those people actually doing, and how can you do this on repeat, those triggers and those actions across your entire business. And then lastly, all your technologies, so the data and the system side of things, how accessible is that data? Are you capturing all that data, ranking that within a scorecard? And then the same thing on the system side, how accessible are those systems? Are those systems about to go end of life, and are they no longer gonna be accessible by AI? You wanna be mapping those things out as well. All of this is really gonna give you a score on how ready you are for AI. And doing this now is gonna set you up for a massive scaling foundation for the future, scalable foundation. You're gonna be able to take advantage of these tools much faster. AI implementation is actually really fast when you have all of these things figured out. When you don't have all these things figured out, it's the same thing as previous system implementations where you gotta figure out all of those things so then you can add in the new system. So I'm excited for you to take advantage of it and follow for more tips.