WEBVTT

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

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

s1
00:00:06.550 --> 00:00:08.550
[music]

s2
00:00:12.520 --> 00:00:13.520
Going good.

s3
00:00:13.520 --> 00:00:14.400
All right.

s4
00:00:14.400 --> 00:00:16.240
There we go.

s5
00:00:16.240 --> 00:00:17.520
All right.

s6
00:00:17.520 --> 00:00:18.880
Hello everyone.

s7
00:00:18.880 --> 00:00:20.520
All right, just checking voice.

s8
00:00:20.520 --> 00:00:22.240
All right, good.

s9
00:00:22.240 --> 00:00:33.720
All right, well uh my name is Dan and I'm here to talk to you about how your agent architecture has a half-life of 6 months.

s10
00:00:33.840 --> 00:00:36.040
But first who am I?

s11
00:00:36.040 --> 00:00:39.920
I'm Dan, I'm the CTO and co-founder at Ingest.

s12
00:00:39.920 --> 00:00:42.000
And why should you listen to me?

s13
00:00:42.000 --> 00:00:45.800
Well, first I lead an amazing team over at Ingest.

s14
00:00:45.800 --> 00:00:55.960
We We build a system that reliably executes anything from agents to workflows to contact pipelines, whatever you want.

s15
00:00:55.960 --> 00:01:07.400
I'm deep building AI infra every [clears throat] day and on top of that also building agents, not just pontificating up here in theory about how you should build it.

s16
00:01:07.680 --> 00:01:18.520
So speaking of building agents if you've been building agents for more than 6 months, you've likely rewritten something, maybe more than once.

s17
00:01:18.520 --> 00:01:29.080
A new model a new framework or framework version new tool calling standard, a new pattern, suddenly your architecture doesn't fit.

s18
00:01:29.080 --> 00:01:30.480
It's not a complaint.

s19
00:01:30.480 --> 00:01:32.080
It's just the reality.

s20
00:01:32.080 --> 00:01:34.280
Right, things move faster than ever.

s21
00:01:34.280 --> 00:01:38.880
You can see if you've been to any of the the sessions or keynotes.

s22
00:01:38.880 --> 00:01:52.200
So I want you to think about what you shipped 6 months ago and how much of it still runs the way that you originally wrote it.

s23
00:01:52.200 --> 00:01:54.960
Some parts of your code likely survives.

s24
00:01:54.960 --> 00:01:57.440
But did they survive by accident?

s25
00:01:57.440 --> 00:01:59.360
Or did you design it that way?

s26
00:01:59.360 --> 00:02:02.280
Did they survive by design?

s27
00:02:03.280 --> 00:02:06.680
How did you actually architect your agent?

s28
00:02:06.680 --> 00:02:08.640
Did you architect it at all?

s29
00:02:08.640 --> 00:02:09.960
It's okay.

s30
00:02:09.960 --> 00:02:11.720
Uh did you use a framework?

s31
00:02:11.720 --> 00:02:14.600
Did you custom roll something?

s32
00:02:14.600 --> 00:02:18.120
Was the architecture an intentional design that you really thought through?

s33
00:02:18.120 --> 00:02:21.280
Or just kind of evolved into what you have now?

s34
00:02:21.280 --> 00:02:25.840
These are all various ways of where people are these days.

s35
00:02:25.840 --> 00:02:33.560
So, a lot of folks have talked about harness architecture, building harnesses.

s36
00:02:33.560 --> 00:02:39.040
But mostly, I think a lot of people draw diagrams and they talk about specific components.

s37
00:02:39.040 --> 00:02:40.240
Draw just nice lines.

s38
00:02:40.240 --> 00:02:44.560
It looks very similar like, you know, kind of simple.

s39
00:02:44.560 --> 00:02:49.440
But I want to talk about the conceptual layers when you're building a system like this.

s40
00:02:49.440 --> 00:02:51.720
This is maybe the mental model.

s41
00:02:51.720 --> 00:02:54.200
Not specific components.

s42
00:02:54.200 --> 00:02:58.880
So, in my opinion, there are three discrete layers.

s43
00:02:58.880 --> 00:03:01.320
First, the execution layer.

s44
00:03:01.320 --> 00:03:03.800
I think of this as the brain.

s45
00:03:03.800 --> 00:03:09.640
It's where flow, state, durability, retries happen.

s46
00:03:09.640 --> 00:03:11.519
Then there's the context layer.

s47
00:03:11.519 --> 00:03:13.040
This is the knowledge.

s48
00:03:13.040 --> 00:03:18.560
All right, this is models, prompts, tools, memory.

s49
00:03:18.560 --> 00:03:21.920
This is the layer that changes the most.

s50
00:03:21.920 --> 00:03:23.560
And then there's compute.

s51
00:03:23.560 --> 00:03:26.600
There are um this is the hands, right?

s52
00:03:26.600 --> 00:03:32.360
This is sandboxes, runtimes, browsers that you're automating.

s53
00:03:32.360 --> 00:03:37.120
I think these layers are important to consider for the following reason.

s54
00:03:37.120 --> 00:03:39.160
It's your half-life.

s55
00:03:39.160 --> 00:03:40.560
And what is half-life?

s56
00:03:40.560 --> 00:03:42.600
All right, it's a scientific term.

s57
00:03:42.600 --> 00:03:51.120
And it's a scientific term for the time that it takes for your for something to decay by half.

s58
00:03:51.120 --> 00:03:55.400
And I think that your architecture has a half-life, also.

s59
00:03:55.400 --> 00:04:00.000
So, prompts last weeks, if you're lucky, maybe maybe a single week.

s60
00:04:00.000 --> 00:04:03.800
Uh the models that you use, months, again, if you're lucky.

s61
00:04:03.800 --> 00:04:09.360
Uh but I think that execution can last years, if you do it right.

s62
00:04:09.360 --> 00:04:15.200
So, the problem is that I think that most teams couple everything together.

s63
00:04:15.200 --> 00:04:21.799
And what happens then is that one layer's half-life kind of leaks and drags the other components down.

s64
00:04:21.799 --> 00:04:25.960
You're building it's technical debt by another name.

s65
00:04:25.960 --> 00:04:30.000
So, my thesis is think in layers.

s66
00:04:30.000 --> 00:04:32.800
Decouple them.

s67
00:04:33.360 --> 00:04:36.080
So, let's talk about what I mean.

s68
00:04:37.000 --> 00:04:40.560
Teams run into a lot of issues with the approaches that they choose.

s69
00:04:40.560 --> 00:04:44.919
You might choose a framework, it might feel super magical to get going.

s70
00:04:44.919 --> 00:04:50.480
You might grab a pre-built harness from one of the frontier labs or wherever.

s71
00:04:50.480 --> 00:04:55.200
And or you might custom roll the entire system yourself, and it might take months or weeks or whatever.

s72
00:04:55.200 --> 00:05:04.320
But I think in a lot of these situations, the abstractions either are not there at all or they're too high-level or the layers merge.

s73
00:05:04.320 --> 00:05:11.720
You know, like orchestration is buried deep inside the chain or inside the framework, and you don't know what the heck's happening.

s74
00:05:11.720 --> 00:05:14.760
Uh state might be kept in a sandbox.

s75
00:05:14.760 --> 00:05:19.120
Uh retries get tangled with prompts, the prompt logic.

s76
00:05:19.120 --> 00:05:26.720
And what's hard is you can't re- you can't like swap any of these things out without rewriting almost everything.

s77
00:05:26.720 --> 00:05:30.919
So, I think you need to embrace the change.

s78
00:05:30.919 --> 00:05:32.520
Know that things are going to change.

s79
00:05:32.520 --> 00:05:34.320
Know that things are moving fast.

s80
00:05:34.320 --> 00:05:39.760
But I think also with that is I want to focus on a layer that I think is the stable layer here.

s81
00:05:39.760 --> 00:05:48.360
Where you can invest and think about and get your abstractions right, so you don't need to rewrite a large component every 6 months.

s82
00:05:48.360 --> 00:05:50.880
So, I'm talking about the execution layer.

s83
00:05:50.880 --> 00:05:53.080
I don't think enough people talk about this.

s84
00:05:53.080 --> 00:06:06.600
And I define it as the execution layer as being the system responsible for running your code reliably, managing how, when, or whether each piece of work completes.

s85
00:06:06.600 --> 00:06:10.880
And that's independent of the infrastructure that it's on.

s86
00:06:11.600 --> 00:06:14.840
So, what does this look like in an agent architecture?

s87
00:06:14.840 --> 00:06:19.560
So, the execution layer manages the full life cycle.

s88
00:06:19.560 --> 00:06:28.440
You know, plan, call a model, run code, invoke a sub-agent, loop, retry, coordinate.

s89
00:06:28.440 --> 00:06:35.840
You can swap the model, swap the context, swap the sandbox, the execution layer should be able to remain the same.

s90
00:06:35.840 --> 00:06:37.919
It's just the the fundamentals.

s91
00:06:37.919 --> 00:06:43.360
And that's how you, I think, decouple and you build the system that it can evolve for change.

s92
00:06:43.360 --> 00:06:47.800
So, let's talk about what the execution layer has to do.

s93
00:06:47.800 --> 00:06:50.840
First, resumability.

s94
00:06:50.840 --> 00:06:59.360
Your execution layer must enable your system to pick up after failures without restarting from the beginning.

s95
00:06:59.360 --> 00:07:03.919
You know, agents are handling longer-running tasks than ever before.

s96
00:07:03.919 --> 00:07:09.280
So, they must be able to resume when an LLM call fails, a tool call fails, everything flakes out.

s97
00:07:09.280 --> 00:07:11.480
We all know.

s98
00:07:11.480 --> 00:07:23.600
So, if you have a failed reflect step 38, you should be able to retry, wait, continue onwards, instead of having to go from the beginning, and you're going to lose tokens,

s99
00:07:23.600 --> 00:07:28.520
costs, time, work that your agent might have completed.

s100
00:07:28.520 --> 00:07:35.840
So, for this this to work, a 3-hour run cannot hold state in memory or in disk.

s101
00:07:35.840 --> 00:07:38.360
The state must live outside of the work.

s102
00:07:38.360 --> 00:07:43.640
So, this means that the state must be durable and external.

s103
00:07:43.640 --> 00:07:48.360
So, without it, you might cobble together maybe some manual checkpointing.

s104
00:07:48.360 --> 00:07:57.120
You might come up with a system that has like a log-based approach where you're going to be like hydrating the state back if you have to pick up where you left off.

s105
00:07:57.120 --> 00:08:01.520
But, I think a lot of those abstractions start leaking into the other layers of your harness, right?

s106
00:08:01.520 --> 00:08:04.240
It gets harder to change.

s107
00:08:04.720 --> 00:08:13.560
So, next, a key aspect of the execution layer is that it must enable you to combine a lot of invocation patterns.

s108
00:08:13.560 --> 00:08:15.080
You're going to need crons.

s109
00:08:15.080 --> 00:08:17.440
You're going to need to trigger things with events.

s110
00:08:17.440 --> 00:08:20.440
You're going to need APIs, human in the loop.

s111
00:08:20.440 --> 00:08:25.919
Subagents or dynamic workflows also must be possible.

s112
00:08:25.919 --> 00:08:33.760
You're going to need to be able to invoke these things synchronously, asynchronously, delaying invocation.

s113
00:08:33.760 --> 00:08:46.240
And I think the key here is that flexible execution and orchestration primitives will enable you to build the pattern or the system the architecture that you actually need.

s114
00:08:46.240 --> 00:08:56.920
So, if not, I think again, your harness logic starts absorbing other concepts like queues, workers, polling, backoff, scheduling.

s115
00:08:56.920 --> 00:09:01.120
And now you end up kind of a mess bad abstractions.

s116
00:09:01.640 --> 00:09:09.760
So, lastly, execution needs to provide observability across your entire session.

s117
00:09:09.760 --> 00:09:19.560
Not just the LLM calls, the tool calls, but database errors, permissions issues, um triggers, performance.

s118
00:09:19.560 --> 00:09:23.320
So, the full session trace across your entire run is essential.

s119
00:09:23.320 --> 00:09:37.080
So, if you can't see the entirety of a trace from the trigger through the whole stack, it's really hard to debug it, let alone improve your agent and keep evolving it.

s120
00:09:37.080 --> 00:09:39.320
So, what about sandboxes?

s121
00:09:39.320 --> 00:09:41.440
Sandboxes are so hot.

s122
00:09:41.440 --> 00:09:45.080
So, agents need sandboxes.

s123
00:09:45.080 --> 00:09:48.480
We kind of like settled upon that at this point in time.

s124
00:09:48.480 --> 00:09:50.480
They need to execute code.

s125
00:09:50.480 --> 00:09:51.560
They need to browse.

s126
00:09:51.560 --> 00:09:53.320
They need to manipulate files.

s127
00:09:53.320 --> 00:09:55.360
They might work on disk.

s128
00:09:55.360 --> 00:10:00.240
But, a sandbox is ephemeral and stateless by design.

s129
00:10:00.240 --> 00:10:05.840
So, using it for durability, snapshots, or something in state, I think is an anti-pattern.

s130
00:10:05.840 --> 00:10:12.920
I think it's a difficult thing where the state gets lost and you're kind of trying to peel pull the pieces back together.

s131
00:10:12.920 --> 00:10:22.680
So, I think when you have the execution layer separate, the execution layer is what gives the sandbox its context, its sequence, its durability.

s132
00:10:22.680 --> 00:10:29.160
So, I think of the sandbox as the hands and execution as the brain.

s133
00:10:29.280 --> 00:10:32.280
So, So, what's next?

s134
00:10:32.280 --> 00:10:38.200
All right, what are the next six months of architectures that you're going to need to handle?

s135
00:10:38.400 --> 00:10:49.320
So, if you're paying attention, you're joining a lot of these sessions, you'll see what architectures are emerging and what each approach brings new engineering requirements.

s136
00:10:49.320 --> 00:11:02.800
You know, you have background agents, dynamic workflows, autonomous loops, agent factories, whatever you want to call it, all these emerging trends that we're seeing the last couple days.

s137
00:11:02.800 --> 00:11:04.720
They're all long-running.

s138
00:11:04.720 --> 00:11:06.800
They're asynchronous.

s139
00:11:06.800 --> 00:11:09.040
They're delegated.

s140
00:11:09.200 --> 00:11:14.280
That means that you need to be able to observe them all uh down to the core.

s141
00:11:14.280 --> 00:11:18.640
All right, they need to be inspectable by human and by an agent.

s142
00:11:18.640 --> 00:11:26.520
So, the patterns, as you see, they as these things emerge, they must be mixed and combined together.

s143
00:11:26.520 --> 00:11:29.080
So, what does this all have in common?

s144
00:11:29.080 --> 00:11:33.680
I think that execution is fundamental to building any of these systems.

s145
00:11:33.680 --> 00:11:38.400
So, let's just take one example here, background agents, right?

s146
00:11:38.400 --> 00:11:39.520
They're not request response.

s147
00:11:39.520 --> 00:11:43.840
There's no person just waiting there for you for the the the chatbot to respond.

s148
00:11:43.840 --> 00:11:46.640
So, it could might run for minutes or hours.

s149
00:11:46.640 --> 00:11:52.800
It's going to have maybe hundreds of calls to you know, maybe 200 tool calls.

s150
00:11:52.800 --> 00:11:56.680
You're going to probably guarantee to have at least one failure in that.

s151
00:11:56.680 --> 00:12:10.960
So, you can't even debug your background agent that's running asynchronously without the right infrastructure, without the observability, without everything that's going on in that process or multiple processes.

s152
00:12:11.920 --> 00:12:16.480
And another example that we have is is loop architectures.

s153
00:12:16.480 --> 00:12:16.680
Right?

s154
00:12:16.680 --> 00:12:30.440
I think we're talking about slash loop commands and whatnot and coding agents, but I think where we're taking this is how are you building actual systems in your products that employ these these these approaches.

s155
00:12:30.440 --> 00:12:32.040
So, like what is a loop?

s156
00:12:32.040 --> 00:12:32.200
Right?

s157
00:12:32.200 --> 00:12:45.160
A loop is a system that basically just runs continuously or on a schedule and it's assessing the state of the system against the the goals that you set or the criteria that you set and determines what to do next.

s158
00:12:45.160 --> 00:12:57.400
So, you're going to need crons, sub-agent delegation, the history needs to be inspectable, and of course it needs to be reliable because you don't know when things are running or how the system is continuously

s159
00:12:57.400 --> 00:13:00.000
continuing to evolve.

s160
00:13:00.000 --> 00:13:05.120
So, the frameworks of 3 months ago were not designed to handle this.

s161
00:13:05.120 --> 00:13:05.320
Right?

s162
00:13:05.320 --> 00:13:09.200
Like you're going to need to design these systems yourself.

s163
00:13:09.200 --> 00:13:12.160
So, I think you're going to need a proper execution layer.

s164
00:13:12.160 --> 00:13:14.839
So, let's look at just some examples of code.

s165
00:13:14.839 --> 00:13:20.240
It's small on here, but in general, let's just look at how we might put it together.

s166
00:13:20.240 --> 00:13:22.080
In your loop, you're going to need some sort of cron.

s167
00:13:22.080 --> 00:13:33.240
Maybe that cron here is some sort of health check system runs every 30 minutes, pulls down some key high-level system metrics, and it looks you pass to an LLM.

s168
00:13:33.240 --> 00:13:34.480
You say, "Is this healthy?

s169
00:13:34.480 --> 00:13:35.360
Is this looking okay?

s170
00:13:35.360 --> 00:13:37.120
Should we do more?

s171
00:13:37.120 --> 00:13:38.360
And it is it is healthy or not?

s172
00:13:38.360 --> 00:13:39.600
What should we do?"

s173
00:13:39.600 --> 00:13:47.800
And if it isn't healthy, maybe you just invoke a a triage agent that goes and looks at that individual service and goes and digs more.

s174
00:13:47.800 --> 00:13:50.680
It's pretty simple looking, right?

s175
00:13:50.680 --> 00:13:52.560
Now you have this triage agent itself.

s176
00:13:52.560 --> 00:13:54.120
You've just triggered it.

s177
00:13:54.120 --> 00:13:58.520
This should maybe pull some more context, pull some detailed metrics.

s178
00:13:58.520 --> 00:13:59.920
It's just context.

s179
00:13:59.920 --> 00:14:03.640
And then you're passing to the LLM to start that investigation.

s180
00:14:03.640 --> 00:14:07.280
Putting in a loop, you're calling some tools, trying to get to the root cause.

s181
00:14:07.280 --> 00:14:09.120
This may run for a minute.

s182
00:14:09.120 --> 00:14:11.480
This may run for multiple minutes.

s183
00:14:11.480 --> 00:14:16.680
It needs to spin up a sandbox, uh maybe clone code, maybe analyze commits.

s184
00:14:16.680 --> 00:14:20.040
It's going to be doing a lot of work here, and you don't know when this is going to run.

s185
00:14:20.040 --> 00:14:21.200
It might run, it might not.

s186
00:14:21.200 --> 00:14:21.840
How do you know?

s187
00:14:21.840 --> 00:14:24.800
How do you observe that system later?

s188
00:14:24.800 --> 00:14:29.400
And then to complete the loop, there you may have a reviewer function, right?

s189
00:14:29.400 --> 00:14:34.240
Like, are we Is the system actually performing as expected?

s190
00:14:34.240 --> 00:14:34.440
Right?

s191
00:14:34.440 --> 00:14:42.960
Like, it's going to run every week and look at the history of what just happened and evaluate how the triage system is working.

s192
00:14:42.960 --> 00:14:44.120
Do we need to adjust the prompts?

s193
00:14:44.120 --> 00:14:45.680
Do we need to do better metrics?

s194
00:14:45.680 --> 00:14:47.200
Does this have the data that it needs?

s195
00:14:47.200 --> 00:14:48.680
Is it doing anything at all?

s196
00:14:48.680 --> 00:14:50.960
Is it overreacting?

s197
00:14:51.000 --> 00:14:53.280
So, it needs to be execution aware.

s198
00:14:53.280 --> 00:15:00.720
And I think it needs to be execution aware, orchestration aware, because it needs to be able to pull the logs of the system and understand, all right, what was executed?

s199
00:15:00.720 --> 00:15:03.320
What did this agent choose to execute?

s200
00:15:03.320 --> 00:15:05.839
What sub agents did it fan out?

s201
00:15:05.839 --> 00:15:09.160
What workflows did it call upon?

s202
00:15:09.160 --> 00:15:18.080
And then it needs to be able to analyze that and understand what happened and come back to you, either make the change itself or tell you this is where we performed or underperformed.

s203
00:15:18.080 --> 00:15:21.640
This is what we can do, how we can improve the system overall.

s204
00:15:21.640 --> 00:15:24.320
So, this completes this improving loop.

s205
00:15:24.320 --> 00:15:25.840
It's three functions.

s206
00:15:25.840 --> 00:15:27.680
It's pretty simple by design.

s207
00:15:27.680 --> 00:15:29.320
It's flexible to iterate on.

s208
00:15:29.320 --> 00:15:40.640
I know things get always a lot more complex in production, but I think about when when I think you think about the layers this way, makes things a little bit little bit easier to think about building such a complex system that feels like it's,

s209
00:15:40.640 --> 00:15:44.840
you know, something that you might not be able to reach right now.

s210
00:15:44.840 --> 00:15:53.640
So, in the spirit of the reviewing functions, what do you think about measuring your agent, how your agent is performing?

s211
00:15:53.640 --> 00:16:02.040
You know, I think what's interesting is this execution layer sits between what your users' input is and what's happening throughout the system.

s212
00:16:02.040 --> 00:16:10.080
So, user feedback, actions, um and the results of the sessions all flow through this execution layer.

s213
00:16:10.080 --> 00:16:15.600
And I think this makes it uh an ideal place because it becomes the hub for observability.

s214
00:16:15.600 --> 00:16:21.840
And it allows you to be able to score and understand what your agent is doing.

s215
00:16:21.840 --> 00:16:29.960
So, to iterate on your application, you kind of need all this data connected and it needs to be aware of how your code is actually executing.

s216
00:16:29.960 --> 00:16:30.240
Right?

s217
00:16:30.240 --> 00:16:33.680
So, I think the the linking of this is is extremely important.

s218
00:16:33.680 --> 00:16:37.120
So, this is what we built Ingest for.

s219
00:16:37.120 --> 00:16:40.480
We're durable execution for AI agents.

s220
00:16:40.480 --> 00:16:42.720
We're the execution layer.

s221
00:16:42.720 --> 00:16:49.360
You can plug in any context layer, bring a model, framework, tool, any compute layer.

s222
00:16:49.360 --> 00:16:50.839
Bring whatever sandbox you want.

s223
00:16:50.839 --> 00:16:52.720
Bring whatever browser you want.

s224
00:16:52.720 --> 00:16:55.680
You get durable steps, small primitives, right?

s225
00:16:55.680 --> 00:17:04.680
Uh event triggers, scheduling, agent-to-agent coordination, full session traces, no infra to manage.

s226
00:17:05.959 --> 00:17:15.800
And I think like I just mentioned with scores, we also think that that that the middle of the execution layer, when your agent is running, is a key place to instrument

s227
00:17:15.800 --> 00:17:17.880
and score your agents.

s228
00:17:17.880 --> 00:17:29.520
When you have access to the data that you need that's all flowing through there or you've just executed something, it's a perfect place to run something after and defer some scoring

s229
00:17:29.520 --> 00:17:33.600
for with the whole trace information, maybe the inputs and the outputs.

s230
00:17:33.600 --> 00:17:51.440
So, again, that's just execution orchestration, delayed task deferrals on and since there's also data flowing through, you can also wait for additional events and attach them to the sessions that you're building and understand

s231
00:17:51.440 --> 00:17:53.480
did this did this actually work, right?

s232
00:17:53.480 --> 00:17:57.600
If you're if you're running this triage, um was this triage successful?

s233
00:17:57.600 --> 00:18:00.400
Did it result in an action by the engineering team?

s234
00:18:00.400 --> 00:18:02.680
Then that means it probably was a positive result.

s235
00:18:02.680 --> 00:18:06.160
Instead of a thumbs up, thumbs down, it's like did we open the PR, right?

s236
00:18:06.160 --> 00:18:09.720
If it's a research agent, was this research saved?

s237
00:18:09.720 --> 00:18:11.040
Was it a good report?

s238
00:18:11.040 --> 00:18:20.600
That is these these things that are events that you should be able to attach and when you have a system that can connect all these pieces, I think it's really makes doing a lot of those things

s239
00:18:20.600 --> 00:18:25.120
um like creating outcome-based scores a lot easier.

s240
00:18:25.120 --> 00:18:30.080
So, to wrap up, build your harness.

s241
00:18:30.080 --> 00:18:32.960
You know, understand the layers of the architecture.

s242
00:18:32.960 --> 00:18:37.160
We have to embrace fast-paced pace of change.

s243
00:18:37.160 --> 00:18:44.640
And I think if you can get your execution layer right and think about the right primitives, everything else can quickly evolve around it.

s244
00:18:44.640 --> 00:18:50.960
And the next 6 months, the next 3 months will all be a lot easier for especially as everything continues to change.

s245
00:18:50.960 --> 00:18:52.160
You all are here.

s246
00:18:52.160 --> 00:18:54.320
So, thanks for listening.

s247
00:18:54.320 --> 00:18:55.640
I'm Dan.

s248
00:18:55.640 --> 00:18:57.240
Um come and find me at the ng-js booth.

s249
00:18:57.240 --> 00:18:58.720
We're right on the other side of this wall.

s250
00:18:58.720 --> 00:19:00.800
We're very bright and orange.

s251
00:19:00.800 --> 00:19:02.080
So, thanks everyone.

s252
00:19:02.080 --> 00:19:04.400
Appreciate it.

s253
00:19:18.053 --> 00:19:19.560
[music]

s254
00:19:19.560 --> 00:19:21.560
Mhm.