← All AI Engineer talks

AI Engineer World's Fair 2026

The Half Life of Agent Infrastructure — Ben Kus, Box

Ben Kus· Box19:26

Read the talk

The Half Life of Agent Infrastructure

Ben Kus draws on Box’s agent rebuilds to explain why rapid technical change demands replaceable infrastructure, customer-relevant evaluations and teams prepared to adapt.

From a talk by Ben Kus

At a glance

Ideas worth remembering

  • A sound agent architecture can become less competitive within months. Kus’s half-life comparison is a planning judgment, not a measured expiration date.

  • Prepare teams for replacement and use abstractions to make underlying components swappable. Repeated rebuilds affect trust and morale as well as implementation effort.

  • Regular review does not require automatic migration. Box reviews AI technology every six months; switching should depend on customer-relevant evaluations of cost, speed, quality and capabilities.

  • Assess vendors by their available capabilities and their record of handling change. Adaptability may outlast the advantage of any particular technical approach.

Change at enterprise scale

Ben Kus, CTO of Box, approaches agent infrastructure through the experience of building enterprise software. His question is how to keep adapting infrastructure while the technologies underneath AI agents continue to change. That enterprise context matters: some of his lessons concern organizational scale and commitments that may differ from those of a consumer company.

Kus describes Box as operating with over an exabyte of data, tens of millions of users and hundreds of billions of files or other pieces of unstructured content. Tokens add another dimension: he puts Box in the ballpark of a trillion tokens and anticipates 10 trillion sometime soon, without specifying a measurement period. These quantities establish the scale of the infrastructure decisions he is discussing.

He places AI alongside earlier transitions through the internet, mobile devices and cloud computing. Those shifts created opportunities for new companies and forced established companies to adapt. Kus says he had two startups and was acquired twice, once by IBM and once by Box. He sees the current transition as another major opening—but one that will test familiar engineering advice.

0:120:15
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:01 · section reference included

When sound architecture advice ages quickly

Kus’s conventional advice followed a useful sequence: choose technology for a scalable, reliable platform; become good at that stack; use it to build customer capabilities; then optimize speed, cost and functionality. The sequence rewards accumulated expertise. A team that keeps improving a platform can spend more of its effort on the product it supports.

He now questions whether that advice fits agent infrastructure because its foundations are changing unusually quickly. Earlier transitions retained durable foundations: he points to HTTP for the internet and iOS and Android for mobile devices. In generative AI, he argues, much of the machinery powering applications remains unsettled.

His own previous conference talk supplies the example. He had recommended graph-based agents: developers construct a graph of nodes, and an LLM-powered agent traverses that graph to carry out a workflow. The approach makes the developer’s graph central to how the agent organizes its work. Kus believed in it, and an attendee told him it answered exactly the problem he faced.

A year later, Kus still likes the approach but considers it somewhat dated. He wonders what happened to the attendee who had thanked him for advice relevant to his problem. His explanation is that a better approach emerged after a reasonable decision had been made. Looking back at other conference talks, he sees the same pattern: useful ideas can lose their leading position quickly without having been bad ideas when presented.

3:053:07
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

2:44 · section reference included

Model selection becomes an ongoing decision

Kus traces a succession of model strategies. Training or fine-tuning a model gives way to using frontier models from OpenAI, Anthropic or Gemini. Their expense motivates interest in open-weight models that a company can host on its own GPUs. Enterprise purchasing adds another requirement: customers with existing provider agreements may want to bring their own key or model. Each shift changes what an application must support, from model ownership to hosting and customer-selected access.

His provisional preference is adaptive model selection: choose among larger and smaller models according to which performs well for the work. Model choice therefore becomes something the system can vary instead of a single decision fixed at adoption. He offers this as the latest promising approach in the sequence, without specifying a routing algorithm or presenting comparative results.

6:226:23
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

6:16 · section reference included

From fixed workflows to agents with their own execution environment

Agent design follows a similarly compressed progression in Kus’s account: a single LLM response, chain-of-thought reasoning, graph-based systems and then agents that make their own plans. The important architectural change is who determines the workflow. In the graph approach, developers construct the structure the agent follows; in the planning approach, the agent figures out what to do.

The choices then extend to dedicated subagents versus a generic agent that works recursively and receives skills. A sandbox adds another capability: the agent can write and execute code in its own computing environment. Kus presents this as a way to use agents’ programming abilities. Finally, he raises bring-your-own-harness support, allowing people to select another agent system. These alternatives move the application’s integration boundary as well as changing its internal implementation; the talk does not establish one as a permanent winner.

7:057:10
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

7:05 · section reference included

Retrieval changes along with the models

For context retrieval, Kus starts with BM25 and keyword search, then moves to retrieval-augmented generation using embeddings and approximate nearest-neighbor search. He argues that this approach can perform poorly at scale, describing results as increasingly resembling randomness. Graph-based retrieval introduces its own difficulty in getting it to work well. These are his qualitative assessments; he supplies no benchmark or scale threshold that would establish a general failure boundary.

Hybrid retrieval combines lexical and semantic search and fuses their rankings. Agentic search adds an agent’s ability to find information and apply intelligence to reaching the relevant material. Kus’s stated preference includes agentic search powered by hybrid retrieval, so the progression can retain an earlier retrieval mechanism underneath a newer agent approach. He treats these as successive contenders for the leading approach, rather than demonstrating that every earlier technique should be discarded.

Several forces could change the preferred architecture again. Kus credits a transition between Opus models with substantially better instruction following. Faster, cheaper hardware may change how many tokens a system can use. Enterprise adoption also matters: a customer might standardize on one agent, use agents from several platforms, or combine both strategies. Model capability, computing economics and customer choices all influence which infrastructure makes sense.

8:058:07
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

8:05 · section reference included

A half life measured in months

Kus distinguishes agent infrastructure from subjects where established advice remains useful for years: large-scale databases, identity and access controls, scaling engineering teams and multicloud storage. For those systems, going deep and switching rarely still has a rationale. Migrations are difficult, introduce breakage and often take more effort than expected. The existence of something better does not by itself justify paying that switching cost.

He characterizes conventional infrastructure with a three-to-five-year half life and AI technology with a half life measured in months. This is a planning metaphor, not a measured decay rate: a few months after adopting what appears to be the best option, a team may face a significant chance of needing to replace it. The consequence is that replacement becomes a recurring consideration during product development.

That shorter horizon affects different groups in different ways. Engineers see recently acquired expertise and freshly built systems age quickly. Startups betting on one approach can themselves face disruption from the next wave. Buyers risk making commitments, including three-year deals, to technology they may soon want to replace. Investors can see an apparently compelling opportunity change underneath them. Kus’s response is to make changing well an explicit capability.

10:1510:23
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

10:15 · section reference included

The human cost of rebuilding a working agent

Kus illustrates the difficulty with Box’s move from graph-based agents to a more looping, deep-agent style. An engineer had made agentic search and deep research work as requested. Kus then asked him to rebuild it using the newer technology because the existing system was less capable than desired. From the engineer’s perspective, the implementation worked and the requirements appeared to have changed after delivery.

The engineer completed the rebuild successfully. Two months later, with the product shipping on Tuesday, Kus proposed another rebuild starting Wednesday. The team wanted time to improve the existing approach and questioned whether the next choice would change again. Kus’s answer was that it probably would. Repeated replacement can therefore damage confidence in leadership as well as morale: people need to understand why completed work is being superseded and why the next decision is still worth committing to.

13:0313:06
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

12:55 · section reference included

Prepare people and make the underlying technology replaceable

His first recommendation is to prepare people explicitly: in AI work, change is expected, and replacing an approach does not necessarily mean the team made a mistake. This also helps technology reviewers make decisions. Kus describes reviewers who could not promise that a choice would remain best two years later. His response was to accept that uncertainty, choose something and build with future change in mind.

The corresponding engineering mechanism is an abstraction that allows the underlying technology to be swapped. Kus describes Box’s agent layer as letting the company select different components underneath while the agent continues to work the same way for customers. The intended benefit is continuity in the customer experience while the implementation improves. He does not specify the interface or claim that this removes every migration cost.

Box also gives reassessment a regular cadence. Kus says it reviews AI technology every six months, even when the team likes the current choice, compared with roughly three years for other technology. A scheduled review makes uncertainty part of normal operation. It creates a time to reconsider the decision without treating the original adoption as a failure.

14:2414:28
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

14:24 · section reference included

Use evaluations to decide whether a change matters

Readiness to change needs a decision rule. Kus cautions against switching because a new paper is exciting or a technique has become fashionable, even when enthusiasm comes from the CEO. His proposed test is whether the change improves something customers care about.

Evaluation sets make that test repeatable: give the system the same inputs, define the expected outputs and grade cost, speed, quality and capabilities. If a new approach performs better on customer-relevant evaluations, strongly consider switching. If it does not, retain the existing approach or do a limited amount of additional work to determine whether the alternative has been adequately explored. Kus supplies the comparison dimensions, but no numerical threshold or weighting for resolving tradeoffs between them.

15:5015:53
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

15:50 · section reference included

Choose partners that have demonstrated adaptability

Kus’s final recommendation starts from a practical limit: no individual or team can keep up with everything. Depending on vendors and platforms is one way to share that burden. Their current capabilities remain the most important selection criterion, and their roadmap should fit the buyer’s direction. He adds another source of evidence: examine how they responded to previous changes.

Look back six months or a year and ask how the vendor handled the transitions it encountered. Kus says several vendors he likes have reinvented themselves three times in the last year. Their familiarity with agent technology, evaluation sets and observability gives him more confidence that they can respond to the next development. That history offers evidence of adaptability, though it does not guarantee future performance; the buyer still has to evaluate whether the platform remains a good choice.

After a brief invitation to discuss unstructured content and AI with Box, Kus closes with a prediction: companies that become dominant through this transition will probably change their technical approach multiple times on the way. He leaves room for those companies to be new, medium-sized or already large. Their potential advantage is the ability to adapt repeatedly as the available technology changes—an advantage he also treats as provisional.

16:4516:49
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

16:45 · section reference included

Read the complete timestamped transcript
  1. 0:01

    [music]

  2. 0:12

    Hi everyone, I'm Ben Kuss. I'm CTO of

  3. 0:15

    Box and today I'm going to be talking

  4. 0:16

    about uh building for change and

  5. 0:19

    specifically around uh AI agents and how

  6. 0:22

    to continue to adapt uh your

  7. 0:24

    infrastructure as we are all in the

  8. 0:26

    middle of this journey.

  9. 0:28

    Um, so before I get too far, I will

  10. 0:30

    quickly sort of set a little bit of like

  11. 0:32

    who I am and uh sort of what I do. Um,

  12. 0:36

    for Box, I'm CTO and one of my jobs in

  13. 0:39

    my job for my whole career has been to

  14. 0:41

    build enterprise software. And so if

  15. 0:43

    today um you're from a consumer company

  16. 0:46

    or you're uh not involved in enterprise,

  17. 0:48

    I hope that a lot of it is still

  18. 0:49

    relevant. But in many cases um a lot of

  19. 0:52

    the lessons I've learned are enterprise

  20. 0:53

    uh specific.

  21. 0:56

    So um I sort of will highlight um when

  22. 1:00

    I'm thinking and talking about

  23. 1:01

    infrastructure when I'm talking about uh

  24. 1:03

    the kind of challenges that we face um

  25. 1:05

    I'm typically talking about things that

  26. 1:07

    are sort of in a scale of like uh like

  27. 1:09

    for box we have over an exabyte of data

  28. 1:12

    not a gigabyte not a terabyte not a

  29. 1:14

    pabyte but an exabyte um and then

  30. 1:16

    oftentimes we're I'm thinking in the

  31. 1:17

    tens of of millions of users uh the

  32. 1:20

    hundreds of billions of things in our

  33. 1:22

    case files or content or unstructured

  34. 1:24

    content um and then the new stat that is

  35. 1:26

    sort of the the one that we talk about

  36. 1:28

    is uh tokens. Um so we are now in the

  37. 1:31

    ballpark of trillion tokens probably

  38. 1:33

    will be 10 trillion tokens sometime

  39. 1:35

    soon. Um and this of course is uh uh

  40. 1:38

    some of the new and interesting

  41. 1:39

    challenges that this kind of scale

  42. 1:40

    brings.

  43. 1:43

    Um so in my career and um I think maybe

  44. 1:46

    many of us here um we've kind of lived

  45. 1:49

    through these this these technology

  46. 1:50

    changes. And so taking a quick step back

  47. 1:52

    um I started uh my career when the

  48. 1:55

    internet was sort of becoming a thing uh

  49. 1:58

    lived through mobile and sort of this

  50. 2:00

    idea of like you know carrying these

  51. 2:02

    different devices move to the cloud

  52. 2:03

    where you could kind of store and

  53. 2:04

    maintain all your data and then of

  54. 2:06

    course we're all in the middle of this

  55. 2:07

    AI change and I think when you see these

  56. 2:09

    kind of technology disruptions when

  57. 2:11

    you're sort of thinking about this idea

  58. 2:13

    of like all of these kind of have

  59. 2:14

    changed all of our lives um and then uh

  60. 2:17

    and you're thinking about it from the

  61. 2:18

    perspective of a technology leader or a

  62. 2:21

    startup or a engineer. Um, you kind of

  63. 2:24

    see that like these are where like major

  64. 2:27

    companies are born. Um, you see that

  65. 2:29

    like big companies adapt or die. Um,

  66. 2:32

    small companies are here to disrupt

  67. 2:33

    things. They're here to take bets.

  68. 2:34

    They're here to grow. Um, I've had two

  69. 2:36

    startups. I've been acquired twice. Once

  70. 2:38

    in IBM, once in a box. Um, and um, so

  71. 2:41

    that we're in the middle of this kind of

  72. 2:42

    major opportunity.

  73. 2:44

    Um but for um a long tu uh no matter

  74. 2:48

    what you kind of come from and what area

  75. 2:50

    you're at I uh t typically if you were

  76. 2:52

    to ask my advice um and about kind of

  77. 2:55

    what makes it you successful as an

  78. 2:57

    company as an engineering organization

  79. 2:59

    as a technology startup or as a like a

  80. 3:02

    company who has a a technology division

  81. 3:05

    um I would say no matter what there's

  82. 3:07

    kind of three things the first is you

  83. 3:10

    need to build scalable reliable uh

  84. 3:12

    platforms and select the technology that

  85. 3:14

    you care about. Meaning that like

  86. 3:16

    there's a lot of ways to do things, but

  87. 3:18

    get good at something. Get good at that

  88. 3:19

    technology, at that system, at that

  89. 3:21

    stack, and then and then keep going with

  90. 3:22

    that. Um, and then you leverage this

  91. 3:25

    technology so that you do more for your

  92. 3:27

    customers. Um, you build your better

  93. 3:29

    product, you develop the capabilities,

  94. 3:30

    and then you optimize it, make it

  95. 3:32

    better, make it faster, make it cheaper,

  96. 3:35

    make it uh more capable. And this was

  97. 3:38

    sort of the generic enterprise advice,

  98. 3:40

    uh, the generic energy advice that many

  99. 3:42

    many people would follow. And I think

  100. 3:44

    this works really well

  101. 3:47

    except now

  102. 3:50

    I don't know if this is good advice. It

  103. 3:52

    has been across all these major

  104. 3:54

    disruptive changes over time. Unclear.

  105. 3:56

    In fact, I don't think it's good advice

  106. 3:58

    right now because there's a funny thing

  107. 4:00

    happening right now which that didn't

  108. 4:02

    happen in those previous trends which is

  109. 4:03

    that the rate of change is dramatically

  110. 4:05

    higher. Um I and you might say look

  111. 4:08

    technology always is changing like you

  112. 4:10

    know there's other trends things change

  113. 4:11

    a lot but not that much um the internet

  114. 4:15

    is still based on HTTP the uh uh mobile

  115. 4:18

    devices are still um iOS and Android

  116. 4:20

    based and so on and so but nowadays um

  117. 4:23

    other than the fact that like uh

  118. 4:24

    generative AI exists most things that

  119. 4:26

    power it are changing and changing

  120. 4:28

    dramatically.

  121. 4:30

    So last year I was here at this uh at

  122. 4:33

    the AI engineering world fair and I gave

  123. 4:34

    a speech and I said uh after spending a

  124. 4:38

    lot of time on this and thinking through

  125. 4:39

    this I think there's a key to this which

  126. 4:42

    is a gentic uh uh graph-based approach.

  127. 4:45

    The idea was um uh you have a large

  128. 4:48

    language model and these nodes and then

  129. 4:50

    you sort of put them together and you

  130. 4:51

    have the sort of the AI traverse this

  131. 4:53

    graph that you set up you build the

  132. 4:54

    graph. This is the key approach that and

  133. 4:57

    if you use this this is going to really

  134. 4:59

    help you sort of build agents because

  135. 5:01

    what is anything that we do in life it's

  136. 5:03

    a agent it's a workflow um uh it's a

  137. 5:06

    it's a way and then if you have an

  138. 5:08

    intelligent uh uh a agent it can

  139. 5:10

    basically traverse this is the key

  140. 5:12

    approach and I believe that at the time

  141. 5:14

    and a lot of people did and I still love

  142. 5:16

    this approach but nowadays it's sort of

  143. 5:20

    a little bit out of date in fact I

  144. 5:22

    remember um uh a guy came up to me after

  145. 5:24

    my speech last time and he was like the

  146. 5:26

    problem you talked about the the answer

  147. 5:29

    is just this exactly you were speaking

  148. 5:31

    to me thank you so much and and I was

  149. 5:32

    happy I I you know I gave a good speech

  150. 5:34

    and gave somebody some good advice um

  151. 5:36

    and then I remember when we made a

  152. 5:37

    change I was like I wonder what happened

  153. 5:39

    to that guy I wonder if he's here uh

  154. 5:40

    it's uh uh so um but the problem is is

  155. 5:44

    that not that it was wrong that that was

  156. 5:45

    the best approach but a new way emerged

  157. 5:49

    um in fact I started to like look

  158. 5:52

    through like all of the last year's uh

  159. 5:55

    events and actually go to other

  160. 5:56

    conferences like what what did people

  161. 5:57

    talk about a year ago and most of them

  162. 6:00

    were again nothing much wrong all good

  163. 6:02

    speeches all all good ideas but most of

  164. 6:05

    them have now a better way there um and

  165. 6:09

    uh so um and this is be sort of the gist

  166. 6:13

    of of the challenge so if you look at

  167. 6:16

    our journey of the technologies the kind

  168. 6:18

    of things that we care about um I'll

  169. 6:20

    just kind of rapid file here like so

  170. 6:22

    let's say that you want to utilize AI

  171. 6:23

    models and let's just look the last

  172. 6:24

    couple years a long a while ago probably

  173. 6:26

    distant memory now like people would say

  174. 6:28

    train your own my models or maybe fine

  175. 6:29

    tune them like nah that doesn't that's

  176. 6:31

    too why bother just use a frontier model

  177. 6:33

    use something from openi use something

  178. 6:34

    from anthropic use something from from

  179. 6:36

    Gemini um and then that's great but it's

  180. 6:39

    kind of expensive okay great let's just

  181. 6:40

    use openweight models they're pretty

  182. 6:41

    close you can use them you can host them

  183. 6:43

    yourself you can get some good GPUs um

  184. 6:45

    but then uh some companies will come to

  185. 6:47

    you and they'll be like look we just did

  186. 6:48

    this big deal with open orthropic like

  187. 6:50

    can we use our own key or bring our own

  188. 6:51

    model like sure you can do that too but

  189. 6:53

    then nowadays is probably the best

  190. 6:55

    approach is to do an adaptive model

  191. 6:56

    selection where you basically are

  192. 6:58

    picking the big and smaller models what

  193. 6:59

    which model does well and this is kind

  194. 7:01

    of the cool new thing maybe I could give

  195. 7:03

    a talk on that um or let's say you're

  196. 7:05

    building agents like we lot lot of

  197. 7:07

    things here like um I mean the word

  198. 7:09

    agent hasn't really been around for that

  199. 7:10

    long but in that time it used to be like

  200. 7:12

    a singleshot uh LLM response call that

  201. 7:15

    an agent if you feel like it then you

  202. 7:16

    have to say no okay we're chain of

  203. 7:18

    thought reasoning now we're going to

  204. 7:19

    make a graph-based agent system like I

  205. 7:21

    presented last year uh no then it turns

  206. 7:23

    that why are you bothering to make

  207. 7:24

    graphs when you could actually have an

  208. 7:25

    agent just figure out what to do? Make a

  209. 7:26

    plan. That's the new approach. That's

  210. 7:28

    kind of the way that um Claude sort of

  211. 7:30

    uh laid the approach there. And you're

  212. 7:32

    like, okay. And then now it's like,

  213. 7:34

    well, you if you want to use dedicated

  214. 7:36

    sub agents, maybe, but then maybe why

  215. 7:37

    not just make a generic agent and have

  216. 7:39

    it recursively work and then give it

  217. 7:40

    skills. Skills are very generic. They're

  218. 7:42

    super helpful. Um and then maybe now

  219. 7:44

    it's maybe the idea is not just to do

  220. 7:46

    that, but to do it with a agent sandbox

  221. 7:48

    so the agent can write code and execute

  222. 7:49

    it because that's super useful because

  223. 7:51

    agents are great programmers. I'd have

  224. 7:52

    them sort of just live in their own

  225. 7:53

    computer. Um, and then arguably now

  226. 7:55

    that's the best approach or maybe even

  227. 7:57

    we're in the world now of like don't

  228. 7:59

    even bother with any of that. Just bring

  229. 8:00

    your own harness like like like let

  230. 8:02

    people select if they want to use one of

  231. 8:03

    these other systems and then you know

  232. 8:05

    not even just building agents but the

  233. 8:07

    technology around context retrieval

  234. 8:08

    things like um you know in the old world

  235. 8:10

    we were like BM25 and keyword search

  236. 8:12

    that's the way to do things but that's

  237. 8:13

    like distant memory. Uh obviously the

  238. 8:15

    future is is retrieve augmented

  239. 8:17

    generation embeddings approximate

  240. 8:19

    nearest neighbor that's how we're going

  241. 8:20

    to find data. Turns out that doesn't

  242. 8:22

    really scale well and it kind of almost

  243. 8:23

    mimics randomness as you keep going. So

  244. 8:24

    then maybe it's about graphs. It's

  245. 8:26

    difficult to get working well. It's

  246. 8:27

    probably not the best. Um so then it's

  247. 8:29

    about hybrid. You want a lexical and you

  248. 8:31

    want to do semantic search and rank fuse

  249. 8:33

    those together. Arguably not. Arguably

  250. 8:35

    agents are actually way better at

  251. 8:37

    finding data because they can find

  252. 8:39

    things and apply their intelligence to

  253. 8:40

    get to it. So each of these things I

  254. 8:42

    just mentioned is arguably the leading

  255. 8:44

    approach for that moment over time.

  256. 8:48

    If you asked me to give a speech right

  257. 8:49

    now on any one of these, I would pick

  258. 8:50

    the last. I'd pick the adapted models

  259. 8:53

    with dedicated RM style agent and

  260. 8:55

    agentic search powered by hybrid.

  261. 8:57

    But uh is this the end of this journey?

  262. 9:01

    This is not that long of that time here.

  263. 9:04

    And so um my guess is the stuff that

  264. 9:07

    you're learning today likely won't last

  265. 9:10

    that long. Not that it's not wrong, not

  266. 9:12

    that it is not the best answer right

  267. 9:13

    now, but probably something's going to

  268. 9:16

    change. The big thing that changed last

  269. 9:18

    year was in my mind Opus 40 to Opus 45.

  270. 9:23

    When you did that, suddenly you got to a

  271. 9:25

    model that could do instruction

  272. 9:26

    following and really high scale. This is

  273. 9:28

    kind of to me the beginning the epic of

  274. 9:30

    like the new agent models. Uh also uh

  275. 9:33

    hardware is getting better, faster,

  276. 9:35

    cheaper. Maybe we'll start to use more

  277. 9:36

    tokens. Like token usage is off the

  278. 9:37

    charts of course and is that good or

  279. 9:39

    bad? What's going to change there?

  280. 9:40

    Enterprises are adopting things

  281. 9:42

    differently whether or not a company has

  282. 9:44

    decided to go all in on one agent to

  283. 9:46

    rule them all sort of like claude or

  284. 9:48

    maybe codec style agent um or maybe they

  285. 9:50

    want to utilize uh agents from different

  286. 9:52

    platforms and different systems or both.

  287. 9:55

    This is going to affect your lives um in

  288. 9:56

    addition to things like just the new

  289. 9:58

    techniques new interesting uh approaches

  290. 10:00

    new technology to power these things. So

  291. 10:03

    the fact that everybody in is working so

  292. 10:06

    hard on this trillions of dollars

  293. 10:07

    investment is actually leading to a lot

  294. 10:09

    of this change and again it's happening

  295. 10:10

    way faster than than I've ever seen for

  296. 10:13

    sure.

  297. 10:15

    Um, now if you look back, um, it's not

  298. 10:18

    this way with everything else. Like if

  299. 10:20

    you go see some of these other

  300. 10:21

    discussions, like I've given a speech on

  301. 10:23

    some of these topics. I looked at them

  302. 10:24

    come some of a few years old. They're

  303. 10:26

    pretty good. I still think they're very

  304. 10:27

    relevant. You want to talk about large

  305. 10:28

    scale databases about uh identity access

  306. 10:31

    controls, how to scale engineering

  307. 10:32

    teams, how to do multi cloud storage,

  308. 10:35

    probably um these are still relevant

  309. 10:37

    things today. These do not change as

  310. 10:39

    fast despite being high-scale uh

  311. 10:41

    interesting powerful uh technologies.

  312. 10:45

    So the previous wisdom of saying

  313. 10:47

    optimize for specific technologies

  314. 10:50

    go deep switch rarely right this what

  315. 10:52

    this the reason you do that is because

  316. 10:54

    switching is hard migrations suck

  317. 10:56

    whenever you migrate you break something

  318. 10:58

    every time no matter what um it's always

  319. 11:00

    harder than you think even [music] if

  320. 11:01

    you know that um and uh and the

  321. 11:03

    switching cost is basically high so

  322. 11:04

    basically don't do it for most things

  323. 11:06

    you're kind of uh just because

  324. 11:08

    something's better out there that's not

  325. 11:10

    the answer for most infrastructure so

  326. 11:12

    typically If you say half life of an

  327. 11:15

    agent infrastructure,

  328. 11:17

    3 to 5 years, reevali, see what's out

  329. 11:19

    there. We've been using databases like

  330. 11:21

    my SQL databases for a long time. It's

  331. 11:23

    still pretty good and probably need to

  332. 11:24

    replace it soon. But um but now with AI

  333. 11:28

    technologies, arguably the halflife is

  334. 11:31

    measured in months, meaning a few months

  335. 11:33

    after you've adopted what might be the

  336. 11:35

    best possible thing, there's a

  337. 11:37

    significant chance that you're going to

  338. 11:39

    have to replace it coming soon. And this

  339. 11:41

    is I think shocking.

  340. 11:44

    Maybe I see from some of your reactions

  341. 11:45

    that like you're kind of like have

  342. 11:47

    experienced this a little bit. Um but

  343. 11:48

    this is a different aspect of the way

  344. 11:51

    that you build technology.

  345. 11:53

    So if you're an engineer, this really

  346. 11:56

    sucks because the thing that you just

  347. 11:58

    learned and that you're making is now

  348. 12:00

    probably going to be out of date soon.

  349. 12:02

    Uh no engineer I know likes this. Um uh

  350. 12:05

    as a startup, you bet on something.

  351. 12:07

    You're like, we're going to go all in.

  352. 12:08

    We're going to go on the technology this

  353. 12:09

    approach and then we're going to

  354. 12:11

    basically uh uh disrupt somebody which

  355. 12:13

    probably will but then you see and see

  356. 12:15

    now like the first phase of AI companies

  357. 12:17

    are starting to get disrupted by the

  358. 12:18

    next phase. If you're a technology

  359. 12:21

    buyer, you're a leader of a company, you

  360. 12:22

    buy technology, you you you select uh

  361. 12:25

    open source models, you select vendors,

  362. 12:28

    there's a significant chance that

  363. 12:29

    whatever you just bought is not going to

  364. 12:31

    be the approach you're going to invest.

  365. 12:33

    That's you know, good luck doing a

  366. 12:35

    three-year deal like on on things about

  367. 12:37

    about this kind of stuff. Or if you're

  368. 12:38

    VC, uh maybe the coolest best thing that

  369. 12:41

    everybody agrees is the greatest

  370. 12:42

    opportunity is no longer going to be the

  371. 12:44

    opportunity soon um because everything's

  372. 12:47

    changing.

  373. 12:49

    So here's my advice. Get good at

  374. 12:51

    changing.

  375. 12:55

    It's almost silly to say because you

  376. 12:57

    know obviously technology changes.

  377. 12:58

    Obviously it's something that is um you

  378. 13:01

    know built in. Of course we're all going

  379. 13:02

    to change. We've done this for a long

  380. 13:03

    time. Um it's hard. I think it's really

  381. 13:06

    hard and the faster that you do it the

  382. 13:08

    harder it is. Uh when I was going

  383. 13:10

    through that uh like oh yeah we switched

  384. 13:12

    from the graph based agent to a um to

  385. 13:14

    the more looping style deep style agent.

  386. 13:16

    I remember very well the conversation

  387. 13:18

    with the engineer. He just he's like, "I

  388. 13:19

    did it. I got a tic search working and

  389. 13:21

    this approach does deep research. It

  390. 13:22

    does all this stuff just like you

  391. 13:23

    asked." Okay, we're going to switch

  392. 13:26

    rebuild it again in this new technology.

  393. 13:28

    And he's like, "Wait, what?" Like, "It's

  394. 13:30

    working. You did what you're talking."

  395. 13:32

    Yeah, but it's not as capable as we

  396. 13:33

    wanted it to be. Like, what do you mean?

  397. 13:34

    You didn't tell me that before. Like,

  398. 13:35

    and then and then so convince him like,

  399. 13:36

    "Okay, this is a new approach." And

  400. 13:38

    then, you know, he does it and it's

  401. 13:40

    good. Two months later, uh, we we're

  402. 13:42

    we're actually shipping the product uh

  403. 13:44

    on on Tuesday. And then I was like,

  404. 13:46

    "Okay, uh, guys, on Wednesday we're

  405. 13:48

    going to rebuild it again on the new

  406. 13:49

    approach." And they're like, "What are

  407. 13:50

    you talking about?" Like, like, um, then

  408. 13:53

    they'll say, like, it's it's almost hard

  409. 13:54

    on everybody like, "Wait, wait, give me

  410. 13:55

    more time. I'll I'll make the new way

  411. 13:56

    the old way do it better." Um, uh, like,

  412. 13:59

    and then also they're skeptical. Like,

  413. 14:01

    now you say that, but like this is going

  414. 14:03

    to change again, right? Like, who are

  415. 14:04

    you to like make these choices? And the

  416. 14:06

    answer is, yeah, I'm pretty sure it's

  417. 14:07

    going to change again. So, this is, I

  418. 14:10

    think, a leadership problem. It's a

  419. 14:11

    technology problem. It's a morale

  420. 14:13

    problem. It's a team problem. It's a

  421. 14:15

    company problem and if you're not

  422. 14:17

    careful, it is actually can destroy you.

  423. 14:19

    It can destroy a lot of things because

  424. 14:21

    people lose faith, they lose morale.

  425. 14:22

    It's a problem.

  426. 14:24

    So, um if my advice is change um and be

  427. 14:28

    ready for change, how are you going to

  428. 14:30

    do it? Three things to give you.

  429. 14:33

    One, um you just got to prepare people.

  430. 14:35

    Well, this is a kind of a people

  431. 14:37

    challenge. So when you build your teams,

  432. 14:39

    when you talk to them, when you prepare

  433. 14:40

    them, if they're in AI world, you got to

  434. 14:42

    tell them like expect change. It's

  435. 14:44

    normal. It's not a problem. It's not

  436. 14:47

    that you did something wrong. This is is

  437. 14:48

    weirdly like um like helps people like I

  438. 14:51

    have a a technology review team and and

  439. 14:53

    then and then they're like we can't like

  440. 14:54

    change. We don't know. We're not sure.

  441. 14:55

    We can't tell you that in two years from

  442. 14:57

    now this is going to be best. Like

  443. 14:58

    that's okay. Uh we're gonna we're gonna

  444. 15:00

    build these things that change. So just

  445. 15:02

    go with it. You have to pick something.

  446. 15:04

    Um, also whenever possible if you can

  447. 15:06

    build an abstraction so that it lets you

  448. 15:08

    swap out what's underneath. We have an

  449. 15:09

    agent extraction in box and you're able

  450. 15:10

    to go through and be like uh like select

  451. 15:13

    things underneath and the agent still

  452. 15:14

    works the same for the customers but it

  453. 15:16

    it's better underneath. Um, and the idea

  454. 15:19

    is that change is not a mistake and and

  455. 15:22

    I highlight like that's very hard for

  456. 15:24

    most people and and I and I would sort

  457. 15:26

    of just you just I tell them all the

  458. 15:27

    time change is not a mistake. You

  459. 15:29

    wouldn't nobody knew six months ago.

  460. 15:31

    Nobody today will know six months from

  461. 15:32

    now. It's Seems very true. So uh at Box

  462. 15:36

    we are now in the habit of reviewing

  463. 15:37

    every six months no matter what. This is

  464. 15:39

    great technology. We love it. Review in

  465. 15:41

    six months like because uh which is just

  466. 15:43

    completely crazy for everything else

  467. 15:45

    that we're doing. Everything else is

  468. 15:46

    like three years. Um also even though

  469. 15:50

    change is critical you um you need to

  470. 15:53

    define what you mean when change. If you

  471. 15:54

    just change all the time there's a new

  472. 15:56

    paper it's awesome. You know our CEO

  473. 15:59

    Aaron is very active on all the newest

  474. 16:01

    things. He's like check this out. Like

  475. 16:02

    don't change just because of that. Like

  476. 16:04

    don't change just because it's a trend.

  477. 16:05

    Change because you know it matters. And

  478. 16:08

    how do you know it matters? Probably

  479. 16:09

    pitch you on eval sets. If you're

  480. 16:11

    building agents, if you're building AI,

  481. 16:13

    make sure that you know what people

  482. 16:14

    have. You have the ability to give the

  483. 16:15

    same input, expect certain output. Grade

  484. 16:17

    that cost, speed, quality, capabilities.

  485. 16:19

    These are the things that you probably

  486. 16:21

    are going to to be wanting. So for us,

  487. 16:23

    it's easy. Does the new approach work

  488. 16:27

    better for our eval sets? What the

  489. 16:28

    customer cares about? If the answer is

  490. 16:30

    yes, strongly consider switching. If the

  491. 16:32

    answer is no, don't bother like or or

  492. 16:34

    keep working on a little bit of work to

  493. 16:35

    see if you can make sure that you you've

  494. 16:37

    fully explored it. Um and then so the

  495. 16:39

    idea is uh build a system that lets you

  496. 16:42

    be able to change. And then the third uh

  497. 16:45

    and final piece of advice here is um

  498. 16:49

    almost certainly none of us can keep up

  499. 16:51

    with everything. It is very hard. Um I

  500. 16:54

    think I heard uh Andre Kaparthy uh he he

  501. 16:56

    was like everything changes so fast I

  502. 16:58

    can't keep up. and you're like you're

  503. 17:00

    sort of quite famously good at keeping

  504. 17:01

    up and so like what's the hope for

  505. 17:03

    everybody else if if that's the case. Um

  506. 17:05

    and so but then so what you do is you

  507. 17:06

    rely on somebody else. You rely on a

  508. 17:08

    technology, you rely on a vendor, you

  509. 17:10

    rely on a platform. Um you when you

  510. 17:13

    select it and um and then here I think

  511. 17:16

    very use I mean like whenever you

  512. 17:18

    whenever anybody's bought technology in

  513. 17:19

    the past I would had advised them like

  514. 17:22

    look at what they do now. Double check

  515. 17:24

    the road map. Make sure it's good. Make

  516. 17:25

    sure it's on the path you want but just

  517. 17:27

    focus on what's available now. But I

  518. 17:29

    think something else here is um should

  519. 17:31

    do that of course that's most important

  520. 17:33

    thing but like look back how have they

  521. 17:36

    handled change what's their attitude

  522. 17:37

    towards change how can what can you when

  523. 17:39

    you talk to them when you read about

  524. 17:41

    their stuff like what happened six

  525. 17:43

    months ago what happened a year ago how

  526. 17:45

    did they handle that transition many of

  527. 17:47

    the vendors that I really like right now

  528. 17:49

    have reinvented themselves three times

  529. 17:50

    in the last year and I now trust that if

  530. 17:53

    something else comes along they're very

  531. 17:55

    good at this they understand agent

  532. 17:56

    technologies they understand the the

  533. 17:57

    eval sets they understand the the

  534. 17:59

    observability systems and then you can

  535. 18:00

    say ah okay good I hope that they keep

  536. 18:02

    up and then I now my sort of thing I

  537. 18:05

    need to do is just evaluate whether or

  538. 18:07

    not that's a good platform

  539. 18:09

    so um making sure that you have this

  540. 18:11

    sort of platforms that do well is is is

  541. 18:14

    critical um and um if anybody's

  542. 18:16

    interested in unstructured content and

  543. 18:18

    AI associated with it uh Box has a booth

  544. 18:20

    downstairs happy to talk to you about

  545. 18:22

    those kind of things

  546. 18:24

    um and then um I I'll leave you with

  547. 18:26

    this is um I actually I fully bet and I

  548. 18:29

    believe that um a company that's born

  549. 18:31

    this year was born last year um will or

  550. 18:34

    maybe even a company a medium-sized

  551. 18:36

    company or a big company will will they

  552. 18:38

    they'll shoot very high the company that

  553. 18:40

    will dominate tomorrow is is is now born

  554. 18:43

    today. Uh but I kind of bet you that the

  555. 18:47

    technology approach that they have right

  556. 18:48

    now is probably going to change multiple

  557. 18:50

    times before they do that. So

  558. 18:52

    interestingly it's like the challenge

  559. 18:54

    the advice the thought here is build for

  560. 18:57

    change

  561. 18:58

    adaptability arguably that's the moat

  562. 19:01

    that you have

  563. 19:03

    until that changes.

  564. 19:05

    Okay thank you everyone.

  565. 19:08

    [applause]