One-Way vs Two-Way AI Decisions
Key Points
- AI demos often feel magical, but real‑world deployments falter because businesses can’t afford the mistakes that are acceptable in a controlled demo environment.
- The true bottleneck isn’t model intelligence but trust, which hinges on how risky a decision is and how easily it can be undone.
- Reversible, “two‑way‑door” tasks (e.g., scheduling, file organization) benefit from fast, frictionless AI assistance, while irreversible, “one‑way‑door” tasks (e.g., sending customer communications, granting access) require deliberate checks and approvals.
- Decades of software design have turned many business actions into easy‑to‑reverse decisions, creating the fertile ground that now lets AI agents handle low‑stakes work effectively.
- Scaling AI agents across enterprises will depend on building governance structures that embed the right amount of friction for high‑stakes decisions while preserving speed for low‑stakes ones.
Sections
- From Demo Magic to Real‑World Trust - The speaker explains that the real barrier to deploying AI agents isn’t model intelligence but the lack of trust stemming from business risk and decision‑making structures.
- Safety Infrastructure Enables Rapid Change - The speaker describes how modern software delivery relies on reversible, automated, and closely monitored change processes that lower risk and allow huge engineering teams to innovate quickly—an advantage not yet common in most other business areas.
- Beyond Tool Access: Trust and Safety - The speaker argues that while model context protocols enable agents to use tools, the real business challenge lies in ensuring safe, reversible actions and robust error‑recovery rather than simply providing connectivity.
- Applying Software Primitives to Business Ops - The speaker proposes adopting software engineering practices—drafting before execution, visual previews, and bounded time windows—to make business automation more transparent and trustworthy.
- Agentic Delegation in Back‑Office Ops - Applying software‑engineered controls such as drafts, approvals, and logging enables AI agents to responsibly automate procurement, support, access, and financial tasks, making back‑office operations the first wave of accountable, low‑risk AI delegation.
- Redesigning Decisions for Safe AI - The speaker urges leaders to prioritize redesigning decision processes—making actions reversible and audit‑able—so that delegating to AI agents becomes a safe, intentional design choice rather than the default.
Full Transcript
# One-Way vs Two-Way AI Decisions **Source:** [https://www.youtube.com/watch?v=7NjtPH8VMAU](https://www.youtube.com/watch?v=7NjtPH8VMAU) **Duration:** 00:19:50 ## Summary - AI demos often feel magical, but real‑world deployments falter because businesses can’t afford the mistakes that are acceptable in a controlled demo environment. - The true bottleneck isn’t model intelligence but trust, which hinges on how risky a decision is and how easily it can be undone. - Reversible, “two‑way‑door” tasks (e.g., scheduling, file organization) benefit from fast, frictionless AI assistance, while irreversible, “one‑way‑door” tasks (e.g., sending customer communications, granting access) require deliberate checks and approvals. - Decades of software design have turned many business actions into easy‑to‑reverse decisions, creating the fertile ground that now lets AI agents handle low‑stakes work effectively. - Scaling AI agents across enterprises will depend on building governance structures that embed the right amount of friction for high‑stakes decisions while preserving speed for low‑stakes ones. ## Sections - [00:00:00](https://www.youtube.com/watch?v=7NjtPH8VMAU&t=0s) **From Demo Magic to Real‑World Trust** - The speaker explains that the real barrier to deploying AI agents isn’t model intelligence but the lack of trust stemming from business risk and decision‑making structures. - [00:03:15](https://www.youtube.com/watch?v=7NjtPH8VMAU&t=195s) **Safety Infrastructure Enables Rapid Change** - The speaker describes how modern software delivery relies on reversible, automated, and closely monitored change processes that lower risk and allow huge engineering teams to innovate quickly—an advantage not yet common in most other business areas. - [00:06:20](https://www.youtube.com/watch?v=7NjtPH8VMAU&t=380s) **Beyond Tool Access: Trust and Safety** - The speaker argues that while model context protocols enable agents to use tools, the real business challenge lies in ensuring safe, reversible actions and robust error‑recovery rather than simply providing connectivity. - [00:10:11](https://www.youtube.com/watch?v=7NjtPH8VMAU&t=611s) **Applying Software Primitives to Business Ops** - The speaker proposes adopting software engineering practices—drafting before execution, visual previews, and bounded time windows—to make business automation more transparent and trustworthy. - [00:13:41](https://www.youtube.com/watch?v=7NjtPH8VMAU&t=821s) **Agentic Delegation in Back‑Office Ops** - Applying software‑engineered controls such as drafts, approvals, and logging enables AI agents to responsibly automate procurement, support, access, and financial tasks, making back‑office operations the first wave of accountable, low‑risk AI delegation. - [00:17:53](https://www.youtube.com/watch?v=7NjtPH8VMAU&t=1073s) **Redesigning Decisions for Safe AI** - The speaker urges leaders to prioritize redesigning decision processes—making actions reversible and audit‑able—so that delegating to AI agents becomes a safe, intentional design choice rather than the default. ## Full Transcript
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.