By the time a field starts naming everything aggressively, it is usually trying not to drown. Agent frameworks multiply. Tool protocols proliferate. New model releases reorder yesterday's leaderboard. Interfaces move from chat windows to canvases to copilots to swarms. Some of that noise is real progress. Some is marketing theater with a GPU budget.
Chapter 10 asks the calmer question: what actually endures? The answer is not a framework, a model family or an orchestration fashion. What endures is a pattern for turning machine capability into dependable work.
The pattern has a name
I call it constrained delegation. The machine gets a prepared environment, a clearer representation of intent, a workable slice of context, and a runtime that can preserve and expose state. It also gets authority boundaries proportionate to risk. Human review is focused where it matters most.
The chapter defines the pattern partly by what it excludes. It is not raw generation. It is not autonomous theater. It is not tool-sprawl disguised as capability, infinite context pretending to be memory, or a leaderboard screenshot standing in for product trust.
I also claim the pattern will outlast today's frameworks and likely today's interface assumptions. The reason matters. It is not a workaround for weak models. It is a design response to the nature of delegated work itself.
Why interfaces are the wrong place to look
The visible part of a system is easy to confuse with the stable part. A chat interface, a coding pane or a voice loop shapes behavior, but it is rarely the deepest source of reliability. A coding agent does not become trustworthy because its diff view looks polished. A realtime voice system does not become trustworthy because its speech sounds natural. Each time, the deeper question is the same: what has to be true around the model for delegated work to deserve trust?
Omar Khattab offers a useful piece of evidence in the chapter. Describing systems he built across years of model turnover, DSPy among them, he noted that they "fundamentally stayed the same over the years," from text-davinci-002 up to o4-mini, even as the models underneath were swapped out entirely. The model turned over. The structure stayed.
That is the practical meaning of durable. When you choose where to invest, ask which part of your system survives a model swap. Prepared repositories, specs, validations, memory, permissions and review surfaces tend to survive. Prompt cleverness tends not to.
The chapter also warns against reading this as pessimism about autonomy. The most useful systems in the book were rarely the ones with the least human involvement. They were the ones with the clearest handoffs. Autonomy is a variable to tune, not a trophy.
So here is the test I would apply to your next AI project. Take the proposal and strip out every model name and product name. If a plan still stands, with a prepared environment, explicit intent, bounded authority and focused review, you have something that can endure. If nothing remains, you have a dependency on a moment.
This post draws on Chapter 10 of From Copilot to Colleague.