The RIGHT Way to Handle Broken AI Agents as an Enterprise

What if the broken AI agent you have right now took on a little more work every single month and before you know it, it's easily doing tasks you never trusted to do a year ago? Well, after helping dozens of enterprise companies implement AI in the last couple of years, I can tell you the only thing stopping that is how your team deals with them every time they ask to do something your rules don't allow 'em to do. So in this video, I'm gonna show you exactly how to fix your broken AI agents the right way so that you can do more and more of the work your team is doing manually, and you can see that transition and hand off to your agents. Fewer approval requests is the wrong goal. So look, when one of your agents asks to do something your rules don't allow, somebody on your team gets an approval request or an escalation. And the reason that request feels like a problem is because for years anything that came up to a human actually was a problem. It required the human to make a decision. Something in the business broke, it went to IT, somebody fixed it, and then everyone just moved on. The email system went down, a server dropped, a report stopped running, and wanting fewer of those occurrences was the right instinct. But an agent sending you an approval request is a completely different thing because nothing broke. The agent looked at the numbers and context in front of it, picked what it thought was the best move, and one of your rules wouldn't let it proceed, so it stopped. And that's the agent doing exactly what you set it up to do. Now Most teams still want fewer approval requests the same way they wanted fewer IT problems. If you're counting requests as failures, the number you're going for is zero. And you can always get to zero because you can take the option away from the agent and the request just stops happening. But you never find out whether the thing the agent asked for was actually a good idea. So here's what you might not realize. The leaders getting the most out of their agents want more of these requests coming in, not fewer of them. Because an agent only sends an escalation or a request when the decision it wants to make is something your rules don't allow. So every request you get is a chance to check whether that rule is still right. Every escalation is a chance to learn, lean in, and try to ask why the agent wants to break the rules. The leaders that take this approach use these moments to investigate and ask better questions, and they're the ones finding incremental opportunities for their business. They find new ways to automate more work, new ways to enhance capabilities and provide more services to their team and to their customers. The 3 reasons an agent gets stopped. All right, so let's take an example of an approval request you might get. So you've got an agent handling contract renewals, for example, and it goes to renew a vendor you've been with for years, and the renewal comes up over your $250,000 approval limit. So the agent stops and sends the request to a person. Now, when somebody actually looks into the request, There are only 3 things they can find, and each one has a different way to resolve it. First off, the rule could be out of date. You get that $250,000 limit, but it was set years ago. Now the company is 3 times larger, and a renewal like that used to be a big deal. Today, it clears that limit every single year, and every year somebody signs off on it in about 2 seconds without thinking twice. So in this situation, maybe you want to raise the limit, and from then on, the agent can handle that type of renewal on its own. The second thing you might find is that the rule's actually right, but nobody ever wrote down what it was intended for. So the limit exists because the contract that size needs a second person reading the terms, and that's a good reason, but the reason was never written anywhere the agent can read. So it has no way to tell the difference between a renewal at the same terms and a brand new contract at a bigger number. What you, you do here is write the condition into the rule, and now the agent only asks when the terms have changed. actually changed, not just when it's over the $250,000 limit. And the third thing is that the renewal really is a problem. Maybe the price went up 40% since last year, or a clause changed that nobody caught. That's the rule doing exactly what it was built for, and you found it before anybody signed. Now look at what you end up with in each of these 3 situations. In the first one, you fixed a rule been costing your team every year. In the second, your agent takes on work it couldn't do before, so now you're saving yourself time, you're more efficient. In the third, you caught a bad contract before it went through. So whichever one of those three you find, you end up better off than you were before that agent got stopped. And if you lean in, you can adjust these rules in real time. So who should be answering? The next question is who that request should go to. In most organizations, the answer is still whoever's on the rotation that week. That made sense when the thing coming up was technical problem because any competent person on the team could attack it and fix it. But when the agent's handling a contract renewal that gets stopped by your $250,000 approval limit, what its request is really asking is whether that limit is still right for the company of your size. And that's not a question the IT team clearing out the queue can answer, no matter how good they are at their job. They can approve or deny it because that's what the screen in front of them is asking for, but they can't raise the limit. And they're not the person who would ever think to ask if the rule's still correct with the context of the transaction and the business intent. More so they're unlikely to ask the deeper questions that uncover the aha breakthrough opportunities to add more efficiency by updating the rule, making it clearer. So one of the first things that has to change is who the request goes to. It should be the person who could actually change the rule that actually stopped that agent. So you need these approvals and escalations to go where expertise and authority merge together. That's where the experts on the topic can make the right decisions and also have the broader context to ask the right questions. It's also where someone with enough authority that can approve the decision or the need to deploy a change or sponsor the next idea or sponsor that change. So for a spending limit, that might be whoever manages the budget or a contract term, it might be legal. And for anything about how the work gets done, it's whoever runs that part of the business. And it might require more than one person to collaborate with on this approval or asking the right questions about why this escalation was triggered and what might we learn from it. And then What might we do with those learnings to improve how your agents work and how your team works with them? This has to be super efficient or you won't do it. The second thing to change is how much comes with the approval request or escalation attached to it, because whoever is deciding needs 3 things on the same screen. What the agent was looking at when they made the call, the context. This is called the agent context window. So they can see the actual numbers, data points, etc. And it may need to be presented differently to different roles. Roles and people that it's escalated to based upon what agent was escalating and what it was trying to perform in the workflow. For example, a finance team member may need the numbers presented. A legal team may need to see the conflicting terms that were identified across the multiple contracts. Which rule triggered it is really important so that they know what might need to be looked into that created the escalation in the first place and why it was assigned to them specifically. That last one matters a ton because if the request tells you it came because you approved the last 3 contracts with the same vendor, you know in like 5 seconds why you're the right person to answer it. But without that, the first thing you have to do on every request is figure out why it came to you in the first place. And some approval requests, they're obviously— they're going to need potentially more than one person to make the decision, answer the question. So you got to definitely plan for that and how your system works. Say the contract doesn't say clearly whether a renewal is annual or monthly, so the agent has no way to which one applies. Your CFO's office would probably be deciding which one you actually want, and your general counsel's team would be making sure the contract actually says that. Once both of them sign off, the agent gets one answer it can act on. Now, I built my platform Force Equals to handle all of these scenarios on the same screen— the numbers the agent was working from, the rule that stopped it, and why it came to you. It connects to the agents you already have, whether they're running already, so if So that way nothing has to be rebuilt or migrated. With that said, let me show you what one of these requests looks like when it reaches the right person. So this right here is the contract renewal, and everything I need to decide is right here. I can see the renewal amount that the agent's working with, the $250,000 limit that stopped it, and right underneath, the reason it came to me— because I signed off on the last 3 contracts with this vendor. I can click in for more context if I need more information, and I can take action right here from the card. And this is where those 3 reasons from earlier turn into 3 different buttons. If the contract's fine, I approve it. If it's a problem, I deny it. And if the rule is the thing that's wrong, or if I have a question, or I get a good idea, I can capture all this with the context right here and start that change instead of the request just disappearing the second somebody deals with it. So capturing this idea, this need for a change in this moment is hypercritical because then I can apply those updates that improve my efficiency, improve how the system operates with my team. And furthermore, if I need to ask why the agent made a decision or get deeper details from that agent, or frankly any set of agents or any agent in your enterprise system, I can just chat with them right here in one place. So maybe I want to know how many times the same type of situation happen in the last week? Maybe I wanna find out if what likely would happen if I changed how the rule worked. The AI in this system will help dig out all those answers, capture it so that you can start improving. By the way, if you wanna try out FourSQLs for yourself, I'll leave a link to it in the top of the description where you can get started for free. Why you should look into every request. Now what happens at most organizations is somebody looks into the requests that sound risky and just approves the rest. A request about a multimillion A million-dollar contract gets read really carefully, and a request about a routine renewal gets approved in a couple of seconds. It might make sense because a mistake on a bigger contract can potentially cost a lot more money. But the rules you'd actually want to fix are almost never the ones that are the risky ones. Usually those are right. An out-of-date rule doesn't look dangerous; normally looks routine, which is exactly why nobody's questioned it in three. 3 years. That $250,000 limit never blocked a bad contract. It just added an extra approval into a renewal that was completely fine. So the thing to be worried about here is whether looking into all of them slows your team down. And it would if every request meant somebody had to go figure out what the agent was doing, which rule stopped it, who owns it. That part takes the longest, and at a lot of companies it takes days because the answer is spread across 3 or 4 different systems buried audit logs among thousands of transactions. But once every request shows up in the exact same place with all the context, all the numbers, and the rule already attached, there's nothing left to figure out. Somebody can access the context, understand the rule, and sign off on an approval or start the process to change something. And it happens in a matter of minutes. So you end up looking into more of these issues and spending less time on each one, improving little by little every single day, finding new opportunities for automation, new opportunities to improve your efficiency and get more value out of your investments. And once every request is in one place, you can start confidently adding agents without wondering what they're all doing. What holds a lot of leaders back from adding more is the fact that they can't see the ones they already have. Have and figure out what they're really doing. And if you can't see them, you can't operate them. But once you see all of them in one place, the next agent you add just sends its request to the same place as all the others, and you get to operate them efficiently, intelligently, with a mindset to ask more questions to help improve. So you've got 2 options every time an approval request comes in going forward. Either you can keep saying no every time an agent asks for something, you can tighten down and further restrict what your agents are able to do, and your agents will do less and less work every year. Or you can intelligently look into every request that comes in, and every month a few more of your rules will be more right. Your agents will be able to take on a little bit more work all the time, and your team will have to do less and less manual intervention, and you'll uncover more and more opportunities to improve your business. Now, going down that second path means every request an agent sends has to end up somewhere a person can actually do everything we just talked about. And that's what I built Force Equals for. Solving this problem required a brand new purpose-built platform, so I'll leave a link to it at the top of the description where you can get started on this for free. Force Equals is purpose-built for this exact moment, helping teams Deploy and operate AI agents in their business. It connects to the agents you already have running and intelligently routes every request to the right person who can answer it with the agent's numbers, the context, the rules, the policies and guardrails that stopped and created that escalation all together, so you can make efficient decisions, trigger agent actions, and improve your environment every single day. And when the rule turns out to be the thing that you need to change, you can do that from the same screen. So again, you can get started with FourSquares for free by clicking the first link in this video. And if you wanna see how to control every agent you're running as you add more and more of them, check out this next video.