What the term means ## Capability overhang Capability overhang is the gap between what frontier AI models can already do and what products, protocols, and organizations have actually absorbed. When a new model ships with abilities that no one has wired into real workflows yet, those capabilities sit unused — overhanging the current product surface — until infrastructure, interfaces, and integration work catch up. In this channel's material, the term belongs to the same conversation as the agentic web: Microsoft CTO Kevin Scott argues the interesting frontier is no longer scaling laws but what happens when models' existing capabilities get connected to the tools and data of the internet. [moment: 327][^385ed583-4107-5c5a-b47a-33e1dde27a3b@327] How the channel uses it ## How the term is used here The overhang shows up concretely across the channel's interviews: - Models can act, but the plumbing is missing. Scott frames usefulness as agents that take action on your behalf — using tools and reaching APIs — which requires an ecosystem where existing sites and APIs are plumbed through for agents, not capabilities the models lack. [moment: 268][^eea0a522-b6b8-5472-bf62-08b0a42ab8a3@268] - Protocols close the gap. MCP as the HTTP of the agentic web and NLWeb as its HTML are presented as the infrastructure needed to turn latent model capability into reachable, composable action. [moment: 326][^eea0a522-b6b8-5472-bf62-08b0a42ab8a3@326] - Product design, not model quality, is the bottleneck in much of this material: MCP servers need real product management, evals, and careful context-budget design before models' abilities translate into production agents. Use the term the way this channel does: as an explanation for why capability and deployment move on different clocks. - Capability overhang = model capabilities that already exist but have not yet been exposed by products, protocols, or infrastructure. - The channel connects it to the agentic web: closing the overhang means building protocols like MCP and NLWeb, not training smarter models. - It explains why the hard work is product and infrastructure design — context budgets, evals, sandboxes — rather than raw model improvement.