WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=BInpv7lGp1o

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/BInpv7lGp1o.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:01.309 --> 00:00:03.309
[music]

s2
00:00:13.040 --> 00:00:16.240
Thank you for choosing to spend this session with me.

s3
00:00:16.240 --> 00:00:19.439
My goal today is simple.

s4
00:00:19.439 --> 00:00:27.199
I want to convince you all that most of the production failures are not most of most of the agent failures are not model failures.

s5
00:00:27.199 --> 00:00:29.119
Those are harness failures.

s6
00:00:29.119 --> 00:00:32.559
So let's start with one production incident.

s7
00:00:32.559 --> 00:00:34.480
The user saw the reply.

s8
00:00:34.480 --> 00:00:36.719
The system forgot it happened.

s9
00:00:36.719 --> 00:00:39.280
This is a failure shape I want to start with.

s10
00:00:39.280 --> 00:00:43.280
Not a hallucination, not a crash, not a bad answer.

s11
00:00:43.280 --> 00:00:50.160
The user visible edge looked healthy while the durable record had a hole.

s12
00:00:50.640 --> 00:00:58.320
In this example, the user asked the customer the agent to remember a refund for a customer.

s13
00:00:58.320 --> 00:01:02.079
The assistant said it recorded the fact for the next turn.

s14
00:01:02.079 --> 00:01:03.840
The interface looked normal.

s15
00:01:03.840 --> 00:01:06.799
No red screen, no obvious failures.

s16
00:01:06.799 --> 00:01:09.840
But the next turn cannot reconcept the fact.

s17
00:01:09.840 --> 00:01:11.840
The user experienced success.

s18
00:01:11.840 --> 00:01:15.600
The system inherited incomplete reality.

s19
00:01:16.720 --> 00:01:18.240
Why this matters?

s20
00:01:18.240 --> 00:01:22.000
The crash is annoying, but at at least it gives you a boundary.

s21
00:01:22.000 --> 00:01:24.560
You know some you know something stopped.

s22
00:01:24.560 --> 00:01:26.799
You usually see an error.

s23
00:01:26.799 --> 00:01:30.400
You can often start from last known good point.

s24
00:01:30.400 --> 00:01:32.720
Silent success gives you a lie.

s25
00:01:32.720 --> 00:01:36.320
Delivery can succeed while the persistent fails.

s26
00:01:36.320 --> 00:01:40.799
The user has no reason to doubt the reply.

s27
00:01:40.799 --> 00:01:43.520
The operator has no obvious alarm.

s28
00:01:43.520 --> 00:01:53.840
The next turn can still sound confident because the model is coherent but it is coherent over a broken history.

s29
00:01:53.840 --> 00:01:56.880
That is why agent reliability matters.

s30
00:01:56.880 --> 00:02:01.200
and agent relity cannot stop at model quality.

s31
00:02:01.680 --> 00:02:03.360
Hi, I'm Ben.

s32
00:02:03.360 --> 00:02:07.920
I work on core data and AI infrastructure at OpenAI.

s33
00:02:07.920 --> 00:02:12.080
Before that, I worked on distributed systems at Apple and Uber.

s34
00:02:12.080 --> 00:02:20.560
Outside of the work, I write the agent stack where I try to explain how the production AI and data systems work under the hood.

s35
00:02:20.560 --> 00:02:25.120
I'm daughter of OpenClaw and this is not a openclaw product pitch.

s36
00:02:25.120 --> 00:02:27.599
This is a pure system design talk.

s37
00:02:27.599 --> 00:02:38.480
I'm using open claw as a public case study because its issues code docs makes the harness around the agent unusually visible.

s38
00:02:38.959 --> 00:02:41.519
Here's a production contract for the talk.

s39
00:02:41.519 --> 00:02:46.640
A model proposes the harness commits and the receipts proves it.

s40
00:02:46.640 --> 00:02:51.760
The model can may suggest a message, a tool, a edit or an command.

s41
00:02:51.760 --> 00:02:54.000
But model is not the production boundary.

s42
00:02:54.000 --> 00:03:02.319
The harness owns the state transition, the authority check, the ordered commit and the receipt is the evidence that survives the term.

s43
00:03:02.319 --> 00:03:06.480
Open clause is the case study and the contract is the takeaway.

s44
00:03:07.280 --> 00:03:10.800
If you remember only three things from this talk, make it these.

s45
00:03:10.800 --> 00:03:16.239
Own the state, order the mutation and prove the action.

s46
00:03:16.239 --> 00:03:19.440
A fact needs only one owner and one replay path.

s47
00:03:19.440 --> 00:03:25.280
Shared mutable state needs one ordered commit path and transcript is not the proof.

s48
00:03:25.280 --> 00:03:27.920
A transcript tells you what the agent said.

s49
00:03:27.920 --> 00:03:35.760
A receipt tells you what the system allowed, attempted, executed and what the user visible edge confirmed.

s50
00:03:36.959 --> 00:03:42.239
To create a simple mental model, I created this car analogy of the harness.

s51
00:03:42.239 --> 00:03:44.720
The model is the engine.

s52
00:03:44.720 --> 00:03:46.640
It matters a lot.

s53
00:03:46.640 --> 00:03:52.000
But nobody buys a production car by just looking at the horsepower alone.

s54
00:03:52.000 --> 00:03:58.480
You also care about steering, brakes, road rules, dashboard, and a black box.

s55
00:03:58.480 --> 00:04:03.439
The model gives you capability, but the harness gives you control.

s56
00:04:03.439 --> 00:04:06.159
A powerful engine with no brakes is not autonomy.

s57
00:04:06.159 --> 00:04:09.519
It is a liability with good acceleration.

s58
00:04:09.680 --> 00:04:15.920
Here is the harness blueprint I wanted to uh discuss today.

s59
00:04:15.920 --> 00:04:27.840
Every agent we know of like personal agents such as open claw or Hermes, coding agents such as codeex, cursor, open code or cloud code uses the same underlying architecture.

s60
00:04:28.080 --> 00:04:36.080
Events enter from many surfaces a chat, web hook, timer or heartbeat or another external system.

s61
00:04:36.080 --> 00:04:43.360
The control plane maps the events to a session key and the session key determines the state boundary.

s62
00:04:43.360 --> 00:04:47.759
The session lane gives you one active writer for that mutable state.

s63
00:04:47.759 --> 00:04:50.400
The runtime calls the models and tools.

s64
00:04:50.400 --> 00:04:55.759
Tools act through approvals and policies and audit rail becomes the run receipt.

s65
00:04:55.759 --> 00:05:00.320
This is the blueprint event session key throttle tools audit.

s66
00:05:00.320 --> 00:05:06.160
The blueprint is a talk and the incident of the proof that each boundary matters.

s67
00:05:08.160 --> 00:05:16.000
context is assembled uh in agent runtime does not usually remember in human sense.

s68
00:05:16.000 --> 00:05:18.000
It is stateless.

s69
00:05:18.000 --> 00:05:21.919
The harness rebuilds the working state for the each turn.

s70
00:05:21.919 --> 00:05:28.813
The working set may include the transcript, session state, memory, policy, tool definitions.

s71
00:05:28.813 --> 00:05:32.639
[clears throat] The model only sees what the harness supplies.

s72
00:05:32.639 --> 00:05:37.759
If one input is missing or stale, the answer may still sound coherent.

s73
00:05:37.759 --> 00:05:41.840
Coherence does not proves the working set was complete.

s74
00:05:43.199 --> 00:05:44.880
These failures are not new.

s75
00:05:44.880 --> 00:05:52.000
We already know about timeouts, retries, item potency, locks, ordering, and state ownership.

s76
00:05:52.000 --> 00:05:55.120
What change is the agent setting?

s77
00:05:55.120 --> 00:05:59.120
Now these failures sit around a probabilistic planner with dynamic plans.

s78
00:05:59.120 --> 00:06:01.840
It's rebuilding the context for every turn.

s79
00:06:01.840 --> 00:06:06.880
there are more event sources and it can act through more action surfaces.

s80
00:06:06.880 --> 00:06:13.520
So these failures are familiar agents makes them easier to trigger and harder to explain.

s81
00:06:13.520 --> 00:06:17.120
That's why agent harness matters.

s82
00:06:18.560 --> 00:06:22.560
Let's talk about the first failure mode.

s83
00:06:27.360 --> 00:06:31.759
This is the same failure mode I started this talk with.

s84
00:06:31.759 --> 00:06:33.280
The user sees a success.

s85
00:06:33.280 --> 00:06:35.840
The source of truth cannot replay it.

s86
00:06:35.840 --> 00:06:38.639
Delivered is not remembered.

s87
00:06:38.880 --> 00:06:48.160
In this stateole open claw issue, a telegram reply could succeed while the router turn was not written to the active context or transcript.

s88
00:06:48.160 --> 00:06:49.600
The user saw the response.

s89
00:06:49.600 --> 00:06:52.000
The log looked healthy.

s90
00:06:52.000 --> 00:06:55.680
But the next turn had no durable record of the next change.

s91
00:06:55.680 --> 00:06:57.840
A successful send proves transcript.

s92
00:06:57.840 --> 00:07:00.400
It does not prove the future context.

s93
00:07:00.400 --> 00:07:06.479
That distinction matters because the model can answer fluently over an incomplete record.

s94
00:07:06.479 --> 00:07:08.800
The missing boundary was not intelligence.

s95
00:07:08.800 --> 00:07:11.759
It was the state ownership.

s96
00:07:12.960 --> 00:07:15.680
By owner, I do not mean a person.

s97
00:07:15.680 --> 00:07:20.160
I mean the system of record whose persistent state becomes the truth.

s98
00:07:20.160 --> 00:07:22.720
A calendar event belongs to the calendar system.

s99
00:07:22.720 --> 00:07:25.199
A support status belong to the ticketing system.

s100
00:07:25.199 --> 00:07:35.520
While a code change belongs to a workspace or repository on a conversation turn belongs to a session transcript and a user preference belongs to a memory store.

s101
00:07:35.520 --> 00:07:37.360
Storage tells you where the bytes live.

s102
00:07:37.360 --> 00:07:41.280
Ownership tells you who can reconstruct the reality.

s103
00:07:43.120 --> 00:07:47.759
A replay is not a reliable memory until until a named owner can replay it.

s104
00:07:47.759 --> 00:07:50.000
A system has to persist the turn.

s105
00:07:50.000 --> 00:07:55.599
It has to name the owner or system of record and it has to make the replay possible.

s106
00:07:55.599 --> 00:07:57.520
The question is simple.

s107
00:07:57.520 --> 00:08:04.479
For every fact the agent might use later, who owns it and how would you replay it?

s108
00:08:04.479 --> 00:08:10.639
If no owner can replay the fact, this the system did not reliably remember it.

s109
00:08:11.599 --> 00:08:18.160
Once we know who owns the state, the next question is who's allowed to change it and in what order?

s110
00:08:18.400 --> 00:08:22.400
Two correct rights can still produce one wrong outcome.

s111
00:08:22.400 --> 00:08:26.639
and last writer wins is not a consistency model.

s112
00:08:28.639 --> 00:08:34.479
In this overlapping writer open claw issue describes a load modify save race.

s113
00:08:34.479 --> 00:08:37.360
Two callers loads the same old state.

s114
00:08:37.360 --> 00:08:39.279
Each changes a different record.

s115
00:08:39.279 --> 00:08:43.839
The sil the second save silently erases the first.

s116
00:08:43.839 --> 00:08:48.320
The user may see a dismissed commitment return or receive a duplicate follow-up.

s117
00:08:48.320 --> 00:08:50.320
Neither writer is malformed.

s118
00:08:50.320 --> 00:08:52.560
Both operations are locally correct.

s119
00:08:52.560 --> 00:08:56.480
The missing boundary is civilization around the commit.

s120
00:08:58.000 --> 00:09:00.320
The invariant is not no concurrency.

s121
00:09:00.320 --> 00:09:03.040
That would be too slow and it would miss the point.

s122
00:09:03.040 --> 00:09:05.200
You can fan out sub agents.

s123
00:09:05.200 --> 00:09:06.399
Parallel reads are fine.

s124
00:09:06.399 --> 00:09:08.480
Independent retrieval is fine.

s125
00:09:08.480 --> 00:09:11.200
Many sessions can also run at once.

s126
00:09:11.200 --> 00:09:13.600
The rule is narrower and simple.

s127
00:09:13.600 --> 00:09:17.440
One ordered commit path for one mutable state boundary.

s128
00:09:17.440 --> 00:09:22.000
This mechanism may be a Q, a mutx, a transaction or a lock.

s129
00:09:22.000 --> 00:09:27.920
You can use locks or mutx across the sessions and cues or transactions within a session.

s130
00:09:27.920 --> 00:09:33.200
Be conservative of the commit time and not across the whole system.

s131
00:09:34.720 --> 00:09:37.200
Users do not see cues or locks.

s132
00:09:37.200 --> 00:09:39.200
They see behavior.

s133
00:09:39.200 --> 00:09:41.839
A last correction feels forgetful.

s134
00:09:41.839 --> 00:09:44.000
A stuck lane feels dead.

s135
00:09:44.000 --> 00:09:47.200
And completion before delivery feels confused.

s136
00:09:47.200 --> 00:09:53.360
Ordering is a product feature because users experience ordering books as personalities.

s137
00:09:55.600 --> 00:09:58.000
Now let's talk about time in production.

s138
00:09:58.000 --> 00:10:00.240
Silence cannot be neutral.

s139
00:10:00.240 --> 00:10:01.120
Let's review.

s140
00:10:01.120 --> 00:10:05.760
Uh the next uh failure mode is life cycle failure mode.

s141
00:10:05.760 --> 00:10:08.560
The run waits for an event that cannot arrive.

s142
00:10:08.560 --> 00:10:11.680
Silence is not a terminal state.

s143
00:10:12.399 --> 00:10:18.640
In this dangling tool call issue, the session contains a tool call but no matching tool result.

s144
00:10:18.640 --> 00:10:20.560
A process may have died.

s145
00:10:20.560 --> 00:10:22.000
The connection may have dropped.

s146
00:10:22.000 --> 00:10:26.399
A timeout might have happened before the results were recorded.

s147
00:10:26.399 --> 00:10:29.600
The exact cause uh matters for debugging.

s148
00:10:29.600 --> 00:10:32.399
The production failure is much simpler.

s149
00:10:32.399 --> 00:10:36.079
The run is waiting for a event that will never arrive.

s150
00:10:36.079 --> 00:10:39.120
New messages cue behind that silence.

s151
00:10:39.120 --> 00:10:43.600
To the user, the agent simply looks stuck.

s152
00:10:45.279 --> 00:10:47.440
Runs needs deadlines and cancellation.

s153
00:10:47.440 --> 00:10:49.600
A deadline bounds the weight.

s154
00:10:49.600 --> 00:10:52.320
Watchdog makes the stuck work visible.

s155
00:10:52.320 --> 00:10:54.800
Tools needs time modes and error results.

s156
00:10:54.800 --> 00:11:00.320
Channels needs recovery commands that do not wait behind the stuck work they are trying to fix.

s157
00:11:00.399 --> 00:11:02.880
Every external boundary needs an ending.

s158
00:11:02.880 --> 00:11:08.320
Success, failure, timeout, cancel, or max attempts.

s159
00:11:08.320 --> 00:11:11.920
Most importantly, the receipt records the terminal outcome.

s160
00:11:11.920 --> 00:11:14.800
So the next step does not have to guess.

s161
00:11:14.800 --> 00:11:18.480
Bound the work before the work bounds you.

s162
00:11:19.040 --> 00:11:26.320
Now let's uh we can move on from state to authority because a chat becomes risky when it becomes an action.

s163
00:11:26.320 --> 00:11:28.320
Capability is not execution.

s164
00:11:28.320 --> 00:11:30.320
The model can request an action.

s165
00:11:30.320 --> 00:11:32.399
Requestability is not authority.

s166
00:11:32.399 --> 00:11:35.279
Approval needs a shape.

s167
00:11:35.519 --> 00:11:41.279
In this approval drift issue, expired approved call back was stated as retraable.

s168
00:11:41.279 --> 00:11:46.720
The state call back state durable served restarts and blocked later channel work.

s169
00:11:46.720 --> 00:11:48.320
The battle click existed.

s170
00:11:48.320 --> 00:11:50.399
The valid authority did not.

s171
00:11:50.399 --> 00:11:51.839
This is the mistake.

s172
00:11:51.839 --> 00:11:57.120
Treating approval as a vague memory that the human was near the system or clicked yes.

s173
00:11:57.120 --> 00:12:02.560
Approval as a scoped execution state, it must stay bound to the action it authorized.

s174
00:12:02.560 --> 00:12:06.399
An expiration must terminate rather than loop.

s175
00:12:07.600 --> 00:12:20.240
A useful approval object answers who approved in what session and run for which tool and for which arguments and for how long and with what outcome.

s176
00:12:20.399 --> 00:12:22.240
It also point to the receipt.

s177
00:12:22.240 --> 00:12:32.959
If those fields fall off during a retry replay or a channel call back the harness can no longer prove the action was being executed is the action being approved.

s178
00:12:34.160 --> 00:12:35.920
The general lesson is simple.

s179
00:12:35.920 --> 00:12:38.880
Capability is not execution.

s180
00:12:38.880 --> 00:12:41.360
Least privileges narrows the tool surface.

s181
00:12:41.360 --> 00:12:45.200
Scoped credentials ensures the right identity is used for the action.

s182
00:12:45.200 --> 00:12:49.680
Approval and audit decides what happens before and after the execution.

s183
00:12:49.680 --> 00:12:53.600
The model can reason about the boundary but it should not be the boundary.

s184
00:12:53.600 --> 00:12:58.320
The model can request but the still the system decides.

s185
00:13:00.160 --> 00:13:05.200
Finally, even if the tool says success, the user visible B may disagree.

s186
00:13:05.200 --> 00:13:07.040
Internal component reports success.

s187
00:13:07.040 --> 00:13:09.519
The user visible surface shows nothing.

s188
00:13:09.519 --> 00:13:11.120
This is the inverse of the opening incident.

s189
00:13:11.120 --> 00:13:15.519
We saw in this missing edging edge proof issue.

s190
00:13:15.519 --> 00:13:21.440
The message tool reported success for a web chat or TUI run, but the message did not render.

s191
00:13:21.440 --> 00:13:23.519
Normal assistant reply still appeared.

s192
00:13:23.519 --> 00:13:27.120
The tool proved that the internal path accepted the request.

s193
00:13:27.120 --> 00:13:29.839
It does not prove the user saw the result.

s194
00:13:29.839 --> 00:13:31.839
That difference change the conversation.

s195
00:13:31.839 --> 00:13:34.959
The agent may later say, "I already sent it."

s196
00:13:34.959 --> 00:13:37.760
And the user may truthfully say, "I never saw it."

s197
00:13:37.760 --> 00:13:41.200
Internal success is not external proof.

s198
00:13:41.519 --> 00:13:43.839
Proof is a chain, not a claim.

s199
00:13:43.839 --> 00:13:45.440
Model proposed something.

s200
00:13:45.440 --> 00:13:47.600
Policy allowed or denied it.

s201
00:13:47.600 --> 00:13:49.360
Execution attempted it.

s202
00:13:49.360 --> 00:13:54.000
User visible edge confirmed or failed to confirm the outcome.

s203
00:13:54.000 --> 00:13:56.160
The receipt preserves the chain.

s204
00:13:56.160 --> 00:13:58.320
A transcript records what the agent said.

s205
00:13:58.320 --> 00:14:02.320
The tool results records what one component claimed.

s206
00:14:02.320 --> 00:14:07.600
A receipt records what the agent can verify at the boundary that matters.

s207
00:14:08.320 --> 00:14:10.480
Let me recap all the incidents.

s208
00:14:10.480 --> 00:14:13.519
Here are the file failure shapes you you to look for.

s209
00:14:13.519 --> 00:14:19.440
A state hole, overlapping writers, dangling tool call, approval drift, and missing edge proof.

s210
00:14:19.440 --> 00:14:22.160
For each one, let's ask the same question.

s211
00:14:22.160 --> 00:14:24.160
What did the user see?

s212
00:14:24.160 --> 00:14:25.839
Which boundary it broke?

s213
00:14:25.839 --> 00:14:29.440
And what would the receipt have caught?

s214
00:14:29.519 --> 00:14:32.880
Here is the audit I want you to run when you get back to your team.

s215
00:14:32.880 --> 00:14:35.120
Pick one agent system, not all of them.

s216
00:14:35.120 --> 00:14:42.399
One trace one production, one real production path and ask for the receipt.

s217
00:14:42.720 --> 00:14:44.720
The audit has five questions.

s218
00:14:44.720 --> 00:14:46.399
What woke it up?

s219
00:14:46.399 --> 00:14:48.079
What state did it inherit?

s220
00:14:48.079 --> 00:14:50.480
Which authority did it use?

s221
00:14:50.480 --> 00:14:51.519
What executed?

s222
00:14:51.519 --> 00:14:53.760
And what evidence survived?

s223
00:14:53.760 --> 00:14:57.360
These questions expose squashalty.

s224
00:14:57.360 --> 00:15:02.399
They turn a fluent conversation into an inspectable production run.

s225
00:15:02.399 --> 00:15:04.320
First, what woke it up?

s226
00:15:04.320 --> 00:15:10.480
A user message, web hook, timer, tool result, sub agent, or a replay.

s227
00:15:10.480 --> 00:15:12.639
Name the trigger and its identity.

s228
00:15:12.639 --> 00:15:17.680
Without that, you cannot reason about dduplication, order, or authorization.

s229
00:15:17.920 --> 00:15:20.639
Second, which state did it inherit?

s230
00:15:20.639 --> 00:15:25.680
transcript, session state, memory snapshot, policy version, and tool surface.

s231
00:15:25.680 --> 00:15:30.079
The model only reasons over the working set the harness assembled.

s232
00:15:30.160 --> 00:15:33.120
Third, which authority did it use?

s233
00:15:33.120 --> 00:15:39.279
Record the actor, session, tool, run, arguments, scope, and lifetime.

s234
00:15:39.279 --> 00:15:41.360
A model request is not permission.

s235
00:15:41.360 --> 00:15:45.680
Authority should bind to a one pending action.

s236
00:15:46.000 --> 00:15:48.480
Fourth, what executed?

s237
00:15:48.480 --> 00:15:54.720
Record the tool or API call, arguments, attempt number, item potency key, and external results.

s238
00:15:54.720 --> 00:15:59.680
This is a side effect boundary, not the poor summary of what the agent intended.

s239
00:16:00.639 --> 00:16:03.120
Fifth, what evidence survived?

s240
00:16:03.120 --> 00:16:04.800
Did the ticket get updated?

s241
00:16:04.800 --> 00:16:06.720
Did the message got rendered?

s242
00:16:06.720 --> 00:16:09.040
Did the file got changed?

s243
00:16:09.040 --> 00:16:11.279
Did the calendar event exist?

s244
00:16:11.279 --> 00:16:17.199
The receipt should end at the boundary the usual the user usually cares about.

s245
00:16:18.000 --> 00:16:20.560
Now let's apply the opening incident.

s246
00:16:20.560 --> 00:16:22.880
The same order to the opening incident.

s247
00:16:22.880 --> 00:16:25.279
What woke it up a user message?

s248
00:16:25.279 --> 00:16:27.040
What state it owned?

s249
00:16:27.040 --> 00:16:28.800
That was the broken boundary.

s250
00:16:28.800 --> 00:16:31.600
What executed the channel send?

s251
00:16:31.600 --> 00:16:33.839
What evidence survived delivery?

s252
00:16:33.839 --> 00:16:38.079
What did not survive the durable turn?

s253
00:16:38.079 --> 00:16:41.120
Delivery survived while the state did not.

s254
00:16:41.120 --> 00:16:44.240
That gap is the harness failure.

s255
00:16:44.240 --> 00:16:47.680
The agent uh do did not need a better model.

s256
00:16:47.680 --> 00:16:50.399
The model did not need a better prompt.

s257
00:16:50.399 --> 00:16:54.560
The system needed a better harness with complete receipt.

s258
00:16:55.199 --> 00:16:59.519
Let me recap the same three things I asked you to remember from the start of my talk.

s259
00:16:59.519 --> 00:17:04.959
Own the state, order the mutation and prove the action.

s260
00:17:05.039 --> 00:17:07.199
A better model helps inside the turn.

s261
00:17:07.199 --> 00:17:16.000
Ownership, ordering, life cycle, authority and proof keep the system sane across turns.

s262
00:17:16.480 --> 00:17:21.600
A model proposes the harness commits and the receipts receipt proves it.

s263
00:17:21.600 --> 00:17:25.120
Once text can become an action, the useful question changes.

s264
00:17:25.120 --> 00:17:27.760
Do not only ask whether the model can reason.

s265
00:17:27.760 --> 00:17:35.760
Ask whether the system can own the state, order the mutation, bound the work, constraint authority, and preserve evidence.

s266
00:17:36.320 --> 00:17:41.440
A loop can answer a turn and harness can serve up production.

s267
00:17:41.919 --> 00:17:44.640
If you want to go deeper, scan the QR codes.

s268
00:17:44.640 --> 00:17:58.640
The first points to the agent open AI agents SDK where all these um harness are already built in so that you can use to build your own agents and second points to the agent stack where I write about the production agents

s269
00:17:58.640 --> 00:18:00.400
systems in more detail.

s270
00:18:00.400 --> 00:18:05.600
I'll be at the open booth after this talk if you want to talk about your harness design.

s271
00:18:05.600 --> 00:18:07.840
Thank you.

s272
00:18:07.967 --> 00:18:09.967
[applause]

s273
00:18:21.722 --> 00:18:23.722
[music]