WEBVTT

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

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/32nrHU6zHU8.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.680 --> 00:00:14.120
Right.

s3
00:00:14.120 --> 00:00:15.400
Hello, everybody.

s4
00:00:15.400 --> 00:00:17.200
Um welcome to our talk.

s5
00:00:17.200 --> 00:00:18.680
My name is Roberto Milev.

s6
00:00:18.680 --> 00:00:21.320
I am the chief architect at Navan.

s7
00:00:21.320 --> 00:00:25.360
And I have Uday here, who's also part of the architecture team.

s8
00:00:25.360 --> 00:00:30.160
Uh Navan is a travel and expense management company.

s9
00:00:30.160 --> 00:00:37.920
And we'll share with you some of our learnings around how you run an AI and what have we uh discovered.

s10
00:00:37.920 --> 00:00:47.320
So, uh if you've been long enough um in this industry, you remember that over time there are a few paradigm shifts.

s11
00:00:47.320 --> 00:00:53.280
And we all tend to jump on a bandwagon and try to uh kind of do things, all right?

s12
00:00:53.280 --> 00:00:58.320
Last time was when we all jumped on the microservices bandwagon.

s13
00:00:58.320 --> 00:01:04.480
And out of that, a lot of good things came out, like container orchestration, Kubernetes.

s14
00:01:04.480 --> 00:01:10.960
Then we had service mesh, uh circuit breakers, all of those good things.

s15
00:01:10.960 --> 00:01:12.560
But it didn't happen overnight.

s16
00:01:12.560 --> 00:01:14.560
Like it took a long time.

s17
00:01:14.560 --> 00:01:18.160
It took some time for us to learn how to do these things.

s18
00:01:18.160 --> 00:01:25.160
So, one of the quotes from there is, "If you can't build a well-structured monolith, why even try to build microservices?"

s19
00:01:25.160 --> 00:01:37.600
Uh it kind of translates today because if you can't build a single agentic loop, why go in and try to build a multi-agent orchestrated system?

s20
00:01:37.880 --> 00:01:44.280
So, over time, just like previously, uh a reference architecture is emerging.

s21
00:01:44.280 --> 00:01:50.360
So, we have learned a few things by by doing in production.

s22
00:01:50.360 --> 00:01:55.280
We have a lot of agents, a lot of tokens per day being used.

s23
00:01:55.280 --> 00:02:07.920
And as I said, there are few layers that have standardized, that have crystallized around what do we need to run agentic flows reliably in production.

s24
00:02:07.920 --> 00:02:16.040
Runtime memory, context management, all around operational cross-cutting concerns, and around orchestration as well.

s25
00:02:16.040 --> 00:02:26.440
So, today we'll go over some of these layers, all of these layers actually, and we will show kind of where the industry is, what we have done, what we have learned,

s26
00:02:26.440 --> 00:02:28.560
and and so on.

s27
00:02:28.560 --> 00:02:40.680
So, starting at the runtime layer, we've talked a lot and we've built a lot of services in order to scale them statelessly before.

s28
00:02:40.680 --> 00:02:44.880
And now we're in a new world where, you know, agents are stateful by nature.

s29
00:02:44.880 --> 00:02:48.440
They need to have persistent sessions.

s30
00:02:48.440 --> 00:02:50.840
They need to have isolation.

s31
00:02:50.840 --> 00:02:57.560
Their life cycle is different than the life cycle of a traditional API service, and so on.

s32
00:02:57.560 --> 00:03:03.680
So, the cloud providers have jumped in and try to fill this gap.

s33
00:03:03.680 --> 00:03:13.160
Um, you know, AWS, GCP, Azure, they all have a some incarnation of a agentic runtime.

s34
00:03:13.160 --> 00:03:23.720
If you scan the QR code for this slide and for the following slides, you will see a comparison of some of the features and how different cloud providers try to try to

s35
00:03:23.720 --> 00:03:25.120
approach this.

s36
00:03:25.120 --> 00:03:28.800
At Nvono, we run everything on AWS.

s37
00:03:28.800 --> 00:03:31.280
AWS has an agent core runtime.

s38
00:03:31.280 --> 00:03:41.480
We heavily use that, but we have filled some gaps around that, like the session persistence and rehydration is something that we have built.

s39
00:03:41.480 --> 00:03:47.200
And we also run a bunch of other bunch of SDKs for writing agents.

s40
00:03:47.200 --> 00:03:57.000
And part of these runtimes is typically they are framework agnostic, although they all prefer their native framework in a way.

s41
00:03:57.640 --> 00:04:03.120
Um the next layer in the stack is around memory.

s42
00:04:03.120 --> 00:04:05.920
Um we started with rag.

s43
00:04:05.920 --> 00:04:08.720
Rag was kind of a big thing for a while.

s44
00:04:08.720 --> 00:04:18.120
We were kind of driven to that out of necessity because you cannot fit an unlimited amount of context into an agent.

s45
00:04:18.120 --> 00:04:32.400
And over time um all of these cloud providers and the industry has implemented a pipeline where memory is kind of automatically generated by following a workflow of ingestion, extraction,

s46
00:04:32.400 --> 00:04:34.919
and then consolidation and retrieval.

s47
00:04:34.919 --> 00:04:43.600
And there are parts of rag that are built in things like a long-term memory that inherently has some semantic characteristics.

s48
00:04:43.600 --> 00:04:51.640
But memory is built up over time from short-term conversational memory to long-term memory that you kind of manage yourself.

s49
00:04:51.640 --> 00:04:57.760
Uh then episodic memories about kind of instances that worked well and didn't work well.

s50
00:04:57.760 --> 00:04:58.880
Uh and so on.

s51
00:04:58.880 --> 00:05:06.360
We at Navan again being a AWS shop, um utilize their agent core memory.

s52
00:05:06.360 --> 00:05:13.640
But we are also kind of doing it in a way that uh matches matches our our use case.

s53
00:05:14.000 --> 00:05:16.919
And then the next thing is context management.

s54
00:05:16.919 --> 00:05:18.040
You know, it's a hot topic.

s55
00:05:18.040 --> 00:05:20.440
It was a hot topic and it's still a hot topic.

s56
00:05:20.440 --> 00:05:31.000
Context windows are growing bigger, but there's never enough context or if there is too much context again, agents struggle with that cuz you lose focus and so on.

s57
00:05:31.000 --> 00:05:38.720
Um what we found working is that uh focusing on skills as a unit of context.

s58
00:05:38.720 --> 00:05:40.800
And I'll explain what I mean by that.

s59
00:05:40.800 --> 00:05:49.600
Uh we look at skills as both having context, meaning instructions and uh setup about a certain domain or a task.

s60
00:05:49.600 --> 00:05:56.600
And there's also the the second part of the skill, which is the tool execution and you know, the agentic part.

s61
00:05:56.600 --> 00:06:11.480
And we compose context dynamically out of skills that we use as units of work that are pluggable, that we can test independently, and that we can reuse.

s62
00:06:11.480 --> 00:06:19.320
So, for example, when we are we have an agent, we have skills that are that are specific to a domain.

s63
00:06:19.320 --> 00:06:21.560
And based on that, we compose them.

s64
00:06:21.560 --> 00:06:34.760
And we rely on the you know, the progressive disclosure, which is a feature of the skills itself to start with a limited scope of context and then expand by included

s65
00:06:34.760 --> 00:06:39.200
metadata further down the the line.

s66
00:06:39.200 --> 00:06:44.919
I'll hand it over to Uday Uday now to kind of walk us through the rest of this.

s67
00:06:44.919 --> 00:06:46.600
Thanks, Rudra.

s68
00:06:46.600 --> 00:06:47.360
All right.

s69
00:06:47.360 --> 00:07:00.400
Can I have a quick show of hands here who have who had built an agent uh which failed halfway through multi 20 20 step or 30 step process and be able to figure out quickly

s70
00:07:00.400 --> 00:07:03.800
or reason about why the agent failed.

s71
00:07:05.280 --> 00:07:11.480
So, again, logs we've generally been traditionally with microservices, we all are familiar with logs.

s72
00:07:11.480 --> 00:07:13.960
There's logs out there and then we go check out the logs.

s73
00:07:13.960 --> 00:07:17.800
But this changes everything the moment we switch to agents.

s74
00:07:17.800 --> 00:07:20.440
Agents output a lot of thinking.

s75
00:07:20.440 --> 00:07:22.040
There's too much to consume.

s76
00:07:22.040 --> 00:07:23.760
So, that's not the right way to do it, right?

s77
00:07:23.760 --> 00:07:28.720
So, traditionally, that was the way, but our thought has to be changed right now.

s78
00:07:28.720 --> 00:07:40.240
In the in the way they Claude as an example, when we take Claude as an example for an agent, there is hooks and we can intercept everything that Claude as an agent that does at that level.

s79
00:07:40.240 --> 00:07:43.160
So, what kind of tool it calls, right?

s80
00:07:43.160 --> 00:07:44.560
What kind of decision it's making?

s81
00:07:44.560 --> 00:07:54.800
So, before pre-tool and post-tool call or a pre-decision or a post-decision, so all of that are a point point in time for us to intercept and make a decision

s82
00:07:54.800 --> 00:08:01.880
and either block to do a blocking operation or to log in metric or emit a metric, right?

s83
00:08:01.880 --> 00:08:06.840
So, this is a critical place where we can emit auto traces.

s84
00:08:06.840 --> 00:08:20.520
At Nvone, we use one of our provider to interest to emit these auto traces and through these traces we should be able to figure out the spans, the traces and at what point in time where the agent is stuck,

s85
00:08:20.520 --> 00:08:26.240
which gives much more confidence into how we operate and build the agent.

s86
00:08:26.240 --> 00:08:29.520
This is day-to-day operational challenge.

s87
00:08:29.520 --> 00:08:37.640
Building agent these days there's so many frameworks, but how do you navigate building and operating an agent later is primary concern.

s88
00:08:37.640 --> 00:08:50.640
Um And moreover, the reasoning chain, the thought process and critical signals that we emit here as part of the trace captures, we emit a few primary signals here.

s89
00:08:50.640 --> 00:08:58.160
What is the current goal the agent is going through, the reasons behind its operations and the belief status and the tool calls that it's making.

s90
00:08:58.160 --> 00:09:00.720
So, this kind of gives us a judgment pointers.

s91
00:09:00.720 --> 00:09:03.120
Um Um in the traces.

s92
00:09:03.120 --> 00:09:12.000
And when we make when the agent makes a decision, there is a confidence score, how confident it is when it makes the judgment, right?

s93
00:09:12.000 --> 00:09:18.360
So, whether there are multiple paths that it leads to this choice or whether this is an inferred answer.

s94
00:09:18.360 --> 00:09:22.960
So, basically these are signals that gives us confidence later to review.

s95
00:09:22.960 --> 00:09:30.800
If this is an inferred answer, there could be a human in the loop to guide through and tweak the agent to perform a little better.

s96
00:09:32.480 --> 00:09:43.640
Again, um Can I have a raise of hands again to see how confident are you like 100% confident in testing pipelines with your agents?

s97
00:09:43.720 --> 00:09:43.960
Right.

s98
00:09:43.960 --> 00:09:49.240
So, this is one of the other um critical aspect today.

s99
00:09:49.240 --> 00:09:53.080
Um Because agents are non-deterministic.

s100
00:09:53.080 --> 00:09:57.760
We've all been used to program and write much more deterministic flows.

s101
00:09:57.760 --> 00:10:00.280
And we know how it works.

s102
00:10:00.280 --> 00:10:01.800
The Can I ask an engineer?

s103
00:10:01.800 --> 00:10:05.000
Engineer can come and tell me how this the algorithm, the sequence of operations.

s104
00:10:05.000 --> 00:10:06.400
Everything is programmed in our mind.

s105
00:10:06.400 --> 00:10:08.080
Everything is expectations.

s106
00:10:08.080 --> 00:10:10.920
But now the agents come into a non-deterministic way.

s107
00:10:10.920 --> 00:10:11.960
And how do we test them, right?

s108
00:10:11.960 --> 00:10:14.000
So, that is very criticality here.

s109
00:10:14.000 --> 00:10:15.800
And yeah.

s110
00:10:15.800 --> 00:10:17.200
We are also struggling.

s111
00:10:17.200 --> 00:10:20.680
Um we've uh started doing building agents.

s112
00:10:20.680 --> 00:10:24.560
We the day to operations was challenging and then we failed in a lot of steps.

s113
00:10:24.560 --> 00:10:25.360
How do we course correct?

s114
00:10:25.360 --> 00:10:29.600
The moment we change something, something else broke breaks, right?

s115
00:10:29.600 --> 00:10:30.640
So, how do we do that?

s116
00:10:30.640 --> 00:10:46.680
Um one one approach that we took uh this is from um research papers uh around the in a multi-step uh orchestration, when an agent makes uh 30 steps or decisions to make to reach to a goal,

s117
00:10:46.680 --> 00:10:49.680
if that is a program or that's a different story.

s118
00:10:49.680 --> 00:10:50.760
But this is not a program.

s119
00:10:50.760 --> 00:10:58.320
This is non-deterministic way of It makes up its own steps every time uh differently.

s120
00:10:58.320 --> 00:11:03.240
So, how can we chart a deterministic graph here?

s121
00:11:03.240 --> 00:11:04.360
Is it possible?

s122
00:11:04.360 --> 00:11:17.320
No. Can we have a trajectory of its starting from an end to a goal and then see how much how far it went in the trajectory and how far it went from the source to the destination

s123
00:11:17.320 --> 00:11:26.680
is what we can compute to evaluate the efficiency or the completeness of the agent agent evaluation.

s124
00:11:26.680 --> 00:11:38.560
So, we we heavily rely on um trajectory vals um and uh this There are few other signals uh as I briefly spoke around uh in the previous slide around the inferred signal.

s125
00:11:38.560 --> 00:11:55.240
Um If the answer is from an in in inferred answer, uh how can we uh loop that into uh and make a signals around uh how can we classify that this is a regression and make fixes towards the agent?

s126
00:11:59.120 --> 00:12:06.280
Uh So, the next is the uh guardrails.

s127
00:12:06.280 --> 00:12:12.960
Um Where Is this the one?

s128
00:12:12.960 --> 00:12:14.960
Yeah.

s129
00:12:15.200 --> 00:12:24.800
So, guardrails and authorization, um this is uh critical displays a critical role in enterprise AI.

s130
00:12:24.960 --> 00:12:28.800
A lot of information is being piped to models.

s131
00:12:28.800 --> 00:12:33.520
Um there could be sensitive information that goes into it uh without our knowledge.

s132
00:12:33.520 --> 00:12:43.400
And we as uh uh leaders, how can we put in this governance layer um to stop this um is very uh critical here.

s133
00:12:43.400 --> 00:12:51.120
And and the concept of uh authentication and authorization um is taking up a different approach here.

s134
00:12:51.120 --> 00:12:57.400
Um traditionally, we've seen um a user or a service account, but now what is an agent?

s135
00:12:57.400 --> 00:13:00.360
Agent can be acting as on behalf of users.

s136
00:13:00.360 --> 00:13:03.560
There is so much of things uh so many of use cases there.

s137
00:13:03.560 --> 00:13:07.400
Hey, book me a flight whenever it's cheaper than $200, right?

s138
00:13:07.400 --> 00:13:12.720
So, we just tell this assertion and then agent go figures out and does this action on behalf of me.

s139
00:13:12.720 --> 00:13:17.960
So, is it me making this purchase or is it agent me making on behalf of me?

s140
00:13:17.960 --> 00:13:24.680
So, there is Agent acts as a on behalf of user or agent uses a service account as well.

s141
00:13:24.680 --> 00:13:36.080
So, the line is being blurred here and we need to make fine-grained authorization decisions here, and the policy layer that's where the guardrails and authentication authorization plays a critical role.

s142
00:13:36.080 --> 00:13:49.480
And in the one what we employ here is before every tool call pre-tool and post-tool, we have this guardrails to check and block and make a informed decisions.

s143
00:13:52.000 --> 00:14:03.320
And this single agent versus multi-agent, again, this is kind of a orchestration wars you can think of with it to build a single agent or a multi-agent.

s144
00:14:03.320 --> 00:14:12.120
Again, as Roberto briefly hinted if you can't perfect and build a single agent, why go towards multi-agent, right?

s145
00:14:12.120 --> 00:14:18.200
So, learn from our uh failures, experiences, and build towards that.

s146
00:14:18.200 --> 00:14:20.200
At Navan, yeah.

s147
00:14:20.200 --> 00:14:26.960
What the approach that we have taken is single master, and then we adopted sub-skills.

s148
00:14:26.960 --> 00:14:29.480
Um There are sub-agents within it.

s149
00:14:29.480 --> 00:14:44.000
So, it's a single agent that can progressively load the skills and understand decisively what needs to be loaded into the context, and then make this navigation through the use case.

s150
00:14:44.000 --> 00:14:48.320
But there are other patterns that are also emerging.

s151
00:14:48.320 --> 00:14:50.160
There are different class of use cases here.

s152
00:14:50.160 --> 00:14:53.160
One is um agent-to-agent communication.

s153
00:14:53.160 --> 00:15:02.680
So, there are If you take a large scale organization, and there are so many of these teams that are that are acting as the boundaries, and they don't talk to each other, let's say.

s154
00:15:02.680 --> 00:15:03.560
How do we communicate?

s155
00:15:03.560 --> 00:15:06.440
There are two agents on either of the side, right?

s156
00:15:06.440 --> 00:15:07.200
How do we do it?

s157
00:15:07.200 --> 00:15:14.360
So, there is A2A protocol which can help us establish the contracts in terms of skills.

s158
00:15:14.360 --> 00:15:22.200
And we can use A2A as a protocol there, which kind of is a boundary between the teams.

s159
00:15:22.680 --> 00:15:25.440
Yeah, over to you, Uday.

s160
00:15:29.080 --> 00:15:29.520
All right.

s161
00:15:29.520 --> 00:15:40.920
So, as we went through the stack, it's obvious that um some components of the stack are in a more mature state and we already have good answers for them.

s162
00:15:40.920 --> 00:15:43.920
As Uday said, the runtime, I think it's pretty much solved.

s163
00:15:43.920 --> 00:15:51.120
We are so advanced in orchestration and we are running LLMs in kind of uh a very uh brute-force way.

s164
00:15:51.120 --> 00:15:53.600
So, scaling is not a not a problem.

s165
00:15:53.600 --> 00:16:10.520
Also, memory, I think uh as uh the frontier LLMs get better and as our practices get better, we will uh find a way to cover the majority of the use cases and there is good maturity around the the cloud providers.

s166
00:16:10.520 --> 00:16:18.640
Uh MCP has emerged as the de facto protocol and tool calling is now a feature that everybody supports.

s167
00:16:18.640 --> 00:16:25.560
So, we are seeing some industry convergence around that as well and MCP as a standard is also evolving.

s168
00:16:25.560 --> 00:16:27.360
Now, it's becoming stateless.

s169
00:16:27.360 --> 00:16:35.520
It's uh we are reaching a point where kind of we know how to invoke uh services and and and tools with agents.

s170
00:16:35.520 --> 00:16:41.839
Uh in some areas, things are happening, but you know, there's still a lot of unknown.

s171
00:16:41.839 --> 00:16:49.240
Around observability, there is a push towards OTEL, but does OTEL really work for agentic calls?

s172
00:16:49.240 --> 00:16:52.680
Uh yeah, you can make it work as Uday was saying.

s173
00:16:52.680 --> 00:16:59.120
Um also, we are getting more comfortable around um around that the the the the testing patterns.

s174
00:16:59.120 --> 00:17:09.360
It's very hard to test, but we have found a way to give customers um quality experiences even with the unreliability of agentic system and I think that's kind of

s175
00:17:09.360 --> 00:17:15.079
uh getting in a in a state that is uh that is more better defined.

s176
00:17:15.079 --> 00:17:27.520
Orchestration is another one um, where, you know, we have a uh, we have patterns, uh, we can build, you know, bigger agents, smaller agents.

s177
00:17:27.520 --> 00:17:34.040
Uh, as we said previously, probably the right answer is to not over-engineer.

s178
00:17:34.040 --> 00:17:41.600
Uh, so we're learning there and and and uh, a pattern of school thought is also emerging.

s179
00:17:41.600 --> 00:17:54.360
Uh, where we're all struggling with and the previous talk was about this for the developer, um, AI assistant development perspective, but also we're seeing these issues from our production agents.

s180
00:17:54.360 --> 00:18:07.360
It's very hard to predict cost and it's very hard to manage cost, uh, and put guardrails and solve this in a way where there is reliable, maybe fallback or have agents be,

s181
00:18:07.360 --> 00:18:11.200
uh, using cheaper models for certain tasks.

s182
00:18:11.200 --> 00:18:21.440
Uh, uh, this is all driven by kind of the big AI vendors who, I think, their interest is for us all to spend more tokens.

s183
00:18:21.440 --> 00:18:26.280
Um, replay and debugging, Woody talked about that, that's also a big big issue.

s184
00:18:26.280 --> 00:18:41.880
It's very hard to understand, but I think this is also something that that is going to be solved because we can now use, uh, agents to uh, get over the cognitive overload of trying to debug

s185
00:18:41.880 --> 00:18:43.400
what they do.

s186
00:18:43.400 --> 00:18:50.960
And then standards, um, standards are emerging uh, by, you know, the community.

s187
00:18:50.960 --> 00:19:00.520
Uh, Hotel, as I mentioned, agent to agent is young, it's kind of pushed by certain vendors, but I think over time we will we will get, uh, there.

s188
00:19:00.520 --> 00:19:07.760
Uh, with all of this said, you know, we know what we need and it's up to us to write and build it.

s189
00:19:07.760 --> 00:19:09.538
Thank you, everybody.

s190
00:19:09.538 --> 00:19:11.538
[applause]

s191
00:19:27.000 --> 00:19:29.000
I