--- title: "The Universality Proof Says the Loop Is the Product" slug: "transformer-universality-proof-finite-resources-own-the-loop" author: "ibl.ai Engineering" date: "2026-10-10 09:00:00" category: "Premium" topics: "transformer universality, Kolmogorov complexity, minimum description length, ICLR 2026, Turing completeness, Gemini 4 Argon, model commoditization, agent harness, elicitation gap, enterprise AI architecture, model-agnostic infrastructure" summary: "A Google DeepMind paper at ICLR 2026 is circulating as proof that Transformers can represent any computable function. The paper says the opposite about real systems: because a deployed model has finite layers and a finite context window, it \"cannot be strictly universal.\" Universality is a statement about resources growing without bound, which makes the resource layer — depth, context, tool calls, retrieval, the loop — the thing that decides capability. That layer is the one a buyer can own." banner: "" thumbnail: "" linkedin: | A claim is going around that researchers "just proved Transformers are computationally universal" and can represent any computable function. We went to the paper. It is more interesting than the claim, and it points the other way. The paper is "Bridging Kolmogorov Complexity and Deep Learning" (arXiv:2509.22445), by Peter Shaw, James Cohan, Jacob Eisenstein and Kristina Toutanova at Google DeepMind, accepted at ICLR 2026. Three things the summary loses. First, universality is not the headline. Theorem 1 is about compression: "There exists an asymptotically optimal family of two-part codes for Transformer encoders." The Turing-machine construction is a lemma in service of that. Second, and this is the sentence that matters, the authors write: "Since any real-world model, such as a Transformer, has finite resources (e.g., a finite number of layers and context window), it cannot be strictly universal." The guarantee holds in the limit as model resources increase. The construction needs depth and context window that grow with the problem's resource bound, plus prompt tokens that carry the program. For a fixed, finite model the result "only formally constrains the description length of a subset of the computable functions." Third, it is not new. The paper says it extends prior work on the Turing completeness of Transformers, citing Pérez et al. 2021 and Nowak et al. 2024. So read it as a procurement document. If capability is bounded by resources around the weights rather than by the weights, then the layer that decides what your system can do is the layer you assemble: context, retrieval, tool calls, depth of loop, evaluation. A pre-registered controlled study we wrote about this week put the spread from scaffold choice alone at up to 28 percentage points inside a single model. That layer is also the only one a vendor can quietly keep. With ibl.ai you own all the code and the data, run it model-agnostic across any LLM, and pay by usage with no per-seat pricing. #iblai #EnterpriseAI #AIArchitecture #AgenticAI #ICLR2026 --- ## The Short Answer **A Google DeepMind paper at ICLR 2026 states a finite Transformer "cannot be strictly universal": capability is bounded by the resources around the model. On ibl.ai you own all the code and the data, run it model-agnostic across any LLM, and pay with no per-seat pricing.** A result about unbounded resources is circulating as a result about models. Read correctly, it is the strongest available argument that the model is not where your advantage lives. ## What did the Kolmogorov-complexity paper actually prove about Transformers? It proved a compression result, and used a universality construction to get there. The paper is [Bridging Kolmogorov Complexity and Deep Learning: Asymptotically Optimal Description Length Objectives for Transformers](https://arxiv.org/abs/2509.22445), by Peter Shaw, James Cohan, Jacob Eisenstein and Kristina Toutanova at Google DeepMind. First posted 26 September 2025, revised through 2 March 2026, accepted at ICLR 2026. Theorem 1 is the headline, and it is about description length, not capability: "There exists an asymptotically optimal family of two-part codes for Transformer encoders." In plain terms, it establishes that a minimum-description-length objective over Transformers can approach Kolmogorov complexity as resources grow. The Turing-machine emulation is a lemma in service of that objective. The construction emulates a universal prefix Turing machine, and only over programs that halt within the given step and register bounds. It is built with ALTA, a symbolic-program-to-weights compiler from the same group's earlier work. Scope matters too. The result covers Transformer **encoders** on sequence classification, with rational-valued logits. Decoders are named as future work, not as a covered case. ## Why can a real, finite Transformer not be strictly universal? Because the construction buys universality with resources that grow, and a deployed model's resources do not. This is the authors' own sentence, and it is the one the circulating summary drops: "Since any real-world model, such as a Transformer, has finite resources (e.g., a finite number of layers and context window), it cannot be strictly universal." The construction needs a number of layers and a context window that both scale with the resource bound of the program being emulated. It uses layerwise weight sharing, in the Universal Transformer style, and prepends learnable prompt tokens that encode the program itself. For a fixed, finite model the paper is explicit about what survives: the result "only formally constrains the description length of a subset of the computable functions that could be represented," and "serves primarily to establish a worst-case upper bound." Guarantees hold "in the limit as model resources increase," and up to an additive constant. So the honest reading reverses the popular one. Depth, context window and the program you prepend are not implementation details around a universal engine. They are the terms that decide what the system can compute at all. Nor is the underlying idea new. The paper states it extends prior work establishing the Turing completeness of Transformers, citing Pérez et al. 2021 and Nowak et al. 2024. The phrase "just proved" attaches a 2026 date to a literature roughly five years old. ## Did Google's engineers abandon Claude once they got Gemini 4 Argon? No. The reporting says close to the opposite, and the model in question is not generally available. Gemini 4 Argon is real. Google DeepMind announced it on [30 September 2026](https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-4-argon/), with a one-million-token output limit, 77.9% on DeepSWE, and list pricing of $2 per million input tokens and $10 per million output tokens. Access is the part that gets dropped. As of this writing Argon is limited to Google's Fairwind Program for trusted cyber defenders, with no public API model identifier, so "engineers got access and switched" describes a population almost nobody is in. And the direction of travel is the reverse. Business Insider reported in mid-September 2026 that Google had opened Claude Opus 5 to all of its engineers through Antigravity, relaxing earlier restrictions, while keeping Gemini primary and foundational. Claude Opus 5.5 was added later. We are not linking that report because we could not resolve a stable primary URL for it in this session; the claim is attributed in prose instead, and should be read as press reporting rather than a Google statement. The useful lesson is about the shape of the story, not the scoreboard. A frontier release is a procurement event only if you can route to it, and a buyer who can route to any provider treats every release as an option rather than a migration. ## If model capability is not the constraint, what is? The resources and the loop around the model, which is measurable and which moves results further than a model swap does. The theory says capability is bounded by resources. The empirical record agrees. A pre-registered controlled comparison held tasks fixed and varied only the orchestration pattern, and found scaffold choice alone moving measured accuracy by as much as 28 percentage points inside a single model. We wrote that one up in [scaffolding moves accuracy 28 points, model choice is the smaller variable](/blog/scaffold-effects-ai-accuracy-architecture-not-model-choice), which also names the gap the paper there calls the *elicitation gap*: the distance between what a model can do and what its harness lets it do. Put the two side by side and they are the same claim at different altitudes. The universality result says resources decide what is representable. The scaffold result says, on real tasks, resources decide what is actually elicited. Neither of those layers arrives with a model subscription. Retrieval over your own systems, typed relationships between your records, tool permissions, loop depth, evaluation sets: every one is something you assemble, and every one is a term in the capability you end up with. That is also why the model layer reprices without changing your position, the argument in [the model is the commodity, the context layer is the moat](/blog/context-layer-is-the-moat-not-the-model). ## What does owning the loop look like in an enterprise deployment? It means the resource layer runs inside your perimeter, as source code you keep, with the model as a swappable input. Concretely, on ibl.ai that is connectors exposing your systems in place over [MCP](https://ibl.ai/docs/os/agent-settings/mcp) and scoped to each caller's role; an ontology of typed relationships so a record in your SIS and a record in your CRM are known to describe one person; and skills written in plain Markdown by the people who do the work. The execution half is the part most buyers rent. We ship it to be run: the [ibl.ai code-execution sandbox](https://ibl.ai/updates/platform-update-2026-10-09) is built on KVM microVMs, runs on your own servers, and is managed end to end from one command, with a built-in egress firewall for every guest and per-host session caps. Around it sit the controls that make a loop auditable rather than merely functional: [Evaluations](https://ibl.ai/docs/os/agent-settings/evals) with LLM-as-judge scoring plus human annotation, [Transcripts](https://ibl.ai/docs/os/analytics/transcripts) and [Audit](https://ibl.ai/docs/os/analytics/audit) for what ran, and [Roles](https://ibl.ai/docs/os/organization-settings/roles) for who may invoke what. You own all the code and the data, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing, so you can deploy anywhere, including on-premise and fully air-gapped. That last property is what turns a model release from a migration into a configuration change. When Argon or its successor becomes routable, you re-point the loop and keep every layer you paid to build. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on. ## The Edge The paper everyone is citing as proof that the model can do anything contains the sentence that proves the opposite about anything you will actually deploy: a finite Transformer "cannot be strictly universal." That single clause relocates the entire buying decision. If universality is purchased with unbounded depth, unbounded context and a program prepended to the input, then the depth, the context and the program are the product — and all three are assembled outside the weights. Which means the most important question about an AI system is not how capable its model is. It is who holds the layer that decides how much of that capability gets elicited, and whether you still hold it after the contract ends. *Related: [scaffolding moves accuracy 28 points, model choice is the smaller variable](/blog/scaffold-effects-ai-accuracy-architecture-not-model-choice) — the pre-registered measurement of how much of a benchmark score belongs to the harness rather than the model.* *Sources: the theorem statements, the "cannot be strictly universal" sentence, the resource assumptions, the encoder/rational-logit scope and the prior-work citations from [arXiv:2509.22445](https://arxiv.org/abs/2509.22445); Gemini 4 Argon's announcement date, context limit, DeepSWE score and token pricing from [Google](https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-4-argon/); the ibl.ai sandbox's microVM basis, egress firewall and session caps from [the 2026-10-09 platform update](https://ibl.ai/updates/platform-update-2026-10-09). The widely-quoted line "the model is not the agent, the loop is" is attributed online to Andrej Karpathy; we could not locate it in any primary source of his and have therefore not quoted it. Google's internal model usage is press reporting, named in prose and deliberately unlinked for the reason given in that section.* ## Why does owning the AI stack matter? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** - **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours. - **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform. - **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ. - **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.