WEBVTT

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

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/shRR1e2HXMk.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:12.760 --> 00:00:13.840
Hi everyone.

s3
00:00:13.840 --> 00:00:17.560
Uh we're going to start right on time because I'm going to speak basically at 2x.

s4
00:00:17.560 --> 00:00:19.440
I'm sorry, I have a lot of content.

s5
00:00:19.440 --> 00:00:22.320
I'm trying to get you out of here on time.

s6
00:00:22.320 --> 00:00:23.840
I want to start with a quick raise of hands.

s7
00:00:23.840 --> 00:00:27.960
So, how many of you have built your own agents or are currently building your own agents?

s8
00:00:27.960 --> 00:00:28.760
Perfectly.

s9
00:00:28.760 --> 00:00:30.480
You're the right audience for this.

s10
00:00:30.480 --> 00:00:39.400
Um over the next 20 minutes, I want to talk to you about a couple of different things that we're doing in the Codex harness that hopefully you can learn to apply to your own use cases

s11
00:00:39.400 --> 00:00:48.520
or even just use the Codex harness with this in um uh in your own projects or at bare minimum learn what happens when you actually use Codex.

s12
00:00:48.520 --> 00:00:57.360
Uh since we're at AI Engineer World's Fair and we're actually on an energetic engineering track, I'm going to like stop bothering you with like how does an agent work?

s13
00:00:57.360 --> 00:00:59.040
What is an agent?

s14
00:00:59.040 --> 00:01:08.560
And instead I want to talk a bit more specifically about some key features that we have in the agent that I think are particularly interesting and are challenges you have to solve.

s15
00:01:08.560 --> 00:01:15.000
And uh so let's cover it from the lens of like what actually happens when you send off a message.

s16
00:01:15.000 --> 00:01:21.520
Uh also a quick reminder, if you're unaware, the Codex harness and everything I'm showing you is actually open source.

s17
00:01:21.520 --> 00:01:25.320
Uh it's MIT it's Apache 2 license and the harness is written in Rust.

s18
00:01:25.320 --> 00:01:34.200
So, feel free to either learn from it, ask Codex deeper questions about what I'm covering, uh or fork it and make it your own.

s19
00:01:34.320 --> 00:01:39.240
Also disclaimer, before we dive deep into it, this is a current state of affairs.

s20
00:01:39.240 --> 00:01:41.440
Like things change so quickly.

s21
00:01:41.440 --> 00:01:50.680
Um you can always refer back to asking Codex what the current state is, but especially with new model releases, we often release new APIs and change sort of how the harness works.

s22
00:01:50.680 --> 00:01:54.960
Uh so, feel free to follow along as new models come out.

s23
00:01:54.960 --> 00:02:01.280
If we want to talk about how the Codex agent works, we first need to talk about what actually happens when you send off your message.

s24
00:02:01.280 --> 00:02:07.000
Um namely there's two protocols that are involved with uh code uh with the Codex agent.

s25
00:02:07.000 --> 00:02:11.080
The first one is what happens when you send it off in the UI and it goes to the harness.

s26
00:02:11.080 --> 00:02:12.360
We call that the app server.

s27
00:02:12.360 --> 00:02:15.320
I talked about that yesterday, so we're not going to spend too much time about it.

s28
00:02:15.320 --> 00:02:18.080
There will be a talk online that you can follow along.

s29
00:02:18.080 --> 00:02:24.880
Um the second part is the responses API, which is handles the communication between the harness and the inference.

s30
00:02:24.880 --> 00:02:36.360
Both of these though are designed for an open ecosystem, meaning if you're building your own UI, you're building your own uh agent interface, you can actually build on top of the Codex

s31
00:02:36.360 --> 00:02:39.200
uh harness using the app server protocol.

s32
00:02:39.200 --> 00:02:42.160
We use that same app server to power the Codex app.

s33
00:02:42.160 --> 00:02:52.640
So it has really all of that functionality uh that you might expect from uh Codex, as well as like we have a lot of third-party community projects that build on top of it, including Theos T3 code

s34
00:02:52.640 --> 00:02:55.840
or uh Remote X for example.

s35
00:02:55.920 --> 00:02:59.560
I even used that same app server to put Codex into Cloud code.

s36
00:02:59.560 --> 00:03:04.959
So if you're uh Cloud code user and you want to leverage uh Codex, you can use that plugin.

s37
00:03:04.959 --> 00:03:11.200
And if you joined my talk yesterday, you saw me using that same protocol to actually put Codex into Doom.

s38
00:03:11.200 --> 00:03:14.640
Um which is was a fun adventure as well.

s39
00:03:14.880 --> 00:03:17.120
I mentioned the other part is the responses API.

s40
00:03:17.120 --> 00:03:33.880
So responses API was released last year as like a rethinking of the chat completions API in a more agentic world, meaning um we redesigned the slightly the structure, but more importantly we added a lot of like building capabilities that are important for agents like web search, image gen,

s41
00:03:33.880 --> 00:03:38.560
or other other more complex capabilities that you will see as part of this talk.

s42
00:03:38.560 --> 00:03:49.840
We also want to make sure that this is like an open ecosystem, so we worked with a lot of partners including Ollama, LM Studio, Nvidia, and others to uh codify an open responses

s43
00:03:49.840 --> 00:04:00.800
schema and have a governance body for that, so that other uh companies and and platforms can actually build on that same responses API, and you can use any responses API

s44
00:04:00.800 --> 00:04:08.280
compatible um harness model provider and actually plug it into the Codex harness.

s45
00:04:08.280 --> 00:04:10.720
So, that's an overview of how these protocols work.

s46
00:04:10.720 --> 00:04:18.760
We're going from the UI to the harness with the app server protocol, and then from the harness to the LM inference using responses.

s47
00:04:18.760 --> 00:04:20.480
But, what happens in the actual harness?

s48
00:04:20.480 --> 00:04:26.360
The first step, arguably one of the most important ones, is context construction.

s49
00:04:26.360 --> 00:04:30.280
And during that, we care about three things quite a lot.

s50
00:04:30.280 --> 00:04:31.600
The first one is size.

s51
00:04:31.600 --> 00:04:40.520
We want to make sure that, you know, we don't blast through your token budgets and throw in a bunch of unnecessary content, but also the more context you have in your

s52
00:04:40.520 --> 00:04:48.000
in your context, the higher it is that you have contradicting information and it causes confusion for the model.

s53
00:04:48.000 --> 00:04:49.320
The other part is flexibility.

s54
00:04:49.320 --> 00:04:58.640
We want to make sure that, regardless of how many or how little skills you're using, you have a great experience regardless of how many plugins and MCPs you install.

s55
00:04:58.640 --> 00:05:06.600
And of course, we want to make sure that things are performing and cost we know you're cost sensitive, so cashability is important as well.

s56
00:05:06.600 --> 00:05:13.560
To show you this and a couple of other things, I actually built this little nano Codex here, um which functions the same way.

s57
00:05:13.560 --> 00:05:19.120
It's built on built using the same code that is on the public repo, just turned into TypeScript.

s58
00:05:19.120 --> 00:05:29.160
But, we can see here when we send over a message, we have a couple of different parts of of the actual context that gets assembled.

s59
00:05:29.160 --> 00:05:34.600
And some of these are fairly standard and predictable, like the model instructions.

s60
00:05:34.600 --> 00:05:37.160
Again, these are open source if you actually want to read them.

s61
00:05:37.160 --> 00:05:43.520
But, these are fairly structured and don't really change in size or like mess around with cashability.

s62
00:05:43.520 --> 00:05:45.880
But, there are some parts that are harder to predict.

s63
00:05:45.880 --> 00:05:49.400
Namely, for example, how many skills do you have available?

s64
00:05:49.400 --> 00:05:59.200
Or the tool registry, where especially if you install MCPs, for example, you might have additional context that is like growing as you're installing more MCPs.

s65
00:05:59.200 --> 00:06:01.840
For that reason, we do two things to maintain cost.

s66
00:06:01.840 --> 00:06:04.720
The first one is or the size of the context.

s67
00:06:04.720 --> 00:06:07.760
The first one is having deferred tools.

s68
00:06:07.760 --> 00:06:16.720
So, we're marking some of these tools as deferred, and that means that they're not added directly to the context window, but instead are available through tool search later on.

s69
00:06:16.720 --> 00:06:28.280
Um and then the other part is that for available skills, we actually cap the available skills list at 2% of your context total like maximum context window.

s70
00:06:28.280 --> 00:06:36.520
And that means that if it gets longer, we're reducing slowly the amount of like description that we're putting in there.

s71
00:06:36.600 --> 00:06:40.320
Tool search specifically is actually something that is available in the responses API.

s72
00:06:40.320 --> 00:06:43.000
So, even if you're building your own harness, you can leverage this.

s73
00:06:43.000 --> 00:06:47.720
Since GPT-5.4, you can mark any tool as deferred loading.

s74
00:06:47.720 --> 00:07:01.040
Um and that means that these tools are only available if you're using tool search, and then you can give the model either our built-in tool search tool or implement your own if you feel like you can better do that discovery yourself.

s75
00:07:01.840 --> 00:07:02.360
Great.

s76
00:07:02.360 --> 00:07:07.960
We talked about how we're building the context, but an agent really only becomes an agent if it performs actions.

s77
00:07:07.960 --> 00:07:10.600
And there's three common actions I wanted to talk about.

s78
00:07:10.600 --> 00:07:18.840
The first one is async actions, things that are happening while the agent has to continue to do work, computer use, and then the file system.

s79
00:07:18.840 --> 00:07:29.640
For async actions, a good example is sub-agents, where we want to be able to delegate tasks off and then have the main agent continue to do work if necessary.

s80
00:07:29.640 --> 00:07:43.720
The way that works in practice is that we give the agent a spawn agent tool, which then allows the agent to create new new agent instances, and then use a send input tool to either send new content to that

s81
00:07:43.720 --> 00:07:49.040
to those new newly created agents, wait for an agent, or shut it back down.

s82
00:07:49.040 --> 00:07:52.960
Um we use that same concept actually for background terminals as well.

s83
00:07:52.960 --> 00:08:09.760
So, the Codex agent has a tool to spin up a new uh background terminal and then continuously interact with it by sending new data through standard in to that new agent or wait for a specific amount of time for that agent to finish a task.

s84
00:08:12.000 --> 00:08:19.960
Computer use is an interesting one because we actually introduced uh computer use in the responses API last year and it was fairly limited.

s85
00:08:19.960 --> 00:08:31.240
It only allowed you to do one action at a time and um you had to basically declare that you wanted it to do computer use and from there you were up to actually implementing

s86
00:08:31.240 --> 00:08:35.159
specifically the type of actions that were exposed to that tool.

s87
00:08:35.159 --> 00:08:48.040
This was uh great in terms of like that state uh that point in the journey of of building agents, but since then we've evolved it and uh the recent models and the recent API shapes allow you to

s88
00:08:48.040 --> 00:08:58.640
use code execution instead to actually do computer use, which means that the agent can script its own interactions with the uh with whatever computer implementation you want to have.

s89
00:08:58.640 --> 00:09:04.839
You can choose the language like JavaScript or Python and you are you have a much more flexible harness.

s90
00:09:04.839 --> 00:09:07.560
In fact, that's what we use for browser use.

s91
00:09:07.560 --> 00:09:19.400
Um so, the what happens when uh Codex uses browser use is it actually interacts with a persistent node repl that gets persisted throughout different uh throughout the turns.

s92
00:09:19.400 --> 00:09:28.280
And then it writes JavaScript um essentially Playwright code to interact with that uh browser instance in the node repl.

s93
00:09:28.280 --> 00:09:39.640
Um so, here's an example where on the right side we have a Chromium browser and the first time um it writes some code to get the overall status and like pulls up the right tab.

s94
00:09:39.640 --> 00:09:50.720
And then on subsequent terms, we can see here that it is able to like reference those new tabs, pull in information, and script the respective actions um to understand

s95
00:09:50.720 --> 00:09:53.000
what actually has to be done.

s96
00:09:53.000 --> 00:10:03.080
And so that may speeds up these actions significantly because uh Codex and browser use can actually look at for example one page, understand the structure, and then write a script to perform

s97
00:10:03.080 --> 00:10:07.800
like scraping for example on subsequent pages more easily.

s98
00:10:08.360 --> 00:10:10.320
The third thing is file system interactions.

s99
00:10:10.320 --> 00:10:15.760
I think if you're using Codex or any coding agent, of course you want it to be able to interact with the file system.

s100
00:10:15.760 --> 00:10:25.840
In the case of um our models, all of the recent models starting with GPT-5 have been trained on the concept of an apply patch tool to do file editing,

s101
00:10:25.840 --> 00:10:34.760
which means that they're used to using that to change files by giving it a a diff, and then um also using that same thing to create new files.

s102
00:10:34.760 --> 00:10:42.160
And then for everything else, it uses a shell tool where it will uh do a file search or other file system navigation.

s103
00:10:42.160 --> 00:10:49.160
Uh you will see the model naturally trying to use Ripgrep um since that's what what it got used to during training.

s104
00:10:49.160 --> 00:10:56.440
So, we're actually in the Codex harness shipping Ripgrep with uh with the harness if you don't have it installed on your own.

s105
00:10:56.440 --> 00:11:00.480
On Windows, we also trained the model to use PowerShell natively.

s106
00:11:00.480 --> 00:11:06.640
So, if you're running it on Windows, you'll see it uh start writing uh PowerShell code instead.

s107
00:11:06.640 --> 00:11:10.760
One of the things you're seeing here is um the sandbox pulling in.

s108
00:11:10.760 --> 00:11:17.400
So, all of the interactions that you see with the file system actually go through our sandbox layer.

s109
00:11:17.400 --> 00:11:23.440
Um and on macOS, we use Seatbelt for that, similar to most agents.

s110
00:11:23.440 --> 00:11:25.560
And on Linux, we use Bubblewrap.

s111
00:11:25.560 --> 00:11:34.040
On uh Windows, it's slightly different where we actually had to build our own custom um open open source Windows sandbox.

s112
00:11:34.040 --> 00:11:37.560
It's in the same GitHub repository if you want to take a look.

s113
00:11:37.560 --> 00:11:42.040
And there's a many reasons why we had to do this, and I could probably fill a whole talk about that.

s114
00:11:42.040 --> 00:11:48.240
So, instead, I would recommend you to actually check out the check out the article that David wrote about this.

s115
00:11:48.240 --> 00:11:53.960
Um it goes into all of the other Windows alternatives and why we actually had to build our own sandbox there.

s116
00:11:53.960 --> 00:11:58.440
Highly fascinating if you really want to nerd out about Windows internals.

s117
00:11:59.240 --> 00:12:04.760
With sandboxes though, uh one of the biggest complaints is always approval fatigue.

s118
00:12:04.760 --> 00:12:11.440
Um how many of you get like annoyed by approvals, especially for long tasks and like have running full access?

s119
00:12:11.440 --> 00:12:11.840
All right.

s120
00:12:11.840 --> 00:12:14.840
And I don't think the audience gets filmed, so like we're going to do this again.

s121
00:12:14.840 --> 00:12:19.760
Like how many of you know that like IT and security really hates that you turn on full access?

s122
00:12:19.760 --> 00:12:20.160
Yeah.

s123
00:12:20.160 --> 00:12:21.440
Yeah, I know.

s124
00:12:21.440 --> 00:12:31.320
Uh so, for that reason and uh you know, our own security team wanting to be happy as well, um we worked on um an auto approval mode.

s125
00:12:31.320 --> 00:12:39.240
And the idea here is really to um derisk some of the like full access things because there are things that can go wrong.

s126
00:12:39.240 --> 00:12:50.720
As much as these models have gotten better, especially if you're trying to push the model through prompting to really have high agency, that can be misinterpreted by the by the agent to not match up with your expectation

s127
00:12:50.720 --> 00:13:01.160
like you asking a model to send out a file to through an email, pushing it to have high agency, and it realizes it can't attach the file, so it uploads it to a file share,

s128
00:13:01.160 --> 00:13:06.440
um and like uses that instead, or messes up some escaping and accidentally deletes too much data.

s129
00:13:06.440 --> 00:13:09.839
Those things can still happen even with the models getting better.

s130
00:13:09.839 --> 00:13:14.960
And so, you want to still be careful with these um full access modes.

s131
00:13:14.960 --> 00:13:23.760
And so, instead, we built auto review with this goal to cover all of the things that are harder to predict that an agent might do and especially in the long run,

s132
00:13:23.760 --> 00:13:34.600
and um approve those automatically without having to escalate them to you while keeping things like uh data exfiltration outside of it.

s133
00:13:34.680 --> 00:13:45.040
The way this works is when we um kick off a task that runs into a sandbox like deleting a file in this case, um the model when it tries to escalate

s134
00:13:45.040 --> 00:13:49.520
spins up an auto review uh subagent.

s135
00:13:49.520 --> 00:13:52.320
And uh let's see.

s136
00:13:52.320 --> 00:13:52.920
Didn't do it yet.

s137
00:13:52.920 --> 00:13:53.720
There we go.

s138
00:13:53.720 --> 00:13:55.920
So, it spins up an auto review subagent.

s139
00:13:55.920 --> 00:14:02.240
And this subagent runs entirely separate and can't spin up other subagents and has read permissions only.

s140
00:14:02.240 --> 00:14:10.040
Um but it we're giving it a bunch of context around sort of how what what is user authorization, which we'll see in a second.

s141
00:14:10.040 --> 00:14:13.440
How do things like uh risk taxonomies work?

s142
00:14:13.440 --> 00:14:16.000
How do we want it want it to judge these things?

s143
00:14:16.000 --> 00:14:24.240
Um and then eventually we give it um the transcript as well as sort of the tool calls that are actually happening.

s144
00:14:24.240 --> 00:14:26.920
And this is important because the context matters, right?

s145
00:14:26.920 --> 00:14:30.200
Like in some cases you want the agent to actually delete a file.

s146
00:14:30.200 --> 00:14:31.520
In other cases you don't.

s147
00:14:31.520 --> 00:14:35.880
If you ask it to or if it like is part of the project, it makes sense.

s148
00:14:35.880 --> 00:14:39.960
Especially like things like if you ask it to delete a dot git folder, great.

s149
00:14:39.960 --> 00:14:45.040
If you didn't ask it to, it should probably not touch that part and like completely delete your history.

s150
00:14:45.040 --> 00:14:55.480
Um and so we're giving it all of this context and ask it to then come up with um a judgment based on like the user authorization.

s151
00:14:55.480 --> 00:14:59.560
In this case, it's high because we explicitly told it to delete the file.

s152
00:14:59.560 --> 00:15:04.440
Um what is the impact of the deletion or like the action itself and what should we do?

s153
00:15:04.440 --> 00:15:18.640
So, this could apply both to file system actions, but also to network calls for example where like curling Google to see if it if the internet works is fine, but maybe not uploading a file for example.

s154
00:15:18.720 --> 00:15:25.440
This is a gross oversimplification of all of the thoughts and uh work that went into this by engineers and and the research team.

s155
00:15:25.440 --> 00:15:32.360
So, if you do want to learn more about it, check out the auto review um blog post that we wrote.

s156
00:15:32.360 --> 00:15:34.160
The next thing I wanted to talk about is speed.

s157
00:15:34.160 --> 00:15:44.160
Um because agents can do a lot of tool calls, and while we are doing a lot of work on speeding up inference, it's only part of the equation.

s158
00:15:44.160 --> 00:15:53.200
We noticed this when we uh launched GPT 5.3 Codex Spark, uh and it's running on Cerebras at 1,000 tokens per second.

s159
00:15:53.200 --> 00:15:59.920
So, with that, we realized that with all of these tool calls and the interactions, inference wasn't no longer was no longer the bottleneck.

s160
00:15:59.920 --> 00:16:02.360
It was actually the network.

s161
00:16:02.360 --> 00:16:17.640
So, for that reason, we introduced WebSocket mode, which means that the responses API doesn't run through service-side events and HTTP, but instead uses uses a persistent WebSocket connection, which allows us to save both on network overhead,

s162
00:16:17.640 --> 00:16:23.800
but also provides stateful context, which means we only have to send the data that actually changed.

s163
00:16:23.800 --> 00:16:31.360
So, for example, if there's a tool call, we only send back the result of the tool call rather than sending all of the items back.

s164
00:16:31.360 --> 00:16:34.280
So, in practice, oh Great.

s165
00:16:34.280 --> 00:16:36.800
In this case, my demo server crashed.

s166
00:16:36.800 --> 00:16:42.160
Um let me see if I have a backup here.

s167
00:16:43.000 --> 00:16:49.280
Um Oh, spoiling the rest of the demo.

s168
00:16:49.280 --> 00:16:49.880
Nope.

s169
00:16:49.880 --> 00:16:51.800
Uh All right.

s170
00:16:51.800 --> 00:16:58.520
Um in practice, you will see that it's going to send um one like it's going to send only one item after another.

s171
00:16:58.520 --> 00:16:59.080
Oh, wait.

s172
00:16:59.080 --> 00:17:01.480
Sorry, I pressed the wrong button for this one.

s173
00:17:01.480 --> 00:17:02.120
There we go.

s174
00:17:02.120 --> 00:17:03.320
Here's the backup.

s175
00:17:03.320 --> 00:17:12.800
Um So, it's going to only send like one item after another, rather than sending like in this case, for example, like nine items back.

s176
00:17:12.800 --> 00:17:15.839
Um while for the other one, we're only sending one back.

s177
00:17:15.839 --> 00:17:20.199
And so, over time, this actually speeds up things quite significantly.

s178
00:17:20.199 --> 00:17:25.079
Um and can have a pretty drastic impact on the performance.

s179
00:17:25.280 --> 00:17:25.800
All right.

s180
00:17:25.800 --> 00:17:28.120
We're at AI Engineer World's Fair in 2026.

s181
00:17:28.120 --> 00:17:33.040
The only thing like I have to talk legally about is loops.

s182
00:17:33.480 --> 00:17:35.040
So, we're briefly going to talk about it.

s183
00:17:35.040 --> 00:17:38.920
Um specifically {slash} goal, because I got the questions a couple of times during this event.

s184
00:17:38.920 --> 00:17:40.800
How does this actually work?

s185
00:17:40.800 --> 00:17:50.120
Um and of course since the demo server crashed, which also shows that that was real data.

s186
00:17:50.680 --> 00:17:53.640
We're going to show you the demo here.

s187
00:17:53.640 --> 00:17:57.480
This is a hosted demo, by the way, so you'll be able to replay this afterwards.

s188
00:17:57.480 --> 00:18:07.000
Um but basically what happens is in this case we're having a try to guess a number, and it's only achieving that goal when it's actually done with guessing that number.

s189
00:18:07.000 --> 00:18:15.280
And while it until it's done with that, um it will actually automatically the harness will inject this continuation prompt.

s190
00:18:15.280 --> 00:18:18.600
And this continuation prompt includes, among other things, your objective.

s191
00:18:18.600 --> 00:18:20.600
That's the goal that you set.

s192
00:18:20.600 --> 00:18:32.120
And then uh we continue to do this until the model itself calls an update plan update goal tool, which specifies that the plan was actually or the goal was actually achieved.

s193
00:18:32.120 --> 00:18:42.960
So, that is the reason why you actually don't want to, you know, write full essays like I know a lot of you have been trying to um into your goal,

s194
00:18:42.960 --> 00:18:51.760
but instead have very concrete and very fiable um prompts, so that uh it's easy to detect when things are done.

s195
00:18:51.760 --> 00:18:54.320
The last thing I want to talk about is compaction.

s196
00:18:54.320 --> 00:19:01.400
If we have these agents run for hours or days at a time, you don't want to stand there and actually approve everything all the time.

s197
00:19:01.400 --> 00:19:16.960
Um and because of that we introduced uh end end of last year auto compaction, and this has been uh used by Codex since then to automatically trigger compaction on the server side in a way that the model got trained with so that the performance stays the same.

s198
00:19:16.960 --> 00:19:30.960
Um the way this works is you can either trigger this manually or automatically and it will turn your transcription into or your your previous context window into a new one that you're going to use instead on subsequent turns

s199
00:19:30.960 --> 00:19:36.840
and it contains a compaction item that has all of the necessary information in it that you need.

s200
00:19:37.400 --> 00:19:38.000
All right.

s201
00:19:38.000 --> 00:19:42.440
To wrap things up, thank you for staying with me speed running through these slides.

s202
00:19:42.440 --> 00:19:45.680
Um three things I want you to take away from this.

s203
00:19:45.680 --> 00:19:50.040
Uh the first one is the Codex app server and the harness are open source.

s204
00:19:50.040 --> 00:19:58.520
You can use this as a blueprint to learn how we built our agents or you can actually use it as the harness itself that you can build on top of.

s205
00:19:58.520 --> 00:20:05.480
The other part is that most of the features that are stand out for Codex are actually features that are exposed in the responses API.

s206
00:20:05.480 --> 00:20:13.200
So even if you want to build your own agent, you can leverage these things like tool search, apply patch, web sockets, or server side compaction.

s207
00:20:13.200 --> 00:20:16.640
You can use those directly regardless of what harness you're using.

s208
00:20:16.640 --> 00:20:27.600
And the last thing is as models evolve, keep an eye out on how we're evolving the responses API, how we're evolving Codex, and uh use that as a way to understand how you want to update

s209
00:20:27.600 --> 00:20:32.040
your own agents to make make use of these new capabilities.

s210
00:20:32.040 --> 00:20:33.440
And with that, thank you so much.

s211
00:20:33.440 --> 00:20:38.600
That's the link to the slides and I'll be heading down to the booth if you have any questions.

s212
00:20:52.374 --> 00:20:54.374
[music]