Transcription
I think most of us have had this moment in the last year. You watch an AI demo. It looks magical, right? It writes the document, it updates the spreadsheet, it navigates the website. You think, okay, so we're basically at the point where this thing can just run parts of my business. And then you try to deploy it and it immediately turns into something much less dramatic. It's a drafting assistant. It's a chat widget. It's a tool that helps but doesn't really do.
It's not because the technology got worse. It's because the demo happened in a world where mistakes don't matter much and your business happens in a world where mistakes can cost real money, real trust, and real careers. And that's that gap. That's what this executive briefing is is all about between what agents can do in a controlled setting and what we're willing to let them do in the real world. That's the most important story of the next two years. And it has a root cause that most of us are not naming. And I want to talk about it today because I haven't heard it discussed like this anywhere else.
We keep talking as if the bottleneck is intelligence. If the models keep improving, they're going to take on more responsibility, right? But the deeper bottleneck is trust. And trust is not about how smart your agent is. Trust is about the structure of decisions in the business environment. In plain language, how bad is it if you're wrong and how can you undo it if you are?
Every meaningful decision in your business lives on one of those two axes, right? Some decisions are low stakes and easy to reverse. If you pick the wrong time for the meeting, you just reschedule it. No big deal. If you organize a file incorrectly, no big deal. You just move it. If a draft memo is off, you can edit it. Right? These are the reversible ones. These are what Amazon would call two-way doors. You can walk through, you can walk back. You want speed here. Overthinking is a waste. You don't want to have people asking for permission. Just do it.
Other decisions are high stakes and hard to reverse, but they're really important. If you send the wrong customer message, you cannot unend it. If you grant the wrong person access to sensitive systems, the damage might already be done. If you commit to a vendor contract, unwinding that can be really expensive or even impossible. Those are one-way doors. If you want frict, you actually intentionally want friction there, right? You want reviews, you want approvals, you want people slowing down on purpose to take time and think about it.
But this is the part that people don't realize that makes the whole agent ecosystem actually click. Software became the easiest place for AI doing work precisely because we spent decades turning a huge number of software decisions into two-way doors. It's like we forgot that we had 30, 40, 50 years of experience turning software into a series of easy to reverse decisions. Things like GitHub are inventions. They're inventions because we wanted reversibility. It's not because software is inherently easy, people. Not because engineers are gullible early adopters. It's because the environment in which we engineer software has been deliberately designed to make software mistakes survivable.
Think about how modern organizations will ship digital products. They don't treat every change like a permanent irreversible commit. They treat changes like proposals that can be tested, monitored, and rolled back. If something goes wrong, the system is designed to recover really quickly. There are built-in steps that lower the consequences of being wrong. Changes are reviewed, often tested automatically, released gradually, watched very carefully, and then reversed if they're needed. The entire culture of modern software delivery is basically one massive project in how do we move fast without breaking everything. This is the only way that you can have multi-,000 engineer developer footprints and get anything done. You have to have reversible decisions.
And this is the part that most of us mess as leaders. That safety infrastructure for software is a huge and hidden reason why agentic progress has felt so fast in engineering in 2025. In software work, there's a universal expectation that you can make a change. You see what you changed, you test it out, and you undo it if it causes harm. That expectation is not a given anywhere else in the rest of your business. It's the result of tens of millions, perhaps billions of human hours invested across the software ecosystem over decades in processes and tools that are all designed to compound and make change less scary. We have spent decades honing the flywheel of software engineering, so it's less scary to change things.
But now look up from software. Look at the wider world. Commerce, operations, finance, HR, legal, compliance, education, healthcare, the physical world. Most of it doesn't work like this. Many actions are not easily reversible. And even when they are theoretically reversible, the reversal is messy because it involves people, it involves exceptions, it involves negotiations, it involves reputational repair. Buying a car is one example. If you buy the wrong car, you can't just undo it. You might be stuck. You might have to sell it at a loss. You might have to fight through a return process. You might have to eat financing fees. In a small number of cases, you get a generous return policy, CarMax style, where the market has a built-in escape hatch, but that escape hatch is itself not free. It exists because companies invested in policies, in logistics, and in fraud controls that make the reversal possible.
Now take the car idea and expand it. Look at business decisions. Most of your organization's important decisions are effectively one-way doors or at least one-way doors once you pass a certain point. Think of it as a commitment curve. Early steps can be undone. Later steps cannot. A vendor selection can be revisited until you sign and begin working together and then you have to wait for the term or there's an escape clause or whatever. A pricing change can be revised until customers receive it and it becomes a public promise. An access change can be corrected unless data has already been downloaded. A compliance filing can get amended sometimes, but you still have to create a record and a paper trail and an adjustment.
This is where we see tool calling and standards like model context protocol in a really different light. People sometimes treat model context protocol as a kind of universal USB plug that lets models connect to many different systems. That that is true and it does matter, but it's really solving a narrower problem. How to make it technically possible for an agent to take action across tools. That's important, but it does not solve the bigger business problem, which is how do you make it safe to delegate actions across tools where actions are hard to reverse?
Essentially, the challenge I have for you, I'm not saying don't build MCP. What I'm saying is tool access does not create trust. And once you see that, a lot of the AI market's recent behavior becomes very obvious to read. This is why so many agents are really co-pilots. They draft, they propose, they fill forms, they generate the plan, they stop before the point of no return because they're not trusted. The design choice isn't just cautious product managers covering their behinds. It's an admission. The real world doesn't have an undo button, and the vendor cannot take the responsibility for irreversible mistakes.
This also explains why the AI safety conversation often feels abstract or overmoralized when the practical issue is much more mundane. Error recovery in software. Error recovery is super normal. It has a name. It has metrics. Great organizations measure how often changes cause problems and then they measure how quickly they can recover when they do. In the rest of the business, recovery is often improvisational. Someone is scrambling. Someone is escalating. someone is doing damage control and that works when humans are the throttle and we can manage all of that ourselves. It does not work when actions can happen at machine speed which is the world we're entering in 2026.
This is the pivot where where this story of agents turns from a technology story really into an institutional and organizational change story. The question becomes, what should remain a one-way door in our businesses and what should become a two-way door? And the uncomfortable truth is we don't really have to answer that question until this year. The uncomfortable thing is for all of corporate history, humans were slow enough that we could make this one-way door work. And so, we're all going to invent it next to each other in 2026.
Humans naturally introduce friction, right? Humans hesitate. Humans double check. Humans feel social anxiety. Humans worry about embarrassment and reputational loss. All of that has acted like an informal safety system in our societies and also more recently in the corporation. It is inefficient, but it has acted as a risk avoidance break. Agents remove that informal safety system. If you give an agent the ability to take an action like sending a message or changing a record or approving a request or moving money, the agent has no reputational risk on the line, the agent doesn't feel a sense of anxiety and go back and triple check. And so it's up to you to either redesign the process so it's safe and reversible or to keep the agent confined to drafting forever. There's not really a stable middle ground in between those two. Either the agent can take the action or it cannot.
So what does red redesigning so it's safe actually mean in a business context? I think it means building a set of very practical non-technical primitives that make more of our actions as a business reversible or at least safely correctable inside our businesses. So the first one I want to suggest and these are absolutely robbed from the software engineering culture and this is part of my larger thesis that the story of 2026 is that there is no technical and non-technical anymore. It is all blurring. It is people using tools to solve problems. And so we're going to steal some of these software engineering principles because they've worked to help software engineering accelerate. We see agents working in software systems. Let's steal those primitives for other parts of the business.
The first one is drafting first. Nothing important should go straight from idea to done. It should go into a proposed state first. A proposed refund, a proposed access change, a proposed vendor onboarding, a proposed customer communication. And that that captures a lot of the value of agency without necessarily crossing the one-way door. Yes, this is not fully the agent taking action, but if you are trying to make progress with your agents, having your agents jump to draft and have have that draft pass all of your evaluations is a great way to get started.
The second one is preview as a primitive. Before any action becomes final, your system should be able to show what the change will look like in plain English. Which customer records will be updated? Which emails will be set? Which accounts will be changed? which permissions will be granted, what data will be shared. In the software world, people are used to seeing here's what changed, here's the diff. In business operations, we rarely get that clarity and it's one reason that leaders have trouble trusting automation and we need to build for that as system designers and we need to insist on it as leaders.
The third primitive I think is time windows. Many actions feel irreversible because they become final instantly. But you can manufacture reversibility by delaying final settlement. So you can schedule customer emails with a recall window. You can make refunds pending for an hour or a day unless the amount is small. You can grant sensitive access as time limited by default. So it expires automatically for an agent unless it's renewed. This is a big unlock because it's mostly process and configuration. It's not fancy AI. And I have two examples here that I think are really relevant. One, Amazon does this with orders. People don't know this, but when you place an order on Amazon, it is intentionally delayed in processing for about half an hour because they want to give you the option to reverse the order as a customer without consequence. And so they could pick it up and take it right away. They opt to wait a half an hour and give you a time window to reverse. The second example is from the app superhum. They know that people tend to read emails and do their checks as humans in reality after we send. And so what they do is they build in a 10 or 15 second reversibility window where you can hit send and they pop up an undo button as soon as you hit send and you can choose to hit undo right away because you're suddenly reading it for the first time because that's how humans work. We check it after it goes live. And so just having that little time window delay is massively helpful.
The fourth primitive I would talk about is repair plans. When something truly cannot be undone, you're going to need a standard playbook for repair. Refunds, apologies, reversing the accounting, rotating your credentials out, notifying affected teams. You kind of get the idea. In business, this is often handled like a fire drill. It's handled ad hoc. For agents to act at machine speed, we have to think about how repair becomes a systematic thing. It doesn't have to be perfect, but it does have to be consistent and systematic.
The fifth primitive is a permanent record. Every agent-driven action should leave behind a simple queryable history. What the agent was trying to do, what information it used, what it changed, what tools it touched, who approved the final step. That's not the purpose of this is not bureaucracy and filling log books. It's it's to make sure that you have accountability and you have learning over time.
I think if you tackle those five primitives, suddenly a lot more of your organization is becoming and is going to become an agent-friendly substrate. Even though it has nothing to do with software engineering, you're pulling software engineering principles into a nonsoftware context. As an example, you'll be able to let agents handle procurement requests up to X threshold automatically because purchases start as drafts and they require approval to commit or because you've approved and seen the accuracy up to X dollars and you're comfortable with the risk. Another example, you can let agents triage your support tickets and draft the responses because sends are staged and gated. Or you can let them draft and send responses up to a certain customer tier. You can let agents handle access requests because access is timelmited and logged. You can let agents prepare financial close packages for the markets because nothing posts without a human commit.
This is why back office operations, I think, are likely to be the first major wave of real agentic delegation. It's not because finance and HR is the most exciting thing for AI to do. It's because those workflows all happen entirely inside systems that you control. You can add drafts. You can add approvals. You can add time windows. You can add logs. You can create two-way doors inside the enterprise envelope. And you can't obviously you can't always do that across the open market.
Now, take the thought experiment there and look at the the the one that I shared earlier, right? What would it take for an agent to buy a car? And look at how we can apply those same primitives to a larger scale. Look at how you would need new market primitives if you really wanted to change this. I'm going outside the enterprise now and I'm saying if we want to step outside back office operations, if we want to see how the market would change, if we want to see what it would take to have a widely agreed substrate for agent commerce, we would need market primitives like standard hold periods, like standardized cancellation terms, like delayed title transfer, like clear dispute resolution, like liability allocation, like machine readable contracts that remove ambiguity. Those are not really model features. They're not really agent tool features. They're not prompt features. They're institutional upgrades. Our marketplace is going to need to become agentic. And only a few very large companies have the ability to shift the market in this way to say this is the new marketplace norm and we want to make this a marketplace norm for commerce and we will shift the market as a result.
And this is where the story gets really big and really interesting. The Asian era is forcing a question that we've been able to avoid for a long long time as a species. How much of our world ought to be designed around reversible commitments versus irreversible ones? For for thousands of years, we have made that decision based on what is socially acceptable to us and what is risk avoidant. For the first time in our species history, with machine speed and machine intelligence, we can now intentionally choose what is the correct allocation of reversible commitments and irreversible commitments.
Some irreversibility is essential, right? It creates trust. It prevents frauds. I'm not saying don't make decisions that are irreversible. I think we have to have them. It makes promises meaningful. But a lot of irreversibility ends up being an artifact of our history and not intentional. As an example, test scores for small children should be more reversible than they are in most cases, especially if the child is dedicated to learning and is retaking the test. That is good for society as a whole because your goal as an outcome is learning. But a and a lot of irrevers irreversibility can be changed if we put the effort in as a society. We don't have to tolerate the legacy processes. We don't have to tolerate paper era institutions. And we don't have to tolerate a world where coordination is measured by the speed at which an envelope runs through a mail system. Right? I still have to deal with aspects of government through the mail. And yes, we've talked about that in the digital era, but really I'm talking about that in the machine intelligence era. How can we make those kinds of things more reversible?
And I am intentionally zooming out here. I know we talked about what leaders can do in their businesses is the most controllable thing, but I want you to get the larger vision because really all we're doing as we build these businesses is we're starting to change our norms as a species around how corporations behave and really long-term around how we expect society to behave. And that's why we're zooming out of agents are a forcing function here because they remove the human throttle. They make it obvious when the world cannot safely absorb mistakes, which is a good thing because then we'll name them as that. But they also make it obvious where we can redesign our systems. So more of reality has that sort of software style safe commit phase. And that means that we stop treating irreversible action as our default way of interacting with the world and we start to treat it as an intentional choice, a design choice that we make in our systems.
So if you're a leader watching this unfold, the practical takeaway is surprisingly direct. Don't start with where can we deploy agents. Start with where can we redesign our decisions so that delegation becomes a safe thing for us to do with agents. Audit your recurring actions. Identify where you have one-way doors in the system. You can build your your draft, your preview, your time windows, your durable records like I was describing. You want to create thresholds intentionally for when you think humans ought to approve. And I would label all of that as building the decision infrastructure that agents can then operate against.
In the end, the organizations that win are not necessarily going to be the ones that have the flashiest AI demos or the ones with the smartest models. We're all going to have the same models. They'll be the ones that make agent actions boring, predictable, bounded, repable. Software learned this over decades.