Open Reader

The Half Life of Agent Infrastructure — Ben Kus, Box

completed 19:26 Aug 29, 2026 Watch on YouTube

Current Status

completed

Video ID

sM1iYgz93HI

RAG / Chat

Enabled
The Half Life of Agent Infrastructure — Ben Kus, Box
Description

Ben Kus stood on this same stage last year and recommended a graph based approach to building agents. Someone found him afterward to say it was exactly the answer he needed. Kus opens this talk by retracting it, and admits he has since wondered what became of that person. Nothing about the advice was wrong when he gave it. A better way simply arrived, as it did for most of what was presented at that conference. He runs the same exercise across models, agent design and retrieval, and each chain lands somewhere unrecognizable from where it started twelve months earlier. The number that reframes it: infrastructure normally has a half life of three to five years, which is why the standard advice is to pick a stack, go deep and switch rarely, since every migration breaks something. Agent infrastructure has a half life measured in months. That breaks the usual advice, and it lands hardest on people. He tells it against himself, having asked an engineer to rebuild working agentic search in a new style, then proposed rebuilding it again the day after shipping. His answer is not a technology, it is preparation. Tell teams that change is normal rather than a failure, build abstractions that let the layer underneath be swapped, and only switch when eval sets say it matters, not when a paper is exciting. Box now reviews every AI technology on a six month clock. Speaker info: - https://x.com/benatbox - https://www.linkedin.com/in/benkus/ Timestamps: 0:00 - An exabyte, and now a trillion tokens 2:27 - The advice that used to work 4:48 - Retracting last year's talk from this stage 5:57 - How the model choices kept moving 7:07 - Agent design, from single calls to harnesses 8:15 - Retrieval, from keywords back to agents 10:31 - What does not change this fast 11:37 - Who a months long half life hurts 13:49 - Rebuilding it the day after shipping 14:57 - Telling teams that change is not a mistake 16:04 - Changing on evals, not on trends 17:13 - Judging vendors by how they handled ch

Summary

Generated by gpt-5.6-terra

At-a-Glance

  • Verdict: Watch fully
  • Core thesis: Agent infrastructure has a half-life of months rather than the multi-year lifecycle of conventional infrastructure, so the durable advantage is an organization and architecture designed to repeatedly swap approaches without breaking customer experience or team morale.
  • Why it matters: For teams building agent systems, model routing, retrieval, orchestration, and vendor integrations, the cost of committing deeply to today's best pattern may exceed the cost of designing for continuous, evidence-based replacement.
  • Best use: Use this as an operating-model and architecture briefing: adopt its six-month review cadence, abstraction principle, eval-gated migration logic, and vendor-selection criteria rather than treating any named agent pattern as a stable prescription.

Executive Summary

Box CTO Ben Kus argues that conventional enterprise infrastructure rewards deep specialization and infrequent migration because switching is expensive and risky. That logic still applies to durable layers such as databases, identity/access control, storage, and engineering management. It does not, in his view, apply cleanly to the rapidly shifting AI-agent stack.

His central observation is that the leading implementation pattern for AI changes within months: teams have moved from training or fine-tuning models, to frontier APIs, open-weight models, bring-your-own-model options, and adaptive model selection; similarly, agent designs have progressed from single calls and graph workflows toward planning/looping agents, reusable skills, code-executing sandboxes, and bring-your-own harnesses. He does not claim earlier approaches were wrong—only that newer approaches can become materially more capable quickly.

The practical answer is not perpetual trend-chasing. Kus recommends preparing teams to expect rework, placing unstable components behind abstractions, conducting formal six-month technology reviews, and using evaluation suites to decide whether a replacement actually improves customer-relevant quality, cost, latency, and capability. Box reportedly uses an agent abstraction so underlying systems can change while the customer-facing agent experience remains stable.

The leadership argument is as important as the technical one: repeated rebuilds damage morale if teams believe change means their prior work was a failure. Leaders must normalize that no one can reliably predict the optimal stack six months ahead. When buying platforms, Kus advises evaluating not only current features and roadmap but also a vendor's demonstrated ability to reinvent itself through prior technology shifts.

Key Takeaways

  • Claim: AI-agent infrastructure should be treated as a rapidly decaying layer, with an expected useful design life measured in months rather than the three-to-five-year cycle typical of conventional infrastructure. | Evidence: Kus contrasts long-lived MySQL-style database investments and stable enterprise domains such as identity, storage, and multi-cloud systems with agent technologies that may need replacement only a few months after adoption. | Implication: Separate stable platform foundations from volatile agent, model, retrieval, and orchestration layers, and avoid contracts, designs, or organizational commitments that assume the latter will remain optimal for years. | Caveat: He explicitly limits this argument to fast-moving AI layers; he does not recommend frequent migrations merely because an alternative exists for conventional infrastructure.
  • Claim: There is no settled 'best' agent architecture; the apparent frontier has repeatedly moved from fixed workflows toward more autonomous, tool-using systems. | Evidence: Kus describes a progression from single-shot LLM calls to chain-of-thought and graph-based agents, then planning/looping agents associated with Claude-style approaches, generic recursive agents with skills, code-executing agent sandboxes, and potentially user-selected harnesses. | Implication: Treat graph orchestration, sub-agent specialization, skills, sandboxed code execution, and harness choice as replaceable policies behind interfaces—not as irreversible product architecture. | Caveat: The speaker's preferred current stack is explicitly provisional; he says today's best answer will likely change again rather than presenting a universal reference architecture.
  • Claim: Model strategy is evolving from selecting one provider or model class to adaptive model selection across large and small models. | Evidence: The talk traces a sequence from self-training/fine-tuning, to frontier models from OpenAI, Anthropic, and Gemini, to self-hosted open-weight models and bring-your-own-key/model requests, before identifying adaptive selection as the current leading approach. | Implication: Build a model-control layer that can route tasks by quality, cost, latency, customer policy, and available credentials instead of hardwiring workflows to one model vendor. | Caveat: Kus offers this as an illustrative evolution rather than performance data demonstrating that adaptive routing wins in every workload.
  • Claim: Retrieval architecture is also unstable: embedding-based RAG and graph approaches should not be treated as permanent answers, and agents may increasingly perform the search process itself. | Evidence: Kus contrasts legacy BM25/keyword search, embedding plus approximate-nearest-neighbor RAG, graph retrieval, and hybrid lexical-semantic ranking; he argues that agents can often find information better by iteratively searching and applying reasoning. | Implication: Evaluate retrieval systems on end-task success rather than retrieval-fashion compliance, while retaining composable lexical, semantic, hybrid, and agentic-search options. | Caveat: He notes that graphs are difficult to make work well and says embedding retrieval can degrade at scale, but provides no benchmark or detailed definition of the scale and workloads involved.
  • Claim: Frequent technical change becomes destructive unless leaders explicitly normalize it as expected work rather than evidence of engineering failure. | Evidence: Kus recounts asking Box engineers to rebuild an agentic-search implementation after it was working, then proposing another rebuild immediately after a Tuesday product shipment because a newer approach was more capable; he identifies the resulting skepticism and morale loss as a leadership and company risk. | Implication: Set expectations during team formation and planning that AI implementation work has a short shelf life, reward migration readiness, and protect teams from interpreting invalidated approaches as wasted or failed work. | Caveat: Normalizing change does not justify arbitrary churn; Kus separately insists that changes must be supported by evaluation results.
  • Claim: The correct mechanism for deciding whether to switch is a customer-relevant evaluation suite, not novelty, executive enthusiasm, or new research papers. | Evidence: Box asks whether a new approach improves its eval sets and evaluates expected outputs against dimensions including cost, speed, quality, and capabilities; if it wins, Box strongly considers switching, and if not, it avoids switching or investigates further. | Implication: Before changing agent infrastructure, establish repeatable task suites and a migration gate with explicit quality, latency, cost, reliability, and safety thresholds tied to the user outcomes that matter. | Caveat: The talk does not specify Box's scoring methodology, thresholds, safety criteria, or how it handles regressions across different customer segments.
  • Claim: Vendor selection for AI infrastructure should reward demonstrated adaptability, not only present features and a promised roadmap. | Evidence: Kus says he now examines what a vendor did six and twelve months earlier and values vendors that have reinvented themselves three times in a year while demonstrating competence in agent systems, evaluations, and observability. | Implication: Add change-handling history to platform diligence: inspect prior migrations, compatibility practices, release velocity, observability/eval maturity, and whether the vendor helped customers transition rather than merely announcing new capabilities. | Caveat: Repeated reinvention can signal agility, but the talk does not address the counter-risk that frequent vendor pivots may create product instability, deprecations, or lock-in.

Detailed Brief

Box-scale context and the forces accelerating stack turnover

  • Claims: Kus frames the issue from an enterprise setting where AI must operate over very large volumes of unstructured content and large user populations.; He attributes the pace of turnover to simultaneous advances in model instruction-following, hardware cost/performance, token consumption, enterprise adoption preferences, and enormous industry investment.; He considers the jump from Anthropic Opus 4.0 to Opus 4.5 a meaningful inflection because stronger instruction-following enabled a new class of agent behavior at scale.
  • Evidence: Box operates at more than one exabyte of data, tens of millions of users, hundreds of billions of files/content objects, and roughly trillions of tokens, with an expectation of reaching 10 trillion tokens.; Enterprise customers may prefer one dominant agent platform, multiple agent ecosystems, or both; this choice can reshape the integrations a vendor must support.; Kus cites Andrej Karpathy's observation that even he cannot keep up with the rate of AI change.
  • Caveats: The scale statistics establish Box's operating context but do not prove that every smaller company needs the same architectural complexity or review cadence.; The Opus example is an informed practitioner judgment, not a comparative benchmark presented in the talk.
  • Implications: The need for portability increases with data scale, model-volume growth, and heterogeneous enterprise customer preferences.; Teams should distinguish between a platform strategy that is broadly durable and implementation choices that are likely to move with model capability jumps.

Concrete operating cadence for managed change

  • Claims: Box has adopted a mandatory six-month review cycle for AI technology even when the current solution is working well.; The desired customer experience is stability at the product boundary while the implementation beneath it improves.; Kus sees adaptability itself as the present competitive moat for companies likely to dominate later.
  • Evidence: He says Box's agent abstraction permits selecting or replacing underlying components while the customer-facing agent continues to behave as the same product.; He contrasts the six-month AI review with the roughly three-year review horizon it applies to much of Box's other infrastructure.; His closing prediction is that a company founded recently—or an incumbent—may rise dramatically, but will likely replace its current technical approach multiple times first.
  • Caveats: An abstraction only reduces migration cost if it preserves the necessary semantics, telemetry, controls, and performance characteristics across replacements; the talk does not detail how Box enforces those guarantees.
  • Implications: Treat abstraction boundaries, regression suites, and observability as strategic assets that convert infrastructure turnover from a product rewrite into a managed internal upgrade.; Use review cadences to create a deliberate portfolio of experiments rather than leaving technology replacement to ad hoc reactions.

Notable Concepts & Terms

  • Half-life of agent infrastructure: Kus's framing that the leading architecture for agents may become obsolete in months, unlike conventional enterprise infrastructure that can remain viable for years.
  • Adaptive model selection: Routing work among larger and smaller models based on which model best serves a task, rather than standardizing on a single frontier, open-weight, or customer-provided model.
  • Agentic graph-based approach: A prior favored pattern in which an LLM traverses a designed workflow graph; Kus uses it to illustrate how even sound approaches can be superseded.
  • RLM-style / looping agent: Kus's shorthand for a more iterative agent that plans and repeatedly works through a task, contrasted with pre-authored graph traversal.
  • Skills: Reusable capabilities supplied to a generic agent, enabling a less specialized architecture than dedicated sub-agents for every task.
  • Agent sandbox: An isolated execution environment in which an agent can write and run code, expanding what it can accomplish while containing execution.
  • Agentic search: A retrieval approach in which an agent iteratively locates and reasons over information, rather than relying only on fixed keyword, vector, graph, or hybrid retrieval pipelines.
  • Eval sets: Repeatable input-output tests used to decide whether an AI-system change improves customer-relevant quality, cost, speed, and capabilities.

Operator Notes / Why Ken Should Care

  • Create a volatile-layer inventory for the agent stack: model provider/routing, prompt and harness logic, retrieval, workflow/orchestration, tool interfaces, sandboxing, and observability. Identify where current implementations cannot be swapped without customer-facing breakage.
  • Institute a six-month agent-stack review with a written keep/replace decision, but require every proposed migration to clear predefined task-evaluation, cost, latency, reliability, and safety thresholds.
  • Prioritize a control-plane interface for model and harness selection so provider changes, customer BYO-key/BYO-model requirements, and routing policies do not force application rewrites.
  • In vendor diligence and renewal decisions, audit the vendor's prior-year transition record: release compatibility, migration tooling, deprecation behavior, evaluation support, and observability—not just its current demo and roadmap.
  • Set team expectations explicitly that AI-layer rewrites are planned adaptation work; allocate capacity for them and avoid measuring teams solely by permanence of implementation.

Source/Metadata

  • Title: The Half Life of Agent Infrastructure — Ben Kus, Box
  • Transcript words: 6193
  • Duration seconds: 1166
  • Timestamp note: No usable timestamps or chapter markers were present; the supplied transcript contains substantial duplicated passages and trailing extraction noise.

Transcript

3841 words en Processed in 125.5s

Ben Kuss Hi, everyone. I'm Ben Kuss. I'm CTO of Box. And today, I'm going to be talking about building for change, and specifically around AI agents and how to continue to adapt your infrastructure as we are all in the middle of this journey. So, before I get too far, I will quickly set a little bit of who I am and what I do. For Box, I'm CTO, and one of my jobs, and my job for my whole career, has been to build enterprise software. And so, if today you're from a consumer company or you're not involved in enterprise, I hope that a lot of it is still relevant, but in many cases, a lot of the lessons I've learned are enterprise-specific. So, I will highlight, when I'm thinking and talking about infrastructure, when I'm talking about the challenges that we face, I'm typically talking about things that are in a scale of, for Box, we have over an exabyte of data. So, not a gigabyte, not a terabyte, not a petabyte, but an exabyte. And then oftentimes, I'm thinking in the tens of millions of users, hundreds of billions of things, in our case files or content or unstructured content. And then the new stat that is the one that we talk about is tokens. So, we are now in the ballpark of trillion tokens, probably will be 10 trillion tokens sometime soon. And this, of course, is some of the new and interesting challenges that this kind of scale brings. So, in my career, and I think maybe many of us here, we've lived through these technology changes. And so, taking a quick step back, I started my career when the internet was becoming a thing, lived through mobile and this idea of carrying these different devices, moved to the cloud where you could store and maintain all your data. And then, of course, we're all in the middle of this AI change. And I think when you see these technology disruptions, when you're thinking about this idea of all of these have changed all of our lives, and you're thinking about it from the perspective of a technology leader or a startup or engineer, you see that these are where major companies are born. You see that big companies adapt or die. Small companies are here to disrupt things. They're here to take bets. They're here to grow. I've had two startups. I've been acquired twice, once at IBM, once at Box. And so we're in the middle of this major opportunity. But for a long time, no matter what you come from and what area you're at, I typically, if you were to ask my advice about what makes you successful as a company, as an engineering organization, as a technology startup, or as a company who has a technology division, I would say, no matter what, there are three things. The first is you need to build scalable, reliable platforms and select the technology that you care about, meaning that there are a lot of ways to do things, but get good at something. Get good at that technology, that system, at that stack, and then keep going with that. And then you leverage this technology so that you do more for your customers. You build your better product. You develop the capabilities. And then you optimize it. Make it better. Make it faster. Make it cheaper. Make it more capable. And this was the generic enterprise advice, the generic engineering advice that many, many people would follow. And I think this works really well, except now. I don't know if this is good advice. It has been across all these major disruptive changes over time. Unclear. In fact, I don't think it's good advice right now. Because there's a funny thing happening right now, which didn't happen in those previous trends, which is that the rate of change is dramatically higher. And you might say, look, technology always is changing. In those other trends, things changed a lot, but not that much. The internet is still based on HTTP. The mobile devices are still iOS and Android-based, and so on. But nowadays, other than the fact that generative AI exists, most things that power it are changing and changing dramatically. So last year, I was here at the AI Engineering World Fair, and I gave a speech, and I said, after spending a lot of time on this and thinking through this, I think there's a key to this, which is an agentic graph-based approach. The idea was you have a large language model and these nodes, and then you put them together, and you have the AI traverse this graph that you set up, you build the graph. This is the key approach, that if you use this, this is going to really help you build agents. Because what is anything that we do in life? It's agentic. It's a workflow. It's a way for, and then if you have an intelligent agent, it can basically traverse this. This is the key approach. And I believed that at the time, and a lot of people did. And I still love this approach. But nowadays, it's a little bit out of date. In fact, I remember a guy came up to me after my speech last time, and he was like, the prompt you talked about, the answer is just this exactly, you're speaking to me, thank you so much. And I was happy. I gave a good speech and gave somebody some good advice. And then I remember when we made a change, it was like, I wonder what happened to that guy? I wonder if he's here. But the problem is not that it was wrong, that that was the best approach, but a new way emerged. In fact, I started to look through all of last year's events and actually go to other conferences, like what did people talk about a year ago? And most of them were, again, nothing was wrong, all good speeches, all good ideas, but most of them have now a better way. And this is the gist of the challenge. So if you look at our journey of the technologies, the kind of things that we care about, I'll just rapid-fire here. Let's say that you want to utilize AI models. And let's just look at the last couple years. A while ago, probably a distant memory now, people would say, train your own models or maybe fine-tune them. And you're like, nah, that doesn't, that's too, why bother? Just use a frontier model, use something from OpenAI, use something from Anthropic, use something from Gemini. And then that's great, but it's kind of expensive. Okay, great. Let's just use open-weight models. They're pretty close. You can use them, you can host them yourself, you can get some good GPUs. But then some companies will come to you, and they'll be like, look, we just did this big deal with OpenAI or Anthropic, can we use our own key or bring our own model? Sure, we can do that too. But then nowadays, probably the best approach is to do adaptive model selection, where you basically are picking the big and smaller models, which model does well. And this is the cool new thing. Maybe I could give a talk on that. Or let's say you're building agents. We bought a lot of things here. The word agent hasn't really been around for that long. But in that time, it used to be a single-shot LLM response, call that an agent if you feel like it. Then you have to say, no, okay, we're going to use chain-of-thought reasoning. Now we're going to make a graph-based agent system, like I presented last year. No, but then it turns out, why are you bothering to make graphs when you could actually have an agent just figure out what to do, make a plan? That's the new approach. That's the way that Claude laid the approach there. And then you're like, okay. And then now it's like, well, if you want to use dedicated sub-agents, maybe, but then maybe why not just make a generic agent and have it recursively work and then give it skills? Skills are very generic. They're super helpful. And then maybe now the idea is not just to do that, but to do it with an agent sandbox, so the agent can write code and execute it, because that's super useful, because agents are great programmers, and might have them just live in their own computer. And then arguably now, that's the best approach. Or maybe even we're in the world now of don't even bother with any of that. Just bring your own harness. Let people select if they want to use one of these other systems. And then not even just building agents, but the technology around context retrieval, things like, in the old world, we were like BM25 and keyword church. you if you want to use dedicated sub agents, maybe, but then maybe why not just make a generic agent and have it recursively work and then give it skills. Skills are very generic. They're super helpful. And then maybe now the idea is not just to do that, but to do it with agent sandbox. So the agent can write code and execute it because that's super useful because agents are great programmers and might have them just live in their own computer. And then, arguably now, that's the best approach. Or maybe even we're in the world now of, don't even bother with any of that. Just bring your own harness. Let people select if they want to use one of these other systems. And then, not even just building agents, but the technology around context retrieval, things like, in the old world, we were BM25 and keyword church. That's the way to do things. But that's distant memory. Obviously, the future is retrieval, augmented generation, embeddings, approximate nearest neighbor. That's how we're going to find data. Turns out that doesn't really scale well, and it almost mimics randomness as you keep going. So then maybe it's about graphs. It's difficult to get working well. It's probably not the best. So then it's about hybrid. You want a lexical and you want to do a semantic search and rank, fuse those together. Arguably not. Arguably, agents are actually way better at finding data because they can find things and apply their intelligence to get to it. So each of these things I just mentioned is arguably the leading approach for that moment over time. If you ask me to give a speech right now on any one of these, I would pick the last, I'd pick the adaptive models with dedicated RLM style agent and agentic search powered by hybrid. But is this the end of this journey? This is not that long of a time here. And so my guess is the stuff that you're learning today likely won't last that long. Not that it's not wrong. Not that it is not the best answer right now. But probably something's going to change. The big thing that changed last year was, in my mind, Opus 4.0 to Opus 4.5. When you did that, suddenly you got to a model that could do instruction following in really high scale. This was, to me, the beginning, the epic of the new agent models. Also, hardware is getting better, faster, cheaper. Maybe we'll start to use more tokens. Token usage is off the charts, of course. And is that good or bad? What's going to change there? Enterprises are adopting things differently. Whether or not a company has decided to go all in on one agent to rule them all, like Claude or maybe Codex style agent. Or maybe they want to utilize agents from different platforms and different systems, or both. This is going to affect your lives, in addition to things like just the new techniques, new interesting approaches, new technology to power these things. So the fact that everybody is working so hard on this, trillions of dollars investment, is actually leading to a lot of this change. And again, it's happening way faster than I've ever seen, for sure. Now, if you look back, it's not this way with everything else. If you go see some of these other discussions, I've given a speech on some of these topics. I looked at them, some of them a few years old. They're pretty good. I still think they're very relevant. You want to talk about large scale databases, identity access controls, how to scale engineering teams, how to do multi-cloud storage. Probably these are still relevant things today. These do not change as fast, despite being high scale, interesting, powerful technologies. So the previous wisdom of saying optimize for specific technologies, go deep, switch rarely. The reason you do that is because switching is hard. Migrations suck. Whenever you migrate, you break something every time, no matter what. It's always harder than you think, even if you know that. And the switching cost is high. So don't do it for most things. Just because something's better out there, that's not the answer for most infrastructure. So typically, if you say half-life of an agent infrastructure, of a normal infrastructure, three to five years. Revive it periodically. See what's out there. We've been using databases, MySQL databases, for a long time. It's still pretty good and probably doesn't need to be replaced soon. But now with AI technologies, arguably the half-life is measured in months, meaning a few months after you've adopted what might be the best possible thing, there's a significant chance that you're going to have to replace it soon. And this is, I think, shocking. Maybe I see from some of your reactions that you have experienced this a little bit. But this is a different aspect of the way that you build technology. So if you're an engineer, this really sucks. Because the thing that you just learned and that you're making is now probably going to be out of date soon. No engineer I know likes this. As a startup, you bet on something. You're like, we're going to go all in. We're going to go on this technology approach. And then we're going to disrupt somebody, which probably will. But then you see now the first phase of AI companies are starting to get disrupted by the next phase. If you're a technology buyer, you're a leader of a company, you buy technology, you select open source models, you select vendors, there's a significant chance that whatever you just bought is not going to be the approach. You're going to invest. Good luck doing a three-year deal on things about this kind of stuff. Or if you're a VC, maybe the coolest, best thing that everybody agrees is the greatest opportunity is no longer going to be the opportunity soon because everything's changing. So here's my advice. Get good at changing. It's almost silly to say because, obviously, technology changes. Obviously, it's something that is built in. Of course, we're all going to change. We've done this for a long time. It's hard. I think it's really hard. And the faster that you do it, the harder it is. When I was going through that, oh yeah, we switched from the graph based agent to the more looping style, deep style agent. I remember very well the conversation with the engineer. He's like, I did it. I got agentic search working in this approach. Just deep research. It does all the stuff, just like you asked. Okay. We're going to switch. Rebuild it again in this new technology. And he's like, wait, what? It's working. You did what you're talking about. Yeah, but it's not as capable as we want it to be. What do you mean? You didn't tell me that before. And then convince him, okay, this is a new approach. And then he does it. And it's good. Two months later, we're actually shipping the product on Tuesday. And then I was like, okay, guys, on Wednesday, we're going to rebuild it again on the new approach. And they're like, what are you talking about? Again, it's almost hard on everybody. Wait, give me more time. I'll make the new way, the old way do it better. And then also they're skeptical, now you say that, but who is going to change again, right? Who are you to make these choices? And the answer is, yeah, I'm pretty sure it's going to change again. So this is, I think, a leadership problem. It's a technology problem. It's a morale problem. It's a team problem. It's a company problem. And if you're not careful, it can destroy you. It can destroy a lot of things because people lose faith, they lose morale. It's a problem. So if my advice is change and be ready for change, how are you going to do it? Three things to give you. One, you just got to prepare people. This is a people challenge. So when you build your teams, when you talk to them, when you prepare them, if they're in AI world, you got to tell them, expect change. It's normal. It's not a problem. It's not that you did something wrong. This weirdly helps people. I have a technology review team. And then they're like, we can't change, we don't know. We're not sure. We can't tell you that in two years from now this is going to be best. That's okay. We're going to build these things to change. So just go with it. You have to pick something. Also, whenever possible, if you can build an abstraction so that it lets you swap out what's underneath. We have an Three things to give you. One, you just have to prepare people. This is a people challenge. So when you build your teams, when you talk to them, when you prepare them, if they're in the AI world, you have to tell them, expect change. It's normal. It's not a problem. It's not that you did something wrong. This weirdly helps people. I have a technology review team, and they're like, we can't change, we don't know. We're not sure. We can't tell you that in two years from now, this is going to be best. That's okay. We're going to build these things to change. So just go with it. You have to pick something. Also, whenever possible, if you can build an abstraction so that it lets you swap out what's underneath. We have an agent extraction in Box, and you're able to go through and select things underneath. And the agent still works the same for the customers, but it's better underneath. And the idea is that change is not a mistake. And I highlight that's very hard for most people. And I would just tell them all the time, change is not a mistake. Nobody knew six months ago. Nobody today will know six months from now. It seems very true. So at Box, we are now in the habit of reviewing every six months no matter what. This is great technology. We love it. Review in six months. Because that is completely crazy for everything else that we're doing. Everything else is three years. Also, even though change is critical, you need to define what you mean by change. If you just change all the time, there's new papers, awesome. Our CEO, Aaron, is very active on all the newest things. He's like, check this out. Don't change just because of that. Don't change just because it's a trend. Change because you know it matters. And how do you know it matters? Probably put it on eval sets. If you're building agents, if you're building AI, make sure that you know what people have. You have the ability to give the same input, expect certain output, grade that. Cost, speed, quality, capabilities. These are the things that you probably are going to want. So for us, it's easy. Does the new approach work better for our eval sets, what the customer cares about? If the answer is yes, let's strongly consider switching. If the answer is no, don't bother, or keep working on it a little bit to make sure that you've fully explored it. And then the idea is, build a system that lets you be able to change. And then the third and final piece of advice here is almost certainly none of us can keep up with everything. It is very hard. I think I heard Andre Kaparthi, he was like, everything changes so fast, I can't keep up. And you're like, you're quite famously good at keeping up. What's the hope for everybody else if that's the case? And so what do you do? You rely on somebody else. You rely on a technology, you rely on a vendor, you rely on a platform when you select it. And then here, I think very useful, whenever anybody's bought technology in the past, I would have advised them, look at what they do now. Double-check the roadmap, make sure it's good, make sure it's on the path you want, but just focus on what's available now. But I think something else here is, you should do that, of course. That's the most important thing. But look back. How have they handled change? What's their attitude towards change? When you talk to them, when you read about their stuff, what happened six months ago? What happened a year ago? How did they handle that transition? Many of the vendors that I really like right now have reinvented themselves three times in the last year. And I now trust that if something else comes along, they're very good at this. They understand the agent technologies, they understand the eval sets, they understand the observability systems. And then you can say, okay, good. I hope that they keep up. And then now, the thing I need to do is just evaluate whether or not that's a good platform. So making sure that you have platforms that do well is critical. And if anybody's interested in unstructured content and AI associated with it, Box has a booth downstairs. Happy to talk to you about those things. And then I'll leave you with this. I actually fully bet and believe that a company that's born this year, was born last year, or maybe even a company, a medium-sized company or a big company, will shoot very high. The company that will dominate tomorrow is now born today. But I kind of bet you that the technology approach that they have right now is probably going to change multiple times before they do that. So interestingly, the challenge, the advice, the thought here is build for change. Adaptability, arguably, that's the moat that you have until that changes. Okay. Thank you, everyone. That's my 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 on some of these topics. I looked at them, some of them a few years old. They're pretty good. I still think they're very relevant. You want to talk about large scale databases, about identity access controls, how to scale engineering teams, how to do multi-cloud storage. Probably these are still relevant things today. These do not change as fast, despite being high scale, interesting, powerful technologies. So the previous wisdom of saying optimize for specific technologies, go deep, switch rarely. The reason you do that is because switching is hard. Migrations suck. Whenever you migrate, you break something every time, no matter what. It's always harder than you think, even if you know that. And the switching cost is basically high. So basically, don't do it for most things. You're kind of just because something's better out there. That's not the answer for most infrastructure. So typically, if you say half-life of an agent infrastructure, of a normal infrastructure, three to five years. Revive it periodically. See what's out there. We've been using databases, like MySQL databases for a long time. It's still pretty good and probably need to replace it soon. But now with AI technologies, arguably the half-life is measured in months, meaning a few months after you've adopted what might be the best possible thing, there's a significant chance that you're going to have to replace it coming soon. And this is, I think, shocking. Maybe I see from some of your reactions that you kind of have experienced this a little bit. But this is a different aspect of the way that you build technology. So if you're an engineer, this really sucks. Because the thing that you just learned and that you're making is now probably going to be out of date soon. No engineer I know likes this. As a startup, you bet on something. You're like, we're going to go all in. We're going to go on this technology approach. And then we're going to basically disrupt somebody, which probably will. But then you see now, like the first phase of AI companies are starting to get disrupted by the next phase. If you're a technology buyer, you're a leader of a company, you buy technology, you select open source models, you select vendors, there's a significant chance that whatever you just bought is not going to be the approach. You're going to invest, you know, good luck doing a three-year deal, like on things about this kind of stuff. Or if you're a VC, maybe the coolest, best thing that everybody agrees is the greatest opportunity is no longer going to be opportunity soon because everything's changing. So here's my advice. Get good at changing. It's almost silly to say because, you know, obviously technology changes. Obviously, it's something that is, you know, built in. Of course, we're all going to change. We've done this for a long time. It's hard. I think it's really hard. And the faster that you do it, the harder it is. When I was going through that, like, oh, yeah, we switched from the graph based agent to the more looping style, deep style agent. I remember very well the conversation with the engineer. He just, he's like, I did it. I got agentic search working in this approach. Just deep research. It does all stuff. Just like you asked. Okay. We're going to switch. Rebuild it again in this new technology. And he's like, wait, what? Like, it's working. You did what you're talking about. Yeah, but it's not as capable as we want it to be. Like, what do you mean? You didn't tell me that before. Like, and then, and then so convince him, like, okay, this is a new approach. And then, you know, he does it. And it's good. Two months later, we're actually shipping the product on Tuesday. And then I was like, okay, guys, on Wednesday, we're going to rebuild it again on the new approach. And they're like, what are you talking about? Like, like, again, they'll say, like, it's almost hard on everybody. Like, wait, wait, give me more time. I'll make the new way, the old way do it better. Like, and then also they're skeptical, like, now you say that, but like, who is going to change again, right? Like, who are you to like, make these choices? And the answer is, yeah, I'm pretty sure it's going to change again. So this is, I think, a leadership problem. It's a technology problem. It's a morale problem. It's a team problem. It's a company problem. And if you're not careful, it is actually can destroy you. It can destroy a lot of things because people lose faith, they lose morale. It's a problem. So if my advice is change and be ready for change, how are you going to do it? Three things to give you. One, you just got to prepare people. Well, this is a kind of a people challenge. So when you build your teams, when you talk to them, when you prepare them, if they're in AI world, you got to tell them, like, expect change. It's normal. It's not a problem. It's not that you did something wrong. This is weirdly like, like, helps people. Like, I have a technology review team. And then they're like, we can't, like, change, we don't know. We're not sure. We can't tell you that in two years from now, this is going to be best. Like, that's okay. We're going to build these things to change. So just go with it. You have to pick something. Also, whenever possible, if you can build an abstraction so that it lets you swap out what's underneath. We have an agent extraction in box, and you're able to go through and be, like, select things underneath. And the agent still works the same for the customers, but it's better underneath. And the idea is that change is not a mistake. And I highlight, like, that's very hard for most people. And I would sort of just tell them all the time. Change is not a mistake. You wouldn't, nobody knew six months ago. Nobody today will know six months from now. It seems very true. So at Box, we are now in the habit of reviewing every six months no matter what. This is great technology. We love it. Review in six months. Like, because, which is just completely crazy for everything else that we're doing. Everything else is like three years. Also, even though change is critical, you need to define what you mean when change. If you just change all the time. There's new papers. Awesome. You know, our CEO, Aaron, is very active on all the newest things. He's like, check this out. Like, don't change just because of that. Like, don't change just because it's a trend. Change because you know it matters. And how do you know it matters? Probably put you on eval sets. If you're building agents, if you're building AI, make sure that you know what people have. You have the ability to give the same input, expect certain output, grade that. Cost, speed, quality, capabilities. These are the things that you probably are going to be wanting. So for us, it's easy. Does the new approach work better for our eval sets? What the customer cares about? If the answer is yes, let's strongly consider switching. If the answer is no, don't bother. Like, or keep working on a little bit of work to see if you can make sure that you've fully explored it. And then so the idea is build a system that lets you be able to change. And then the third and final piece of advice here is almost certainly none of us can keep up with everything. It is very hard. I think I heard Andre Kaparthi, he was like, everything changes so fast, I can't keep up. And you're like, you're sort of quite famously good at keeping up. And so like, what's the hope for everybody else if that's the case? And so, but then so what do you do is you rely on somebody else. You rely on a technology, you rely on a vendor, you rely on a platform, when you select it. And then here, I think very useful, I mean, like whenever you, whenever anybody's bought technology in the past, I would have advised them like, look at what they do now. Double check the roadmap, make sure it's good, make sure it's on the path you want, but just focus on what's available now. But I think something else here is, should do that, of course. That's the most important thing. But like, look back, how have they handled change? What's their attitude towards change? How can you, when you talk to them, when you read about their stuff, like what happened six months ago? What happened a year ago? How did they handle that transition? Many of the vendors that I really like right now have reinvented themselves three times in the last year. And I now trust that if something else comes along, they're very good at this. They understand the agent of technologies, they understand the eval sets, they understand the observability systems. And then you can say, ah, okay, good. I hope that they keep up. And then I now, my sort of thing I need to do is just evaluate whether or not that's a good platform. So making sure that you have this sort of platforms that do well is critical. And if anybody's interested in unstructured content and AI associated with it, Box has a booth downstairs. Happy to talk to you about those kind of things. And then I'll leave you with this is I actually, I fully bet and I believe that a company that's born this year, was born last year, will, or maybe even a company, a medium-sized company or a big company will, they'll shoot very high. The company that will dominate tomorrow is is now born today. But I kind of bet you that the technology approach that they have right now is probably going to change multiple times before they do that. So interestingly, it's like the challenge, the advice, the thought here is build for change. Adaptability, arguably, that's the moat that you have until that changes. Okay. Thank you, everyone. That's my 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목 목