Agent infrastructure changes on a timescale of months, so the usual advice to choose a stack and switch rarely no longer fits AI systems.
2
Teams need to expect change, use abstractions that allow components to be replaced, and review AI technologies on a six-month cycle.
3
Switch technologies when evaluation sets show better customer outcomes, rather than reacting to new papers, trends, or vendor announcements.
Summary
Ben Kus argues that infrastructure advice built around long-lived systems does not fit AI agents. Databases, identity controls, storage, and engineering practices can remain useful for years, while models, agent patterns, harnesses, and retrieval methods can change within months. He illustrates this through a series of shifts, from custom and fine-tuned models to frontier models, open-weight models, adaptive model selection, and new agent designs. Kus also describes asking an engineer to rebuild working agentic search, then asking for another rebuild immediately after shipping. That pace can damage morale and trust if leaders treat each change as a mistake. His response is organizational and technical: prepare teams for ongoing change, create abstractions that allow the underlying system to be swapped, and use evaluation sets to decide whether a new approach is worth adopting. Box reviews AI technology every six months. Kus also advises evaluating vendors by how they handled previous changes, not only by their current roadmap.
The standard infrastructure advice breaks when the rate of change is measured in months
Kus describes the usual advice for enterprise engineering: build a scalable and reliable platform, get good at a chosen stack, then optimize it over time. That works when technologies have long lives and migrations are expensive. Internet systems still use HTTP, and mobile platforms still rely on iOS and Android. AI infrastructure is different because almost every layer is changing quickly. Kus says the half life of ordinary infrastructure is around three to five years, while the half life of AI infrastructure can be measured in months. A system that is the best available choice today may need replacement soon.
Last year's graph-based agent advice was reasonable, but a new approach replaced it
At the previous AI Engineer World Fair, Kus recommended graph-based agents. The design connected language-model calls as nodes and let the agent traverse a graph built by the developer. He still liked that approach, and he says it was not wrong when he presented it. A person later told him that the advice was exactly what they needed, which made Kus wonder what happened after the approach became outdated. His broader review of conference talks led to the same conclusion: most of the ideas were sound, but a better method had appeared within a year. The problem is the speed of replacement, not that earlier engineers made foolish choices.
Model selection has moved from owning the model to adapting across models
Kus traces a series of model choices that have appeared in quick succession. Teams first considered training or fine-tuning their own models, then moved toward frontier models from OpenAI, Anthropic, or Gemini. Cost pushed some teams toward open-weight models that they could host with their own GPUs. Enterprise customers also asked to bring their own keys or models. Kus says adaptive model selection is now a strong approach, with larger and smaller models chosen according to which one performs the task well. He presents this as another example of a recommendation that can become outdated soon after teams adopt it.
Agent design has moved from single calls and graphs toward flexible harnesses
Kus says the meaning of an agent has changed repeatedly. It began as a single language-model response, then moved through chain-of-thought reasoning and graph-based systems. The next approach let an agent make its own plan instead of following a graph specified in advance. Later designs added dedicated subagents, recursive general agents, and reusable skills. Sandboxes let agents write and execute code in their own computer. Kus then describes a further option, bringing an existing harness rather than building every part of the agent stack. The sequence makes his point directly: even the current preferred design may be replaced by another way to give an agent tools, context, and control.
Retrieval has moved through keywords, embeddings, graphs, hybrid search, and agents
Kus gives retrieval the same treatment. Earlier systems used BM25 and keyword search. Teams then adopted retrieval-augmented generation with embeddings and approximate nearest-neighbor search. He says that approach does not scale well in some settings and can begin to resemble randomness as the process continues. Graphs were another option, but they are difficult to make work well. Hybrid retrieval combined lexical and semantic search and fused their rankings. Kus then says agents may be better at finding data because they can search and apply reasoning along the way. He names agentic search powered by hybrid retrieval as his current choice, while asking whether it will remain the best approach.
Some enterprise systems change slowly, so they should not be treated like agent infrastructure
Kus separates fast-moving AI systems from infrastructure that still rewards deep specialization and infrequent migrations. He says talks about large-scale databases, identity and access controls, engineering-team scaling, and multi-cloud storage remain useful even when they are several years old. These systems can be expensive and difficult to replace, and every migration tends to break something. For those areas, choosing a technology, learning it deeply, and switching rarely remains sensible. Kus's warning applies to teams that use the same migration habits everywhere. The half life of an AI agent system is different from the half life of a database or an access-control system.
Rapid change hurts engineers, buyers, startups, and investors in different ways
A months-long half life creates problems for everyone involved in an AI system. Engineers may spend time learning and building a system that soon becomes outdated. Startups can commit to one approach just as the next generation begins disrupting it. Technology buyers may sign a long vendor agreement for a method they will not want to use for long. Venture investors can back what looks like the strongest opportunity just before the market moves elsewhere. Kus is direct about the human cost. People lose faith and morale when their work is repeatedly discarded, so adapting to change is a leadership and team problem as well as a technology problem.
Teams need permission to change, replaceable layers, and evaluation-based decisions
Kus describes asking an engineer to rebuild working agentic search in a new style, then asking for another rebuild the day after shipping. The engineer reasonably questioned why working software had to be replaced again. Kus says leaders must tell AI teams that change is normal and does not mean they made a mistake. Box also uses an agent abstraction that lets the underlying components be swapped while the customer experience stays the same. The decision to switch should come from evaluation sets. Teams should give the system the same inputs, check expected outputs, and compare cost, speed, quality, and capabilities. A new approach should win on the customer-relevant evaluations before the team changes.
Vendor history is evidence of whether a platform can keep up
Kus says buyers should still inspect what a vendor offers today and check its roadmap. With AI infrastructure, they should also examine how the vendor handled earlier changes. Some vendors he trusts have reinvented themselves three times in a year. That history gives him more confidence that they can respond when another approach appears. He wants vendors to understand agent technologies, evaluation sets, and observability systems, rather than simply promoting a current product. The buyer still has to assess whether the platform is good, but the vendor's ability to adapt becomes part of that assessment.
"Build for change adaptability arguably that's the moat that you have until that changes."18:43
Who should watch
You lead an enterprise AI team and need to decide how much effort to put into systems that may be replaced within months.
You are building an agent or retrieval system and want a practical rule for when a new model or architecture justifies migration.
You buy AI platforms or vendors and need to judge their record of adapting, not only their current features and roadmap.
