WEBVTT

00:00:00.000 --> 00:00:00.960
I approved the email.

00:00:01.460 --> 00:00:02.260
Then I changed the attachment.

00:00:02.760 --> 00:00:03.900
Which version should the agent send?

00:00:04.260 --> 00:00:05.960
Here’s my rule. Show me the final
package.

00:00:06.400 --> 00:00:07.560
Get my decision on that version.

00:00:08.020 --> 00:00:09.080
Then bring back the receipt.

00:00:09.860 --> 00:00:11.060
Claude Duet got me thinking about this.

00:00:11.720 --> 00:00:14.180
Anthropic says it can prepare work in
the background and ask

00:00:14.180 --> 00:00:17.460
before important actions. That opens up
real possibilities for business

00:00:17.460 --> 00:00:19.780
owners. We turned that announcement into
a case study.

00:00:20.300 --> 00:00:22.780
This is public-source analysis, not a
product test.

00:00:23.400 --> 00:00:24.260
Let’s walk through an example.

00:00:24.820 --> 00:00:25.900
An agent drafts a client email.

00:00:26.360 --> 00:00:28.920
I approve it. Then I change the
recipient and swap the

00:00:28.920 --> 00:00:30.580
attachment. Watch those two fields.

00:00:31.240 --> 00:00:32.660
The person receiving the information
changed.

00:00:33.240 --> 00:00:34.660
The information leaving the business
changed.

00:00:35.380 --> 00:00:37.440
My earlier approval should not silently
carry over.

00:00:37.860 --> 00:00:38.960
The proposed workflow is simple.

00:00:39.500 --> 00:00:40.200
Prepare the final action.

00:00:40.700 --> 00:00:42.320
Show the recipient, message and
attachment.

00:00:42.920 --> 00:00:44.520
Ask for a decision on that exact
package.

00:00:44.520 --> 00:00:46.080
Recheck permission before sending.

00:00:46.940 --> 00:00:48.100
Then verify what actually happened.

00:00:48.600 --> 00:00:50.000
Our case study proposes four checks.

00:00:50.700 --> 00:00:51.640
Change the draft or attachment.

00:00:52.300 --> 00:00:53.940
Does the workflow pause for a fresh
decision?

00:00:54.500 --> 00:00:57.040
Change the recipient. Does the approval
show the final destination?

00:00:57.960 --> 00:01:00.620
Revoke permission. Does the action stop
and explain why?

00:01:01.120 --> 00:01:02.520
Let the send time out.

00:01:02.520 --> 00:01:04.680
Does the system check the first attempt
before trying again?

00:01:05.280 --> 00:01:06.080
That last one matters.

00:01:06.640 --> 00:01:08.660
A timeout does not tell you whether the
email was sent.

00:01:09.160 --> 00:01:11.700
For the receipt, I want the final
recipient, the message identifier

00:01:12.360 --> 00:01:15.320
and the time. Enough to connect the
action I approved with

00:01:15.320 --> 00:01:16.420
the result we can actually verify.

00:01:16.960 --> 00:01:18.280
Those are proposed acceptance checks.

00:01:18.820 --> 00:01:21.160
We haven’t run them against Duet, and
we’re not claiming the

00:01:21.160 --> 00:01:25.040
product failed them. That’s the focus
behind Whitewater AIOS and the

00:01:25.040 --> 00:01:29.600
WWAIOS framework. Make the evidence,
permissions and decision behind an AI

00:01:29.600 --> 00:01:31.140
action visible and defensible.

00:01:31.880 --> 00:01:33.640
Reduce distortion between reality and
decision.

00:01:34.400 --> 00:01:36.320
Take the four checks in the case study
and apply them

00:01:36.320 --> 00:01:37.480
to one workflow you’re considering.

00:01:38.240 --> 00:01:39.120
Keep the decision visible.

00:01:39.980 --> 00:01:40.560
Bring back the receipt.