A listener writing in as Mr. Future put a question to the Moonshots panel: “Is it even possible for any lab to reach escape velocity from future competition, or will everyone keep running on the same foundation?”
Salim Ismail doubted that a lab could leave its competitors permanently behind on the strength of its model alone. Innovations diffuse, he said: papers get published and researchers move between organizations. In his account, the foundation model—the general-purpose AI on which applications are built—eventually becomes widely available infrastructure, “much like databases have done.”
The advantage moves elsewhere: to proprietary data, an organization's purpose, its knowledge of its own work and its ability to turn that knowledge into better systems. What matters most, Ismail argued, is who can “ship and measure and learn and retrain faster.”
“This is what Alex calls the inner loop,” he said, crediting his fellow panelist for the term as they use it in the discussion.
What the inner loop means
A moat, in business language, is an advantage a rival cannot easily copy. The inner-loop thesis asks which advantages survive when rivals can buy or download similarly capable AI models.
The loop is a repeating cycle. An organization deploys a system in real work, observes the results, identifies what needs to change and releases an improved version. Improvement might mean retraining the model, but it might also mean supplying better instructions, connecting the right records or changing when a task goes to a person. Organizational learning does not require the underlying model to update itself after every interaction.
Each useful turn adds knowledge about that particular workplace: which information matters, where a process breaks down and what a successful result looks like. The proposed advantage is not simply doing more experiments. It is turning experience into improvements faster than a competitor can.
Access to the same model does not automatically give a rival the records, workflow connections and lessons needed to use it equally well. Interchangeable models need not make an organization's accumulated knowledge interchangeable.
The case for it: learning the work
Earlier in the episode, a panelist connected the availability of open models to sovereign AI: countries developing systems they can adapt to national goals. He suggested that starting with an existing model could get a country running in roughly five or six months, and give large corporations a roadmap to competitive proprietary systems.
His argument came with a boundary. Borrowing other models' reasoning examples could help a newcomer catch up to the frontier, he said, without necessarily taking it beyond that frontier. The timeline was an estimate, not a reported deployment result. It supplied a premise for the inner-loop argument: if capable starting models become easier to obtain, more of the contest moves to what an organization does with them.
Another example made that work tangible. In a discussion of AI coworkers and workflow recording, the panel described a system that could watch someone perform a task on screen and turn it into a reusable skill. The ambition was to record workflows across a business and produce a digital version of how the company operates.
Recording a task would be the beginning of a loop, not its completion. The organization would need to find out whether the resulting automation worked, identify exceptions and use those lessons to improve the next attempt. The valuable knowledge would include not just the recorded steps, but when those steps were appropriate.
What successful deployments add to the argument
In a later Moonshots discussion, Alvin Graylin described a call with the chief executive of an AI-driven drug discovery company. She had told him that people underestimate how small the models used in that work can be: tens or hundreds of millions of parameters, sometimes a few billion. Parameters are the adjustable numbers a model learns during training. His broader argument was that useful business applications need not wait for the newest, largest model.
Research he coauthored with Elisa Pereira and economist Erik Brynjolfsson gives that argument a more concrete base. Their Enterprise AI Playbook examines 51 successful deployments across 41 organizations, seven countries and nine industries. Interviews ran from August 2025 to February 2026, supplemented by company documentation. Projects had to be in production, sustain adoption for at least three months and produce measurable value to qualify.
The researchers deliberately selected successes, and the evidence was primarily self-reported. Their results describe pathways to value, not the likelihood that an arbitrary AI project will succeed.
Organizational work accounted for 77% of the hardest challenges participants reported. Two other findings speak directly to the inner loop: 61% of the successful projects included a prior failure, and model choice was interchangeable in 42% of cases. Several models could do the job; making the deployment work required something beyond choosing one.
But model choice was a critical differentiator in 19% of cases. The findings support the importance of implementation without making the underlying technology irrelevant. Nor does a history of failed attempts establish that failure caused later success, or that the organizations that iterated fastest beat their competitors.
The study also connects the design of a workflow to its reported gains. Escalation-based oversight—letting a system handle tasks while passing exceptions to a person—was associated with median productivity gains of 71%. That association partly reflected tasks where mistakes were easier to recover from, rather than establishing that this oversight arrangement would produce the same gains everywhere.
The J-curve: learning takes investment
The podcast discussion invoked the productivity J-curve: a technology can initially cost an organization time and money before its benefits appear in measured output. Staff need training, records need connecting and processes need redesigning. Those investments come before the upward bend in the curve.
For the inner loop, this means that buying a capable model is not the same as building the ability to learn from its use. Someone has to examine failures, decide which changes are worthwhile and put those changes into practice. A company can possess the technology while lacking the time, authority or working arrangements needed to improve its deployment.
During the discussion, a panelist cited McKinsey as finding that only “6% are working” among corporate AI deployments. The November 2025 State of AI report counts something different.
Its roughly 6% high-performing group consists of respondents reporting both significant value from AI and an AI-attributed impact of at least 5% on earnings before interest and taxes. It is a respondent classification, not a project success rate.
The online survey covered 1,993 respondents in 105 nations, was fielded from June 25 to July 29, 2025, and was weighted by national GDP. Overall, 88% reported regular AI use in at least one business function, 64% reported innovation benefits and 39% reported enterprise-level earnings impact. Nearly two-thirds had not begun scaling AI across the enterprise.
High performers more often redesigned workflows and pursued growth alongside cost reduction. Those are associations in reported experience, not experimental evidence that redesign caused superior results. The survey shows that widespread use can coexist with limited enterprise-wide financial impact; it does not show that the other 94% of respondents had failed deployments or had simply not finished a J-curve.
Google's assets are not the loop itself
Ismail's main illustration in the earlier listener Q&A was Google. Even without the leading model in his assessment at the time, he argued, the company had deeper advantages: data centers, YouTube data, billions of users and TPUs, its specialized AI chips.
Those are complementary advantages, rather than iteration speed itself. Chips and data centers provide computing capacity; products with large audiences provide distribution and opportunities to observe use. A feedback loop is the process that turns observations into better products. Having the assets and using them effectively are different things.
The distinction cuts both ways. Google's example supports Ismail's broader claim that model rankings do not capture a company's whole competitive position. But it also raises a challenge for smaller organizations: the ability to learn quickly may depend partly on infrastructure and distribution they cannot readily reproduce.
The loop needs employee cooperation
Graylin added a practical constraint: people may resist supplying the knowledge a deployment needs if they expect it to cost them their jobs.
Asked about organizational barriers in China, he said he thought there were fewer, citing more top-down management and a stronger expectation of state protection. He pointed to Chinese court cases that, in his account, required employers to find another role for workers displaced by automation. He contrasted that reassurance with fear among American employees that documenting their work meant training their replacements. His examples do not establish uniform employment protections in either country.
The connection to workflow recording is direct. Employees can demonstrate how a task is really done, report where an automated version went wrong and explain exceptions that a screen recording missed. In Graylin's argument, credible expectations of continued employment make that cooperation easier; fear of replacement works against it.
The Playbook shows why that fear cannot simply be dismissed as resistance to change. Headcount reduction appeared in 45% of the successful deployments' outcomes, alongside redeployment and avoidance of planned hiring. A deployment can create measurable value for an organization while leaving employees worried about who receives the benefit.
For a useful learning loop, the practical question becomes what the organization can credibly offer in exchange for workers' knowledge: a different role, training, a share of the gains or another explicit arrangement. Faster feedback alone does not resolve that bargain.
A proposal to keep the learning locally owned
Intelligent Internet's overview gives the idea an institutional form. The company proposes locally owned intelligence utilities called Champions. These would deploy personal agents—AI systems that carry out tasks—place integration engineers inside organizations and provide robotics services using customizable open infrastructure.
The embedded engineers are central to the connection with the inner loop. Their proposed role puts integration work inside the institutions whose processes and needs the systems must understand. The company argues that value increasingly resides in deployment, accumulated local knowledge and relationships, rather than access to a foundation model alone.
In this design, sovereignty means more than technical control over a model. It also means having an ownership stake in the institution that deploys it and captures the resulting value. The proposal starts with local investors and a founding council, broadens participation across generations and permits later outside investment while retaining a local stake.
This is a proposed ownership and deployment model, not evidence that locally owned institutions already learn faster than large technology companies. It offers an answer to who should benefit from the loop, while leaving its competitive performance to be demonstrated. Local ownership also leaves open what rights individual workers have over the knowledge they contribute.
Objections and open questions
The first objection concerns the premise. Ismail expects model-building methods to spread, but a lab might sustain an advantage through discoveries that rivals cannot easily reproduce. Better deployment and better models are not mutually exclusive sources of advantage. The Playbook's finding that model choice was critical in 19% of cases preserves a role for model capability, though it does not establish that any supplier can maintain an exclusive lead.
The study cannot settle the competitive claim at the heart of the thesis. It documents organizational obstacles and prior failures among successful deployments. It does not compare firms running the same model to show that the faster learner wins.
A second objection concerns what counts as learning. Shipping faster is useful only if the organization can tell whether a change improved the work. A meaningful test would examine quality, cost and failures—not merely count releases or retraining runs.
The workflow-recording example also leaves ownership unresolved. If a supplier captures a company's processes and turns them into reusable skills, where does the resulting knowledge reside? Contracts and system design could determine whether the customer retains control or becomes increasingly dependent on the supplier. Recording a workflow does not, by itself, establish who may reuse it.
That leads to four practical questions:
- Data rights: Who can authorize the recording and reuse of employees' work and customer information? What may be shared across organizations?
- Employee cooperation: What do people receive for documenting their expertise, and what commitments can they rely on if automation changes their jobs?
- Switching costs: Can an organization take its records, reusable skills and accumulated lessons to another provider, or would changing suppliers mean rebuilding them?
- Infrastructure concentration: Can a smaller company or locally owned Champion learn quickly enough when larger providers control much of the computing capacity and distribution?
The record button makes the tension concrete. A digital version of a company's workflow could become a resource the company controls—or a capability it must keep renting. The inner-loop thesis turns on more than how quickly that workflow improves. It also turns on who is willing to press record, and who can carry the learning into the next version.