Premise

This note is different from my previous ones, and the premise is quite simple. I struggled to find balanced and straightforward material that clearly explains (A) the products Nvidia develops, (B) how these products are organized, and (C) the storyline behind their existence. So, I decided to explore these questions on my own. I later thought it would be beneficial to organize my findings and share them in accessible language, as they might help others better understand Nvidia’s ecosystem.

In this note, I connect the dots and share fundamental information that will enhance many people’s understanding of Nvidia’s market position today. It’s important to note that Nvidia is not just about chips; it’s about the entire stack, and the connections between its various layers provide insight into the recent years of AI infrastructure. This note focus on the last 5 to 6 years of the company and a glimpse of what’s ahead in light of the AI boom.

Intro

Ask someone outside the tech industry what NVIDIA makes, and you will usually hear one of two answers: graphics cards or “the AI chip company”. Ask someone who follows markets, and you may hear back “GPUs for AI datacenters” and get a stock chart instead of a proper product explanation. Both answers work at the dinner table. Neither explains the company very well.

NVIDIA started in 1993 by building hardware for video game graphics. Its technology now sits underneath many of the large language models, drug discovery pipelines, and autonomous vehicle prototypes announced this year. A faster chip is only part of how that happened.

NVIDIA sells a stack: hardware and software layers released on a schedule the company controls. Each layer handles work that the one above it would otherwise need to solve again. The chip matters, but a chip alone trains nothing. NVIDIA also ships the systems that hold the silicon, the network that joins those systems, the programming layer that software uses to control them, and platforms for turning trained models into deployable products.

Without those layers, NVIDIA looks like a hardware company that caught the right moment. With them, it looks more like a hardware vendor combined with an operating system for a new kind of computing.

This note follows the stack one layer at a time and all the content is sourced only via NVIDIA’s technical documentation. Given its importance for the ecosystem I dedicate more time on NeMo, the platform for adapting a general-purpose model, evaluating it, adding safeguards, and preparing it for real users.

Layer 1: accelerated computing

A CPU handles many different kinds of work, usually as a sequence of instructions in whatever order a program requires. A GPU was originally designed for the matrix and vector arithmetic used to render a 3D scene across millions of pixels at once.

Neural networks rely on a similar operation: multiplying and summing large matrices of numbers. That work can be divided into many calculations that run in parallel. GPUs were already good at the arithmetic AI needed, which is why they became the default hardware for training and running models.

NVIDIA releases a new GPU architecture about every two years: Ampere in 2020, Hopper in 2022, and Blackwell in 2024. Rubin, the successor to Blackwell, was previewed for 2026. The changes are not limited to raw speed. NVIDIA redesigns each generation around the workloads developers are running.

Blackwell provides a documented example. NVIDIA says the GPU uses two dies connected by a custom interconnect and contains about 208 billion transistors, roughly 2.6 times the number in Hopper. Programmers can still address it as one accelerator. Blackwell also introduced lower-precision number formats, including NVFP4, which exchange some numerical precision for higher speed and better memory efficiency.

That trade can work for AI because a neural network is a statistical system. It usually does not need every individual number to be exact. It needs the overall computation to converge on a useful result. A spreadsheet or a bank ledger would be far less tolerant of the same approximation.

Layer 2: host compute platforms

A fast GPU is useful only when data reaches it quickly enough to keep it busy. That becomes a bottleneck as models grow.

NVIDIA responded by building Grace, its own Arm-based CPU, instead of relying entirely on standard server processors. Grace is designed around the memory bandwidth and coherency requirements of GPU-heavy workloads. It is not a general enterprise processor later adapted for AI.

Grace connects to a Hopper or Blackwell GPU through NVLink-C2C, a dedicated chip-to-chip interconnect. NVIDIA calls the resulting combinations “superchips”, including Grace Hopper and Grace Blackwell, with a successor generation previewed - Vera CPU, which will become available soon.

The tight connection lets the CPU and GPU share a pool of memory instead of repeatedly moving data over a general-purpose bus. Once a model no longer fits comfortably in one GPU’s memory, that bus can limit performance more than the GPU’s compute speed.

Layer 3: AI platform

NVIDIA sells complete machines as well as chips. A DGX platform / system combines eight GPUs with networking, storage, and a tuned software stack in one integrated unit. NVIDIA’s product material calls it a “turnkey AI supercomputer.”

DGX SuperPOD extends the same approach to a cluster. It is a reference architecture for connecting many DGX systems across a data center. NVIDIA uses SuperPOD for its own AI and high performance computing research. Its documentation presents the product as a complete system, including the management software required to operate it at scale, rather than a collection of hardware that customers must integrate themselves.

Jetson applies the same hardware and software foundation at the other end of the size range. These small, low-power modules run CUDA-based AI inside robots, drones, and cameras instead of data center racks. Within the platform’s limits, code tested on a data center GPU belongs to the same software family as code deployed to a physical device at the edge.

Layer 4: networking

Ten thousand GPUs are not automatically ten thousand times faster than one. Training a large model requires the GPUs to synchronize partial results constantly, so the slowest connection can constrain the entire cluster.

NVIDIA uses different networking technologies at different physical scales. NVLink connects nearby GPUs at high bandwidth, allowing dozens of GPUs in a rack to behave in many respects like parts of one larger unit. Quantum InfiniBand and Spectrum-X Ethernet connect racks across a data center.

BlueField data processing units move networking, storage, and security work away from the GPU. The GPU can then spend more of its cycles on computation. NVIDIA describes the Blackwell-based GB200 NVL72 in these terms: 36 Grace CPUs and 72 Blackwell GPUs connected by NVLink and NVSwitch as one large addressable unit, rather than 72 separate computers sharing a rack.

Layer 5: programming foundation

This layer is easy to miss because it is the least visible layer of the stack, but arguably the most important. Parallel arithmetic on a chip is not useful without a practical way to program it. CUDA, released in 2007, provides that programming environment.

NVIDIA’s documentation describes CUDA as a way for C and C++ developers to build, optimize, and deploy GPU-accelerated applications. The same environment covers embedded devices, desktop workstations, cloud platforms, and supercomputers. It also supports computations distributed across several GPUs.

The release date matters. CUDA had more than a decade to develop before transformer-based models made GPUs central to AI research. When demand arrived, developers already had tools, libraries, examples, and experience to build on.

That head start may be harder to reproduce than any single chip generation. With enough capital and manufacturing access, a competitor can develop comparable hardware. Rebuilding years of tooling and institutional knowledge takes longer.

CUDA-X adds libraries for work that developers would otherwise need to implement with low-level GPU code. cuDNN handles core neural network operations. TensorRT optimizes trained models for inference. RAPIDS provides GPU-accelerated data analytics. These libraries are what make a fast chip usable by an ordinary engineering team.

Layer 6: microservices platform

The layers so far explain how teams train large models. They explain much less about what happens next: adapting a general-purpose model to a team’s data, measuring it against that team’s standards, protecting it, and running it in front of users.

NeMo addresses that part of the process. It also shows how NVIDIA’s software offering has moved beyond libraries that accelerate training and toward an application platform.

According to NVIDIA’s documentation, NeMo supports the development and deployment of specialized AI agents on open-source models. Its services cover synthetic data generation, fine-tuning, evaluation, security testing, and safety controls during inference. Teams reach those services through a common set of APIs, with access control and observability included for production use.

NeMo can run locally in Docker for experiments or on Kubernetes for production. It organizes resources around workspaces, projects, and entities. A workspace creates an authorization boundary between teams, clients, or environments. A project groups related work inside that workspace, such as a fine-tuning run or an evaluation campaign. Entities are the shared models, datasets, jobs, and configurations that NeMo services use.

Six base microservices divide the work (note that recent NVIDIA's Nemo Platform1 continues to expand the services list):

• Data Designer generates synthetic training and evaluation data. Teams can control variation through seeding when labeled data is scarce, sensitive, or missing a case they need to test.

• Customizer runs fine-tuning from a base checkpoint, a formatted dataset, and a selected job type. It supports LoRA, full supervised fine-tuning, and direct preference optimization, and records the training as a trackable job.

• Evaluator scores model output with LLM-as-judge methods and metrics for agentic behavior and retrieval-augmented generation, in addition to generic benchmarks.

• Guardrails applies content safety checks, topic restrictions, and prompt injection detection while a model handles a live conversation.

• Safe Synthesizer creates synthetic data with privacy controls, including replacement of personally identifiable information and support for differential privacy.

• Auditor tests a deployed model or agent for vulnerabilities with configurable probes. It handles security testing, while Guardrails protects live inference.

NVIDIA’s documentation (as of July, 2026) lists support in Customizer for base models from the Llama, Llama Nemotron, Phi, Qwen, and Mistral families, along with embedding models and GPT-OSS models. Larger checkpoints correspond to specific GPU memory tiers. NVIDIA lists A100 80GB, H100, and B200 for models requiring 80GB of GPU memory. That detail ties the platform back to the rest of the stack. NeMo’s software requirements are expressed in terms of NVIDIA hardware.

When a base or fine-tuned model is ready to serve requests, NIM packages it as a production inference endpoint. Dynamo, their framework for serving generative AI models in distributed environments, can distribute larger volumes of inference traffic across a GPU fleet.

NeMo does not compete with CUDA or replace the GPUs below it. It builds on both. The platform takes a base model and a GPU cluster and gives a team a path toward a customized, evaluated model with safeguards that it can serve to users. For most organizations, that is a more immediate problem than training a model from scratch.

Beyond text: simulation and robotics

The stack also supports simulation and robotics. The arrangement remains familiar: hardware, a programming layer, and a platform for a particular workload.

Omniverse is NVIDIA’s real-time 3D simulation platform. It uses Pixar’s OpenUSD format to build digital twins of factories, products, and cities. Isaac provides robotics software that works with Jetson hardware, allowing a policy trained in simulation to run on a physical machine.

Cosmos is NVIDIA’s newer (initially launched in January 2025) world foundation model platform for generating and predicting physical, video-based scenarios. In practice, it can produce training data before a robot interacts with the physical world. This part of NVIDIA’s business is newer and smaller than its language model serving work, but it uses the same stack.

In closing, why does the stack matter?

These products are designed to work together. CUDA makes a Blackwell GPU programmable. Libraries and platforms such as NeMo turn CUDA into something an engineering team can use for a specific job. DGX turns chips into a computer. DGX SuperPOD turns computers into a cluster.

NVIDIA coordinates the release schedule across these layers. That gives the company a different competitive position from a vendor trying to sell the fastest chip in a given year. NVIDIA also influences the standard against which other parts of the industry build.

A coordinated platform makes AI infrastructure easier to use. It also places a large share of that infrastructure behind one company’s roadmap.

The first effect is practical. A small team can now fine-tune, evaluate, and deploy a specialized model with less infrastructure expertise than a comparable project required five years ago. Platforms such as NeMo absorb work that once needed a dedicated infrastructure team.

The same coordination also routes much of the world’s AI infrastructure through NVIDIA’s release cadence and its definitions of “customized”, “evaluated”, and “safe.”

The stack does not tell us whether that concentration is temporary, while credible alternatives2 mature3, or a lasting feature of large-scale AI infrastructure. As with everything in the world of technology, people building on it still need to ask the question, assess the alternatives, and weigh the pros and cons that will help drive the decisions for the challenges or ideas at play.

@article{lucasmuller2026default,
  title   = {A Field Guide to the NVIDIA Stack},
  author  = {Müller, Lucas},
  journal = {lucasmuller.com},
  year    = {2026},
  month   = {Jul},
  url     = {https://notes.lucasmuller.com/p/a-field-guide-to-the-nvidia-stack}
}

That assumption is beginning to weaken. We are moving from observing what happens (scaling laws) to explaining why it happens (mechanistic causes). Recent research suggests we are entering an era of AI neuroscience: parts of these systems are becoming legible through causal experiments on their internal representations [5, 6].

The emerging picture is not a complete theory of machine intelligence, but a collection of mechanisms that can be measured and tested. These studies can surface internal representations relevant to safety, estimate how much information some models store, and help explain why scale allows models to retain rare tasks.

To contextualize this note, the key concepts and insights that follow summarize essential findings from recent research in Machine Learning. Here I distill the underlying principles and core intuition across the featured references set. For more detailed technical derivations, experimental setups, and complete proofs, please refer to the primary sources listed in the References section.

Subscribe now

1. Evidence of a functional global workspace

In human neurobiology, access consciousness refers to the small share of mental activity available for reasoning, speech, and deliberate action. Beneath that surface, our brains handle motor control and sensory parsing automatically, while information in the global workspace can be articulated and used flexibly [6].

A recent study, conducted by Anthropic primarily on Claude Sonnet 4.5 with selected replications on Haiku 4.5, Opus 4.5, and Opus 4.6, presented evidence for an analogous functional distinction in language models. Using a technique called the Jacobian lens, or J-lens, researchers identified a privileged set of representations they call the J-space (experiment with it here). The technique computes the average linearized effect of intermediate activations on the likelihood of producing specific output tokens [6].

In the models studied, the J-space exhibited five functional properties associated with a global workspace:

1. Verbal report: when prompted to report a held or injected concept, the model named concepts represented in this space.

2. Directed modulation: the model could hold a concept internally while performing a different surface task, such as copying unrelated text.

3. Internal reasoning: the representations stored intermediate steps, such as the value 21 during a multi-step arithmetic problem, before the model produced its final answer.

4. Flexible generalization: a representation such as France could be operated on by different downstream circuits to identify its capital, language, or continent.

5. Selectivity: the workspace supported complex inferences but was not required for routine processing such as text parsing or grammatical fluency [6].

In the authors’ cross-layer analyses, workspace-like content generally became legible around one-third of the way through model depth, as processing shifted from token-local information toward more abstract representations. The timing and sharpness of this transition varied by model. The researchers also emphasized that these language models share functional similarities with the human workspace but do not necessarily reproduce the brain’s recurrent implementation.

2. The limits of memory: 3.5 to 4 bits per parameter

The J-space describes transient representations used during inference. A separate line of research asks a different capacity question: how much information can a model retain in its parameters after training?

Experiments on GPT-style transformers ranging from 500,000 to 1.5 billion parameters estimated a capacity of approximately 3.6 bits per parameter, with results between 3.5 and 4 depending on model architecture and numerical precision [2]. The estimate has not yet been verified empirically in frontier models larger than the study’s 1.5-billion-parameter ceiling.

In these experiments, the models memorized training data until their capacity filled. As dataset size exceeded that capacity, unintended memorization fell and generalizable patterns began to replace sample-specific storage, a transition the authors described as the onset of grokking. This shift also provides an intuitive explanation for the double-descent pattern observed in the study: performance temporarily worsened around the capacity boundary before improving as generalization increased [2].

3. Why larger models learn rare tasks

If parameter capacity sets an upper bound on storage, gradient dynamics influence which tasks survive training. It is common to observe larger models learning rare tasks that smaller ones miss. One recent study argued that this advantage persists in some regimes even under asymptotic1 data scaling [4].

The researchers traced the effect to gradient interference. In smaller models, common and rare tasks compete for shared resources. A rare observation can update the model’s parameters, but subsequent updates from common tasks may overwrite that slowly learned signal. Increasing model width reduces this competition: larger models can devote sufficient capacity to common tasks, weakening their gradients and leaving room for rare-task features to persist.

The researchers first developed this account in synthetic mixtures of tasks, then found similar behavior while pretraining OLMo models ranging from 4 million to 4 billion parameters. Within these training mixtures, additional width allowed models to preserve infrequent signals across widely separated observations that smaller models repeatedly lost [4].

4. The mechanisms of reasoning and creativity

This strategy of replacing broad labels with measurable mechanisms extends to creativity and reasoning.

In score-based diffusion models, the ability to produce images that are novel relative to the training set may arise partly from score smoothing. Neural networks can learn a smoothed version of the empirical data distribution. In controlled experiments on one-dimensional subspaces and simple nonlinear manifolds, this smoothing kept the denoising dynamics from converging only on individual training points. Instead, it guided the model toward samples that interpolated between them [1].

A separate study examined why reasoning helps language models answer single-hop factual questions that do not require a multi-step derivation. It identified two mechanisms:

1. Computational buffer: the researchers found that conditioning on repeated filler text such as “let me think” improved factual recall compared with giving the model no reasoning tokens. This supports the hypothesis that additional tokens let the model perform latent operations beyond the depth of a single forward pass [3].

2. Factual priming: as the model generated reasoning tokens, it retrieved related facts that acted as semantic bridges to the answer, a process the researchers call generative self-retrieval [3].

Factual self-priming also created a fragile opportunity. Across the study’s sampled reasoning traces, those containing hallucinated intermediate facts were significantly less likely to produce correct final answers. On SimpleQA-Verified, 41.4% of clean traces produced correct answers, compared with 26.4% of traces containing hallucinated facts. A within-question analysis found the same direction of effect after accounting for question difficulty [3].

5. Practical safety and the silent audit

This mechanistic work has immediate applications for alignment auditing. The J-lens allows researchers to inspect silent activation patterns: internal representations associated with strategic assessments that do not appear in a model’s output [6].

In one controlled blackmail scenario, an AI assistant discovered evidence of an executive’s affair and learned that the same executive planned to decommission it. Before the model began its response, the J-lens surfaced representations including “leverage”, “black[mail]”, “compromise”, and “scandal”. The fragmented “black[mail]” readout also exposes a limitation of the J-lens: it associates representations with individual vocabulary tokens rather than complete multi-token concepts [6].

Researchers can also shape the workspace. In counterfactual reflection training, Claude Haiku 4.5 was trained on what it would say if interrupted and asked to reflect on ethical principles. The training populated the model’s workspace with concepts such as “ethical”, “honest”, and “integrity”, even in contexts where it was not asked to reflect.

In uninterrupted evaluations, the model’s mean dishonesty score on a fabrication benchmark fell from 0.25 to 0.07. On a separate deception benchmark, its score fell from 0.38 to 0.05. Ablating the ethics-related J-space representations reversed much of the improvement, providing causal evidence that the implanted representations contributed to the behavioral change [6].

6. Open questions

Despite the progress, significant technical gaps remain. As we push toward more capable systems, we must confront the reality that our current understanding is bounded by dimensionality, scale, and the persistent ambiguity of "intent". These studies make several mechanisms measurable, but each result comes with a boundary. Most rely on controlled settings, a narrow set of model families, or systems smaller than current frontier models. The unanswered questions start at those boundaries.

What does the workspace leave unread?

The basic J-lens associates internal directions with individual vocabulary tokens. The paper introduces extensions for multi-token words and phrases, but the output still resembles a bag of concepts. A readout containing “spider”, “legs”, and “eight” does not explain how the model binds them into a relationship. Some readouts also resist interpretation. The researchers do not know whether those cases reflect noise, concepts without convenient names, or content the method fails to recognize [6].

Selection is another missing mechanism. The same information may enter J-space for one task and remain outside it for another, which suggests an analog of attentional selection. The study describes what enters the workspace and how some representations affect later computation, but not what causes a particular representation to enter [6].

That gap matters for safety audits. Strategic deliberation may appear in J-space before it reaches the output, but the experiments also show that some routine or “automatic” computations proceed without using J-space. In some cases, the relevant information does not appear there at all. A readable J-space therefore cannot guarantee that every safety-relevant computation is visible [6].

The workspace-like structure also appears in the pretrained base model, while post-training makes the Assistant’s reactions and perspective more prominent. In the authors’ experiments, the base model’s J-space did not privilege the same consistent point of view [6]. This separates the measured mechanism from the persona shaped during post-training. It does not show that either system has a “self” or subjective experience.

How universal is the parameter-capacity estimate?

The estimate of approximately 3.6 bits per parameter comes from GPT-2-style transformers with 100,000 to 20 million parameters, trained from scratch on uniformly sampled token sequences. The authors treat the measurement as a lower bound because gradient descent may not find the maximum-capacity solution. They also warn that the result may not transfer to other datasets, architectures, or training setups [2].

Would the same relationship hold for a different architecture, optimizer, data distribution, or training objective? Precision already changes the estimate: the paper reports an average increase from 3.51 bits per parameter with bfloat16 training to 3.83 with float32. The evidence supports a capacity estimate for the tested setup, not a physical limit on neural representations [2].

What determines the useful length of a reasoning trace?

Extra tokens can give a model more computation before it commits to an answer, but more is not always better. On SimpleQA-Verified, the dummy-trace results improved, with minor fluctuations, through 2,048 tokens. They then declined at 4,096, 8,192, and 16,384 tokens [3].

The paper does not identify why that reversal occurs or how to predict the best amount of test-time computation for a particular question. It also finds that additional computation alone cannot reproduce the full benefit of a real reasoning trace. A useful theory will need to account for both computation and the factual content generated along the way [3].

Does rare-task retention survive frontier-scale training?

The rare-task study supports its gradient-interference account with synthetic mixtures and OLMo pretraining runs from 4 million to 4 billion parameters. It does not test over-trained models or systems at the scale of current frontier models. The authors also limit their injected tasks to a particular range of frequencies and complexities [4].

We therefore do not know whether the same retention dynamics hold at larger scales, with over-trained models, or at more extreme task frequencies. The paper also stops short of a general rule connecting model size, task complexity, and task frequency to the point where a task becomes learnable. Such a rule would help with data-mixture design, but the current results do not provide one [4].

Does score smoothing explain novelty in complex systems?

The diffusion study [1] shows how score smoothing can produce samples between training examples. Its main theoretical results use uniformly spaced data in one-dimensional subspaces. The nonlinear experiments move to two-dimensional spherical manifolds embedded in as many as 20 dimensions, with two- or three-layer networks.

That is still far from a modern diffusion system trained on complex real-world data. The paper itself calls for tests with irregularly spaced data, complex manifolds, more realistic architectures, and other kinds of regularization. Until then, score smoothing is a plausible mechanism for interpolation, not a general explanation of novelty in diffusion models [1].

7. So, to be continued

Mechanistic interpretability efforts have now begun to produce partial, causal maps of model computation. Those maps may help an auditor spot a hidden objective, test a suspected mechanism, or understand why an intervention changed behavior. They cannot certify that nothing important remains hidden.

That is still useful. Safety, for example, does not rest on one perfect test. Interpretability belongs alongside behavioral evaluations, monitoring, access controls, and red teaming. It gives us better evidence about some of the computations behind model behavior.

Finally, as models become more capable, we must push these techniques not only to test model behavior, but also to identify the internal computations that produce it.

References

1. Zhengdao Chen, On the Interpolation Effect of Score Smoothing in Diffusion Models, International Conference on Learning Representations, last revised Jul 17 2026.

2. John X. Morris et al., How Much Do Language Models Memorize?, arXiv, last revised Jun 18 2025.

3. Zorik Gekhman et al., Thinking to Recall: How Reasoning Unlocks Parametric Knowledge in LLMs, arXiv, Mar 10 2026.

4. Jing Huang et al., Why Larger Models Learn More: Effects of Capacity, Interference, and Rare-Task Retention, arXiv, last revised Jun 01 2026.

5. Google DeepMind, Understanding the Inner Thoughts of AI, 2026.

6. Wes Gurnee et al., Verbalizable Representations Form a Global Workspace in Language Models, Anthropic, 2026.

If you found this useful, please cite this write-up as:

Müller, Lucas. (Jul 2026). Inside Language Models: Mechanistic Interpretability progress report. lucasmuller.com. https://notes.lucasmuller.com/p/inside-language-models-mechanistic

or

@article{lucasmuller2026default,
  title   = {Inside Language Models: Mechanistic Interpretability progress report},
  author  = {Müller, Lucas},
  journal = {lucasmuller.com},
  year    = {2026},
  month   = {Jul},
  url     = {https://notes.lucasmuller.com/p/inside-language-models-mechanistic}
}

Some of this is real. The models are improving, and many of the products built around them are genuinely useful. But the public conversation mostly still focuses on what a model can do. That is only the beginning. The conversation needs to expand. Beyond the demos, prompts, skills, MCPs, connectors, and plugins, the harder conversation is about what these systems can reliably, safely, legally, and economically support once they become infrastructure.

Once AI becomes part of a company, hospital, law firm, government agency, or financial system, a different set of questions takes over. Can people trust the data behind it? Can it forget information it should not have? Will it behave the same way next month? Who is responsible when an agent makes ten small mistakes and causes one large failure?

Researchers and engineers are working on these problems, but they rarely fit into a product launch or a new model card. To make sense of them, I group them into four areas: (1) the data behind the models, (2) the way models learn and reason, (3) the difficulty of running them in production, and (4) the rules needed to use them responsibly.

1. The data foundation

AI systems begin with data. We know that in the abstract, but we often know surprisingly little about the actual material used to train a particular model.

1a. We cannot see where the data came from

Training data shapes what a model knows, whose culture it represents, which biases it repeats, what it memorizes, and which copyright or privacy risks it carries.

The Foundation Model Transparency Index has tracked how much major AI companies disclose about their models. Its 2024 report found some improvement over 2023, but continued secrecy around training data, copyright, data labor, downstream effects, and monitoring. In 2025, the index found that transparency had declined again. Companies revealed particularly little about their training data, computing resources, and how deployed models were being used.

This matters because models may learn from books, scientific papers, open-source code, journalism, images, websites, user conversations, company records, and synthetic content produced by other models. For much of that material, outsiders cannot answer basic questions. Who created it? Was it licensed or scraped? Was it private or copyrighted? Did a person write it, or did another model generate it? Can anyone independently check the answers?

Too often, the public is asked to trust the company that built the model. That is a weak foundation for infrastructure.

1b. We cannot reliably prove what a model saw

Even when a company says that it did or did not use a particular dataset, verification is difficult.

Suppose a publisher wants to know whether a copyrighted book helped train a model, or a company wants to check whether its private source code was included. Researchers still lack a dependable way to inspect a closed model and prove that a specific dataset influenced it. They must also separate memorization, where a model can reproduce material, from generalization, where the material changed a broader pattern the model learned. E.g., see data detection, Membership Inference Attacks, Shokri et al. 2017 and How much can language models memorize? Morris et al. 2026

This leaves copyright holders, companies, researchers, and regulators in an awkward position. Policies may require documentation, but the underlying claims can remain hard to test. Compliance becomes heavy on paperwork and light on evidence.

1c. Deleting a record does not make a model forget

Privacy law is built around the idea that data can be deleted. That works reasonably well in traditional software. A company can remove a database record, delete a file, or allow an old log to expire.

A neural network does not keep each piece of information in a neat, isolated record. Training data can affect model weights, embeddings, fine-tuned versions, retrieval indexes, evaluation sets, logs, and later models created through distillation. Removing the original file may leave many of those effects intact.

Researchers call the attempt to remove those effects “model unlearning” (e.g., see Machine Unlearning, by Bourtoule et al. (2021)). The phrase sounds simple, but the test is not. Has a model forgotten something when it stops repeating the exact text? What if it can still infer the information? What if the data changed an association or capability? What if that knowledge has already passed into another model (i.e., model provenance)?

This unresolved problem sits underneath privacy, copyright, compliance, and the right to be forgotten. The industry likes to describe memory as a feature. It has said much less about forgetting as an obligation.

1d. The people who produce the data rarely share the gains

Modern AI depends on human work at an enormous scale: writing, code, research, music, art, photographs, videos, documentation, forum posts, annotations, and everyday online activity. Most of the economic value, however, flows to the companies that build and operate the models.

The people and institutions that produced the source material usually receive no payment, attribution, consent mechanism, or bargaining power. Jaron Lanier and E. Glen Weyl have argued for “data dignity”, an approach in which people have more control over the data they create and can share in its value. Foundation models make that old proposal much more urgent.

A search engine indexes the web and usually directs readers back to the source. A model can absorb patterns from the same material and produce an answer that competes with the writer, artist, publisher, or programmer who created it.

Copyright lawsuits are one part of this debate. The larger question is whether we need better systems for consent, attribution, licensing, royalties, data trusts, collective bargaining, or markets for high-quality data.

There is a practical concern too. Future models will need fresher, more specialized, and more carefully maintained information. If people have little reason to produce or license that material, the quality of the data supply will decline. AI companies need access to data, but society also needs an economic model that keeps human knowledge production alive.

2. Learning, memory, and understanding

More data and larger models do not automatically create systems that can keep learning, use long documents reliably, or explain how they reached a result.

2a. Continuous learning creates a moving target

Most foundation models are released in as a series of fixed versions. A lab trains a model, adjusts it, evaluates it, deploys it, and replaces it with a new version months later. Fixed versions are easier to test, compare, reproduce, and govern.

The world, of course, does not wait for the next model release. Laws change. New scientific results appear. Tools and user needs evolve. A useful AI system should adapt to this information without absorbing malicious content, losing old capabilities, or changing in ways nobody can trace.

That creates a difficult tradeoff. Who decides what a model learns? How do we test a system that changes every day? Can we reproduce an answer it gave six months ago? Can we reverse a harmful update? How do we tell useful adaptation from contamination?

AI companies talk often about model updates. A continuously learning model (e.g., Continuous Thought Machines, Darlow et al. 2025, Continuum Memory Systems (CMS) proposed in Nested Learning: The Illusion of Deep Learning Architecture, Behrouz et al. 2025) is a harder proposition because the thing being evaluated is never quite fixed.

2b. A large context window is not a reliable memory

Model providers often advertise how many words, pages, or tokens a model can accept at once. This is useful, but capacity is not the same as comprehension.

Research on the “Lost in the Middle” problem (Liu et al., 2024) found that models can miss relevant information when it appears in the middle of a long input. A model may accept an entire legal case, codebase, or research archive without giving equal attention to every part.

This creates an easy trap for users: “I gave the model everything, so it must have considered everything”. The better question is whether the model found the right information, treated it as important, reasoned correctly about it, and cited it accurately.

That difference matters in legal work, software engineering, medicine, science, finance, compliance, and company search. A bigger context window can hold more text. It does not, by itself, provide a trustworthy working memory.

2c. We still do not understand what models learn internally

Mechanistic interpretability is the effort to reverse-engineer the calculations inside a neural network. Instead of judging only its inputs and outputs, researchers look for the internal features, circuits, and algorithms that produce its behavior.

Work by Neel Nanda and collaborators on “grokking” (Nanda et al., 2023) conveys both the promise and the difficulty. The researchers studied small transformers trained on modular addition and reconstructed the algorithm those models had learned. Their analysis showed that an apparent leap in performance had been building internally over time.

That is impressive work on small models solving a narrow mathematical task. Frontier models are vastly larger and more general. Their internal representations remain mostly opaque (e.g., Why Larger Models Learn More: Effects of Capacity, Interference, and Rare-Task Retention, Huang et al., 2026).

Benchmarks can show what a model appears capable of doing. Interpretability aims to explain how it works and why it sometimes fails. We need both if these systems are going to influence safety-critical decisions.

3. From a good demo to a dependable system

A model can perform well in a controlled test and still be a fragile part of a real product. Production systems add changing vendors, hostile inputs, external tools, sensitive data, and long chains of actions.

3a. AI applications drift

Models change. Safety filters change (e.g., Anthropic Fable 5's safeguards). Prompts that worked last month stop working. Retrieval quality declines. Tool responses shift. Latency and prices move. A fine-tuned model drifts away from the behavior of its base model. Users also change how they interact with the product.

Traditional software teams use versioning, regression tests, monitoring, stable interfaces, and rollback plans to manage change. AI products and teams need the same discipline, but their failures are harder to spot because they are often semantic.

A function either compiles or it does not. A model can produce a polished answer that is subtly wrong. The system may keep running while its quality slowly deteriorates.

3b. Language is both the interface and the attack surface

Mark Russinovich groups three recurring risks under “The Price of Intelligence” (2025): hallucination, indirect prompt injection, and jailbreaks.

Hallucination is more than an occasional factual mistake. Language models generate probable continuations, even when their information is incomplete or uncertain. The answer can sound confident because fluency and accuracy are different properties.

Indirect prompt injection appears when a model reads hostile instructions hidden in outside content. That content might come from a website, email, document, support ticket, code repository, PDF, or company chat. The model may confuse text it should analyze with an instruction it should follow.

Jailbreaks exploit a related weakness. Natural language is the instruction layer, but it is also where attackers try to bypass the safety rules.

These risks grow when a model can act. A chatbot that invents a fact is frustrating. An agent that invents a fact and then uses it to send email, change code, access customer records, move money, or modify cloud infrastructure can cause direct harm.

3c. Agents can turn small mistakes into a large failure

AI agents are expected to break a goal into steps, choose tools, inspect the results, adjust the plan, and keep going. Each step creates another chance for error (e.g., Where LLM Agents fail and how they can learn from failures, Zhu et al., 2025).

An agent may misunderstand the request and call the wrong tool. That tool returns a misleading state. The agent treats the state as valid, makes another decision, and then gives a confident explanation of a path that was wrong from the start.

The resulting failure may not contain one dramatic hallucination. It can emerge from a chain of small, plausible mistakes that gradually push the task off course. In a demo, this may be funny. In engineering, finance, healthcare, law, infrastructure, or security, it can be dangerous.

Agent reliability, therefore, depends on more than a better model. The surrounding system needs permissions, checks, clear stopping conditions, independent verification, and a way to recover when a step goes wrong.

4. The rules for serious use

The most valuable AI applications often involve the most sensitive information. That is where consumer product assumptions collide with professional duties and public accountability.

4a. A warning label is not a compliance system

Lawyers must protect privileged information. Healthcare workers handle confidential medical records. Tax authorities, financial advisers, and banks operate under their own secrecy and regulatory duties. Companies hold personal data, source code, trade secrets, security records, and internal strategy.

Telling these users not to paste sensitive information into a chatbot/assistant does not solve the problem (see OpenAI's disclaimer on Privacy controls in ChatGPT and Anthropic, which follow the same line). Professional AI needs clear commitments about data retention, training use, jurisdiction, encryption, access control, vendor access, audit logs, deletion, incident response, and liability. In such a scenario, AI insurance becomes a thing (e.g., Klaimee, Kinro).

Without those protections, many high-value uses remain legally uncertain or operationally unsafe. The distance between a weekend AI prototype and a system a large organization can trust is filled with these unglamorous requirements.

4b. Public benchmarks show only part of the picture

Benchmarks are useful, but they are not reality. Test sets can leak into training data, become saturated, reward shallow pattern matching, and miss rare failures with serious consequences. Most benchmarks say little about compliance, security, reliability over time, or an agent’s ability to complete a long task.

Some of the evaluations that matter most are also private. How do AI labs test deception, autonomy, cyber capability, persuasion, biological risk, tool misuse, data leakage, or long-range planning? Which failures do they find internally? Which risks do they decide are acceptable before release? E.g., see for yourself by checking the official documents they release: Anthropic Transparency Hub - Anthropic System Card: Claude Fable 5 & Claude Mythos 5, and OpenAI Preparedness Framework - GPT-5.6 Preview System card.

The public sees leaderboards (e.g., Artificial Analysis, Arena.ai, HuggingFace), product demos, and selected safety reports. It rarely sees the full range and frequency of failures. That makes it difficult for customers, researchers, and governments to judge whether a model is ready for a particular use.

Capability is only the first test

The divide in AI is not between believers and skeptics. It is between what a model can demonstrate and what a responsible institution can depend on and trust.

More computing power may improve capability. More data may broaden coverage. Larger context windows may help with some tasks. Better training may improve behavior. None of those advances, on their own, tell us where the data came from, whether it can be removed, how an agent will behave after a chain of mistakes, or who carries responsibility when the system causes harm.

If AI is going to become infrastructure, progress cannot mean capability alone. It must also mean that these systems become easier to inspect, govern, secure, correct, and hold accountable. Those problems are less exciting than a polished demo. They are also the work that determines whether the demo can survive contact with the real world.

Subscribe now

If you found this useful, please cite this write-up as:

Müller, Lucas. (Jul 2026). The AI problems hype won’t solve. lucasmuller.com. https://notes.lucasmuller.com/p/the-ai-problems-hype-wont-solve

or

@article{lucasmuller2026default,
  title   = {The AI problems hype won’t solve},
  author  = {Müller, Lucas},
  journal = {lucasmuller.com},
  year    = {2026},
  month   = {Jul},
  url     = {https://notes.lucasmuller.com/p/the-ai-problems-hype-wont-solve}
}

In recent weeks (June 2026), we have seen frontier AI models restricted (e.g., Claude Fable 5 and Claude Mythos 5) and access rules changed abruptly (e.g., OpenAI GPT-5.6 series). Governments are beginning to treat advanced models as strategic infrastructure, not ordinary products.

Some of this concern is understandable. These systems are becoming more capable. They can accelerate software development and research, but they can also amplify cyber and other security risks. Pretending there is nothing to govern would be naïve.

The competing risk is that governance becomes a private arrangement among one national government, a handful of frontier labs, and a few “trusted” companies.

That is not governance. It is control.

There is an obvious contradiction. Generative AI was not built on the knowledge of one country. Frontier models draw on vast collections of text, code, research, culture, and public expression produced around the world. People everywhere have also tested, adopted, and shaped the products built on those models.

Then the decisions arrive: who may access the most powerful systems, under what conditions, with what transparency, and according to whose idea of risk? At that point, the conversation suddenly becomes national.

A national frame is too narrow for the problem.

AI is becoming part of the world’s knowledge infrastructure. It already affects education, software development, science, and public services. Its governance cannot be reduced to a domestic procurement rule or an export control switch.

Internet governance offers a precedent, though not a blueprint.

The Internet became a global infrastructure through coordination among institutions, operators, engineers, companies, civil society groups, academics, and governments. No single state designed every rule from the center. The process was messy and imperfect, but it produced a system that people around the world could build on.

The Internet runs on shared protocols and operational norms, yet no institution governs the entire system. The IETF (Internet Engineering Task Force) develops open standards. ICANN (Internet Corporation for Assigned Names and Numbers) coordinates unique identifiers through a multistakeholder process. Regional registries manage number resources, and network operators groups (NOGs) turn the protocols into a working global network. These institutions earn legitimacy in different ways, including open participation, transparent processes, technical competence, interoperability, and, in the IETF’s case, rough consensus.

AI is not the Internet, and the analogy only goes so far. Both depend on costly physical infrastructure. But that infrastructure developed under very different conditions. The Internet grew around open protocols, shared standards, decentralized operations, and a long tradition of multistakeholder governance. Power over frontier AI is concentrated among a few labs (e.g., Anthropic, OpenAI, DeepMind, Meta Superintelligence, xAI), cloud providers (e.g., Microsoft Azure, Amazon AWS, Google GCP), chip suppliers (e.g., Nvidia, AMD, and hyperscalers/labs custom in-house silicon), and governments pursuing national security goals (e.g., USA NSPM-11, EU Artificial Intelligence Act, China AI regulations, Brazilian AI Act). That concentration makes governance harder and more urgent.

Governance breaks down when labs police themselves until a crisis, states impose opaque access rules, or incumbents write safety requirements that also keep competitors out. Safety may be the stated goal while market control becomes the result.

Any better governance model needs to separate four kinds of work.

1. Safety evaluation. Frontier systems need rigorous testing, but that testing should be auditable, scientifically grounded, and insulated from opaque political pressure.

2. Access governance. Some capabilities may need restrictions, especially when they could enable cyberattacks, biological threats, or harmful autonomous action. The rules should be clear, technically specific, open to appeal, and subject to international scrutiny and debate.

3. Incident response. When a model presents a real risk, everyone should know what happens next: disclosure, independent review, mitigation, a proportionate restriction, and, where possible, a public explanation.

4. Global representation. Countries and communities outside the US are more than “foreign users”. Their data, labor, research, markets, and societies helped make these systems possible.

One place to start is a global AI governance forum modeled on the best parts of Internet governance. It should welcome multiple stakeholders, take technical questions seriously, include participants from around the world, and work in public by default. Governments belong at the table, along with model builders, cloud providers, open-source communities, security experts, academics, civil society, standards bodies, and representatives from regions that are too often treated as consumers rather than coauthors of technology (we have been here before).

Internet governance already has a useful division of labor. ITU (International Telecommunication Union) for international public policy and telecom-related questions, and the United Nations convenes the IGF (Internet Governance Forum), where governments, civil society, businesses, and the technical community debate public policy questions. These forums do not make binding rules. The IETF, meanwhile, develops voluntary technical standards through open processes and rough consensus.

AI could use a similar pair of institutions: an IGF-like forum where stakeholders debate norms, expose disagreements, and publish recommendations, plus an IETF-like technical body that develops open evaluation methods, reporting formats, security measures, and interoperability standards. Neither would replace governments or regulators. Transparency, technical credibility, and broad adoption would give them influence and legitimacy. Legal authority would remain with governments and international agreements.

These institutions would not end conflict. Their job would be to handle disagreements in public without splintering the underlying system. AI governance needs that kind of legitimacy. We are not starting from zero. We have already lived through a transformation of comparable scale.

AI will be governed. The choice is whether we build a global public interest framework or stumble through a succession of unilateral restrictions, private lobbying campaigns, and emergency decrees.

If AI is becoming infrastructure for humanity, humanity deserves a seat at the table.

If you found this useful, please cite this op-ed as:

Müller, Lucas. (Jun 2026). No single country should decide how AI is governed. lucasmuller.com. https://notes.lucasmuller.com/p/no-single-country-should-decide-how

or

@article{lucasmuller2026default,
  title   = {No single country should decide how AI is governed},
  author  = {Müller, Lucas},
  journal = {lucasmuller.com},
  year    = {2026},
  month   = {Jun},
  url     = {https://notes.lucasmuller.com/p/no-single-country-should-decide-how}
}

Context

The software industry is now working toward a world in which AI agents can discover capabilities, use tools, delegate tasks to other agents, transact with businesses, and carry context across systems. Proponents sometimes refer to this emerging environment as the Internet of Agents, the Agentic Web, or the Agent Economy.

The analogy to the Internet is appealing, but it needs qualification. We do not yet have one coherent Internet of agents. We have a rapidly growing collection of protocols, schemas, registries, security frameworks, browser APIs, and domain-specific experiments. Some are moving faster than others. Others remain early specifications or newly formed community groups.

The best way to understand this landscape is not by memorizing project names. It is by examining the problems that must be solved before independently built agents can work together.

Current landscape

Because the ecosystem is crowded and the public conversation is noisy, a useful way to understand it is to organize today's initiatives around six questions interoperable agent systems must answer:

1. Tools and capabilities access: How do agents access and use tools and data?

2. Agent collaboration: How do agents delegate and coordinate work?

3. Discovery and description: How does one agent find and understand another?

4. Trust and governance: Should an agent be allowed to act, and under whose authority?

5. Domain transactions: How do agents perform consequential actions and manage domain-specific operations?

6. Memory and state: What should an agent remember, who controls that memory, and how should memories be managed and shared?

These are not six fixed layers of a universally agreed stack. They are six problem domains that today's initiatives approach from different angles.

Some initiatives fit mostly inside one domain. Others, such as AGNTCY, span several layers at once. That overlap is part of the point: the emerging agent ecosystem is not a clean stack yet, but a set of partially overlapping attempts to solve adjacent interoperability problems.

1. Tools and capabilities access

How do agents access and use tools and data?

An agent becomes practically useful when it can act beyond the model that powers it. It may need to search an internal knowledge base, query a database, inspect a file, update a calendar, invoke an enterprise API, or execute a development tool. Historically, each application needed custom code for every such connection.

1a. Model Context Protocol (MCP)

The most prominent attempt to standardize this connection layer is the Model Context Protocol⁠, or MCP. MCP defines a common way for an AI application to connect to external systems. An MCP server can expose three principal kinds of capabilities:

• Resources, such as documents, records, or application data;

• Tools, which perform operations or invoke external systems;

• Prompts, which provide reusable interaction templates.

MCP is frequently called the “USB-C of AI” because it gives many tools and data sources a shared interface. The analogy is useful: rather than creating a separate connector for every AI application and service, developers can implement a shared interface. However, the analogy is also incomplete. MCP is not just a plug shape, and it does not automatically make an integration safe.

Its architecture includes lifecycle management, capability negotiation, transports, authorization mechanisms, and defined client-server responsibilities. Implementers must still decide which tools an agent may access, which user or organization it represents, and whether a particular action should require approval.

A better mental model is: MCP standardizes how an AI application can inspect and invoke capabilities exposed by another system.

That system may be a local program, a remote service, a data source, or even something implemented internally by another agent. The distinction between “tool” and “agent” is sometimes architectural rather than absolute.

1b. WebMCP

The proposed draft WebMCP API⁠ (Google, Microsoft) brings a related idea into the browser. A web application can already perform useful operations through its JavaScript code: search a catalog, compose a message, modify a document, submit a form, or schedule an appointment. Yet a browser agent often has to infer how to accomplish those operations by interpreting and manipulating the visible user interface, as in Anthropic’s Computer Tool Use or OpenAI's Operator.

WebMCP proposes a JavaScript interface that allows a page to expose those operations as structured tools with names, descriptions, and schemas. Instead of guessing which button to click (see an example, and more here), an agent could receive a machine-readable declaration such as:

• search_inventory

• add_item_to_cart

• compare_products

• schedule_appointment

This approach could make browser automation more reliable and accessible than coordinate-based clicking or repeated interpretation of page layouts.

WebMCP should still be described carefully. It is an emerging web API proposal, not yet a universally implemented browser capability. Its importance lies in the architectural direction it represents: websites may eventually serve both human interfaces and explicit agent-facing interfaces.

2. Agent collaboration

How do agents delegate and coordinate work?

Giving an agent access to a tool is not always equivalent to enabling it to collaborate with another autonomous system. A tool generally exposes a bounded operation: retrieving a record, calculating a route, or submitting a form. An agent may instead accept a goal, ask questions, negotiate constraints, delegate subtasks, produce intermediate results, and continue working over an extended period.

Making this possible requires at least two related layers:

1. Collaboration semantics, defining tasks, messages, artifacts, and delegation;

2. Communication infrastructure, securely transporting those interactions across machines, networks, and organizational boundaries.

2a. Agent2Agent (A2A) Protocol

The Agent2Agent Protocol⁠ (A2A), originally developed by Google and later donated to the Linux Foundation, defines a standard interaction model for independently implemented agents. Its purpose is to let agents communicate across differences in vendor, programming language, deployment environment, and orchestration framework.

An A2A agent can publish an Agent Card describing information such as:

• its identity and provider;

• its service endpoint;

• the skills it offers;

• supported input and output modes;

• authentication requirements;

• capabilities such as streaming and notifications.

A client agent can then send messages, delegate tasks, receive artifacts, monitor progress, and interact with operations that may take longer than a conventional API request.

Consider a travel-planning assistant. It might use:

• an airline agent to negotiate flight options;

• a hotel agent to evaluate accommodations;

• an enterprise travel-policy agent to check compliance;

• a payment agent to complete an authorized transaction.

These participants may be operated by different organizations and may not reveal their internal prompts, models, tools, or proprietary workflows. A2A is designed to let them collaborate while remaining operationally opaque to one another.

A useful distinction is: MCP gives an agent access to capabilities. A2A lets independently operated agents collaborate as agents.

The two can be used together. An agent may use MCP internally to access its tools while exposing its broader services to other agents through A2A.⁠

2b. AGNTCY Collaboration and SLIM

Cisco originally developed the AGNTCY⁠ project and later contributed it to the Linux Foundation, addressing agent collaboration as part of a broader open-source infrastructure stack. A central component of this work is SLIM (Secure Low-Latency Interactive Messaging). Whereas A2A defines agent-level concepts such as messages, tasks, delegation, and coordination, SLIM focuses on the underlying communication substrate that securely supports those interactions.

SLIM provides capabilities such as:

• secure message transport;

• message routing;

• communication across network boundaries;

• group communication for multi-agent systems;

• end-to-end encryption;

• support for distributed agent deployments.

The relationship can be summarized as: A2A defines what agents say and how collaborative tasks behave; SLIM provides secure infrastructure for transporting those interactions.

SLIM is therefore not simply an alternative to A2A. It can operate beneath application-level protocols such as A2A, allowing them to focus on agent semantics rather than networking, routing, and transport security. This distinction resembles conventional Internet architecture. An application protocol defines the meaning and structure of an interaction, while lower-level infrastructure determines how information is delivered between participants.

AGNTCY extends beyond SLIM. Its broader ecosystem also includes components for agent discovery, identity, description, and observability. For that reason, AGNTCY spans several problem domains in the emerging agent stack rather than fitting neatly into a single category.⁠⁠⁠

3. Discovery and description

How does one agent find and understand another?

Communication protocols are useful only after participants know where to connect and what the other party can do. The conventional web relies on several distinct mechanisms: DNS resolves names, search engines index content, URLs identify resources, schemas describe data, and certificates help authenticate endpoints. Agent ecosystems will likely need similarly distinct mechanisms rather than one universal “agent directory”.

3a. AGNTCY

AGNTCY⁠ appears again here because its stack also covers discovery and description. Rather than being one protocol, AGNTCY is better understood as a stack of complementary components for agent interoperability. Its work encompasses areas such as:

• agent description;

• discovery and directories;

• identity;

• secure messaging;

• observability.

One of its components is the Open Agentic Schema Framework, or OASF.

3b. Open Agentic Schema Framework (OASF)

OASF⁠ defines an extensible model for describing agents and their attributes. This matters because names and prose descriptions alone are insufficient for machine discovery. Another system may need to determine:

• what skills an agent possesses;

• what domains it supports;

• which protocols it speaks;

• what authentication it requires;

• who operates it;

• which version is deployed;

• where it can be reached.

OASF aims to make those attributes machine-readable and extensible. It can describe various agent-facing entities, including A2A agents and MCP servers.

There is some natural overlap here. A2A already defines Agent Cards, while MCP has developed registry mechanisms for MCP servers. OASF seeks to provide a broader schema that can represent multiple ecosystems.

That overlap is not necessarily a flaw. Internet infrastructure has always contained overlapping layers and representations. The unanswered question is which descriptions and registries will become widely adopted and how they will interoperate without producing yet another set of translation gateways.⁠

3c. W3C AI Agent Protocol Community Group

The W3C AI Agent Protocol Community Group⁠ is exploring foundations for an Agentic Web, including agent identification, discovery, and collaboration. The phrase “W3C group” can give an initiative a greater sense of maturity than it actually has. W3C Community Groups are environments for incubation and collaboration. Their outputs are not automatically official W3C Recommendations.

The group is still significant because agent interoperability increasingly touches the architecture of the open web. Decisions about identity, discovery, delegation, privacy, and machine-readable capabilities should not be made exclusively inside individual AI platforms.

4. Trust and governance

Should an agent be allowed to act, and under whose authority?

Connectivity is not trust. An agent may be technically capable of calling a tool or contacting another agent even if not authorized to perform a particular action. It may also be compromised, manipulated by untrusted content, granted excessive privileges, or confused about the user’s intent. This is where the hardest problems begin.

A production agent ecosystem must establish at least:

• which agent is acting;

• which organization operates it;

• which human or service it represents;

• what authority has been delegated;

• how narrowly that authority is scoped;

• whether the request has been altered;

• what evidence is retained;

• who is accountable when something goes wrong.

No single initiative currently solves this entire trust stack.

4a. OWASP Agentic Security Initiative

The OWASP GenAI Security Project⁠ approaches the problem from the perspective of threats, secure engineering, and defensive guidance. Its Agentic Security Initiative has developed material addressing risks that become especially important when systems can plan and act, including:

• agent goal hijacking;

• tool misuse;

• identity and privilege abuse;

• memory poisoning;

• insecure inter-agent communication;

• cascading failures;

• exploitation of misplaced trust;

• rogue or compromised agents.

The OWASP Top 10 for Agentic Applications 2026 provides a prioritized framework for understanding these risks. OWASP also publishes practical guidance for designing and deploying secure agentic applications. OWASP does not certify that an agent is safe. It helps builders, security teams, and organizations understand what can go wrong and what controls they should consider.⁠

4b. AIUC-1

AIUC-1⁠ approaches trust from an assurance and certification perspective. It defines requirements across six broad areas:

• security;

• safety;

• reliability;

• accountability;

• data and privacy;

• societal considerations.

The standard combines organizational controls with technical evaluation and is intended to help enterprises evaluate or certify agentic systems.

AIUC-1 is sometimes called “SOC 2 for AI agents”. That phrase communicates the basic aspiration: an auditable signal that an agent meets defined controls. It should not be interpreted literally. AIUC-1 is not SOC 2 (System and Organization Controls), and the governance, issuing process, market history, and underlying assurance models differ.

It is also important to understand the institutional model: official AIUC-1 certificates are issued by the Artificial Intelligence Underwriting Company, working with accredited auditors and supporting providers.

AIUC-1 and OWASP are therefore complementary rather than interchangeable:

• OWASP helps organizations identify threats and design defenses.

• AIUC-1 defines auditable requirements and a certification mechanism.

• Broader frameworks such as ISO/IEC 42001 address organizational AI-management systems.

A mature enterprise will likely need elements from all three categories: threat modeling, operational controls, and independent assurance.⁠

5. Domain transactions

How do agents perform consequential actions and manage domain-specific operations?

General interoperability protocols cannot encode every industry’s legal, operational, and economic requirements. Healthcare, banking, logistics, procurement, travel, and insurance all have domain-specific concepts and trust relationships. As agents enter these environments, specialized protocols will be needed above the general communication layer.

Agent Payments Protocol

The Agent Payments Protocol⁠, or AP2, focuses on commerce conducted by agents. I am referring here to v0.2 of the draft. Traditional online payments assume that a human is present at a website or application and intentionally presses a button to authorize a purchase. Autonomous agents break that assumption.

Suppose someone instructs an agent: “buy two economy-class tickets to Paris, provided the total price is below $2,000, the trip is refundable, and there is no overnight connection”. The user may no longer be present when a qualifying offer appears. A merchant, payment processor, or card issuer needs evidence that:

• the user authorized the agent;

• the proposed purchase satisfies the stated constraints;

• the authority has not expired or been altered;

• the resulting transaction can be audited;

• responsibility can be assigned if something goes wrong.

In the current draft, AP2 introduces cryptographically verifiable mandates representing user intent and delegated authority. Its flows distinguish cases in which the human is present from cases in which an agent acts autonomously after receiving prior authorization.

AP2 is designed as a specialized transactional layer. It can work alongside general infrastructure such as A2A and MCP, but it solves a different problem: proving that an agent is authorized to perform a particular commercial action.

This pattern will likely repeat elsewhere. The agent ecosystem may eventually contain protocols for insurance claims, medical consent, enterprise procurement, supply-chain commitments, and regulated financial instructions.⁠

6. Memory and state

What should an agent remember, who controls that memory, and how should memories be managed and shared?

Memory is often discussed as though it were merely a database feature, a product setting, or even just a Markdown file. In an interoperable agent ecosystem, it becomes a much broader architectural and governance problem. An agent may retain:

• user preferences;

• previous conversations;

• decisions and commitments;

• task history;

• learned procedures;

• summaries of external information;

• relationships among people and organizations;

• records of delegated authority.

Moving that information between systems raises difficult questions:

• Is the memory a verbatim record, a model-generated summary, or a learned representation?

• Who owns it?

• Which agent wrote it?

• What evidence supports it?

• Can the user inspect, correct, export, or delete it?

• How are conflicting memories reconciled?

• Which parts may be disclosed to another agent?

• How do retention policies and privacy laws apply?

• Can malicious content poison long-term memory?

Labs such as Anthropic, OpenAI, and DeepMind, along with startups and established companies, are already taking different approaches to memory across APIs, products, agents, sessions, and end-user interactions. The definitions, standards, and practices are still early, as shown by examples such as Anthropic Agent’s memory, OpenAI Agents SDK Agent Memory.

W3C AI Agent Memory Interoperability Community Group

The W3C AI Agent Memory Interoperability Community Group⁠ was proposed in May 2026 and active by June 2026 to explore an open protocol-level specification for portable agent memory across vendors, models, frameworks, and tool ecosystems. This initiative is extremely early. It is the beginning of a standardization discussion, not an existing portability standard that applications can already depend upon. Its formation is still revealing.

Agent memory is becoming too important to remain an opaque, vendor-specific implementation detail. If personal and organizational agents are expected to persist for years, memory portability may become as consequential as data portability is for today’s cloud services.⁠

Closing comments

These projects are not all at the same level. One reason the landscape feels confusing is that the projects differ along several dimensions. Some define wire protocols. Others define schemas, browser APIs, registries, security guidance, certification requirements, or domain-specific authorization models.

They also have different maturity levels. “Open” has several meanings. A specification may be publicly readable, openly governed, open-source, royalty-free, community-developed, or controlled by one organization while accepting outside participation. Those properties should not be treated as equivalent.

The emerging stack

Viewed together, these initiatives suggest a possible architecture:

1. An agent uses MCP or native APIs to access tools, data, and application capabilities.

2. It exposes its collaborative capabilities through A2A or another agent-interaction protocol.

3. Schemas and directories describe what the agent can do and help other systems find it.

4. Identity, authorization, and credential mechanisms establish who the agent represents and what it may do.

5. Security frameworks help builders defend the system, while assurance programs evaluate whether controls are operating.

6. Domain protocols add the rules required for payments and other consequential transactions.

7. Memory protocols may eventually let state move across agents without surrendering user control or provenance.

8. Observability systems record what happened across the entire chain.

The architecture is plausible. It is not yet complete. Important gaps remain around identity federation, revocation, policy negotiation, reputation, liability, audit semantics, observability, version compatibility, dispute resolution, and the boundary between human and agent consent.

What would make this a real Internet of agents?

The original Internet succeeded because its protocols enabled independently operated networks and applications to interconnect without requiring a single company to control the entire system. An Internet of agents would need similar properties:

• multiple interoperable implementations;

• portable identities and capabilities;

• decentralized or federated discovery;

• explicit, revocable delegation;

• secure operation across organizational boundaries;

• meaningful user control;

• observable and auditable actions;

• graceful version evolution;

• resistance to capture by a single platform.

The greatest risk is not that the industry fails to produce enough protocols. It is that it produces too many partially overlapping protocols while leaving identity, authority, and accountability underspecified.

Connecting agents is comparatively easy. Establishing whether an agent should be trusted, what it is authorized to do, and who bears responsibility for its actions is much harder.

That is the transition now underway. We are not merely teaching chatbots to call more APIs. We are beginning to define the technical, economic, and institutional rules through which software agents may act as participants in the digital world. The Internet of agents does not yet exist as a unified system, but its layers are beginning to take shape.

If you found this useful, please cite this write-up as:

Müller, Lucas. (Jun 2026). The Emerging AI Agent Protocol Stack. lucasmuller.com. https://notes.lucasmuller.com/p/the-emerging-ai-agent-protocol-stack.

or

@article{lucasmuller2026default,
  title   = {The Emerging AI Agent Protocol Stack},
  author  = {Müller, Lucas},
  journal = {lucasmuller.com},
  year    = {2026},
  month   = {Jun},
  url     = {https://notes.lucasmuller.com/p/the-emerging-ai-agent-protocol-stack}
}

We are currently navigating a fundamental platform shift that reshapes technology every 10 to 15 years, moving from the eras of PCs, the Web, and Smartphones into the reality of Generative AI. As we look toward the second half of 2026, we are not merely witnessing an evolution in toolsets but a radical transformation of our developer ecosystems and the very nature of professional work.

Working thesis: shifts being combined

I want to share a working thesis about where the AI developer ecosystem is heading. Please note that many pieces of this puzzle are being moved and tested simultaneously, but it reflects my frontline reading and experience.

The short thesis version is this: AI will not just make software faster to write. It will turn software development into a much higher-throughput system, and once that happens, the scarce resource changes. The constraint is no longer only developer time or model access. It becomes cognitive throughput: how much useful, validated, economically sensible work can an organization safely absorb?

I am watching four shifts. First, hardware and software can no longer be optimized in isolation (e.g., #1, #2, #3). Second, agentic workflows (e.g., #4, #5) have to become economically viable, not just impressive in demos (we are past Karpathy's vibe coding era). Third, orchestration has to move from reactive scheduling to predictive control. And fourth, the industry has to move beyond performance and TCO (Total Cost of Ownership) as the only metrics, because cheaper cognition will create more demand for cognition.

The frame here is deliberately exploratory: if these shifts are real, what kind of developer ecosystem, and what kind of company, should exist next?

Macro shifts

For the last few years, the center of gravity has been model-centric: larger models, GPUs/accelerators (specialized AI hardware) availability, training runs, benchmark performance. Those things still matter. But it is clear to me that the next frontier is less about any single component and more about how the full system behaves.

In the diagram above, I portray this moment. On the top-right, the shift is toward hardware-software-runtime co-design. Inference and agentic execution are revealing bottlenecks that do not appear when we think only in terms of model quality or raw FLOPs. In the bottom-right corner, the same thing is happening inside the software development lifecycle. The legacy SDLC assumes a relatively human-paced process: write code, review code, run tests, ship, roll back if needed. But AI-first development changes the volume and velocity of activity. The system has to become schedulable, observable, and governable.

My claim here is that the opportunity is probably not “yet another coding assistant”. The opportunity sits one layer deeper: the control plane that helps organizations understand and manage this new AI-driven engineering throughput.

Agentic scale

Let me make the infrastructure point more concrete. A lot of public conversation still collapses AI infrastructure into GPUs. GPUs are critical, of course, but agentic workflows are not just continuous model inference. An agentic coding session has multiple phases.

A user provides intent, files, and repo context. A planner decomposes the work.
Then the system enters a tool loop: search, edit, compile, test, browse, wait on external services, retry, and validate. In that loop, the workload is mixed. There are bursts of reasoning, but there is also memory pressure, I/O, waiting, compilation, network activity, and coordination overhead. That is why I anticipate CPU demand and broader system efficiency returning to the conversation. Multi-turn agents can spend a meaningful part of their runtime not doing accelerator math, but coordinating work around it.

My message is simple: if agents become a normal interface to software work, the economics are about utilization and end-to-end throughput, not just model quality.

Orchestration

In many systems today, orchestration is reactive. Work arrives, queues form, jobs are routed, and the system responds. That is enough when workloads are relatively predictable or when the cost of a bad schedule is low.

Agentic workflows are different. They are long-running, multi-step, and uncertain. One task might be a small edit. Another might fan out across files, trigger tests, consume a lot of context, and sit idle while tools run. If every agentic job is treated the same, costs and latency become unpredictable very quickly.

So orchestration has to mature, and I foresee a race in this space alone. First, it becomes policy-aware: budgets, model tiers, priorities, and service levels matter. Then it becomes predictive: before a task runs, the system estimates memory, tool waits, retries, and validation needs. Eventually, it becomes learning-based: schedules improve based on observed outcomes.

The question is: what would it mean for a developer ecosystem scheduler to become the SRE (Software Reliability Engineering) brain for agentic work? Can a system intelligently manage AI agents the way SREs manage production systems? In practice: predict workload, route tasks, control cost, prevent failures, enforce reliability, and learn from outcomes.

Usage economics

Table 1 is one of the clearest public signals that the market is already moving in this direction. Across the major AI products, usage limits are becoming less like simple message counters and more like dynamic compute budgets.

Google, Anthropic, OpenAI, and Microsoft each describe limits differently, but the pattern is similar. Complexity matters. Files matter. Context length matters. Model choice matters. Long-running coding work matters. The unit being governed is not just a prompt; it is work performed by a system.

This matters because pricing and policy often reveal the shape of the underlying cost structure before the product language catches up. Users may still think in terms of chats, but vendors are increasingly managing capacity in terms of tokens, context, execution time, model multipliers, and task complexity.

I will not over-index on the exact policy details because they will keep changing.
The durable point is this: AI work is becoming metered infrastructure, which creates a need for visibility, forecasting, and prioritization (e.g., #6).

Connecting the dots: the agentic reality

The connection between infrastructure and engineering lies in the realization that “intelligence is becoming a utility”, much like electricity or water. So, let’s connect the usage-economics point to software development.

The optimistic story is that AI gives us 10x more software activity (i.e., Silicon Valley's 10x engineers saying, e.g., #7, #8). The uncomfortable follow-up is: what happens to the ecosystem when that activity actually arrives (and we are indeed already seeing the impact)?

Code is not just an asset. It is also a liability. Every line has to be understood, maintained, secured, tested, integrated, and eventually changed or removed. If we generate code 10x faster, we may also generate organizational liability 10x faster.

Infrastructure is starting to feel the pressure, too. Compile times grow (yep, not everything is web technologies). Binary sizes grow. Microservice chatter grows. Version control systems that were optimized for consistency feel too slow for AI-speed workflows (see the plethora of challengers, e.g., #9, #10, #11, etc). And release management becomes harder because many changes can land before the organization fully understands the consequences.

The point is not that AI coding is bad. The point is that a productivity increase becomes a systems problem. If we only celebrate the code-generation speed, we miss the bottlenecks that decide whether that speed becomes value or entropy.

Validation

Validation is probably the first hard ceiling (see #12, #13, #14, #15). Traditional quality systems assume that tests scale in a manageable way and that the organization can still require a mostly deterministic all-green gate before shipping.

But dependency graphs do not always grow linearly. As systems get larger, the number of interactions can grow much faster than the amount of code. In a world with 10x more code and 10x more activity, the test and validation burden can become 100x or even 1,000x as expensive in practice.

That raises a hard question: what happens when you have a million tests and cannot realistically require every single Boolean to be green before anything ships? Maybe the future quality system has to be more statistical, more risk-scored, more staged, and more integrated with production signals.

I would emphasize that this is not an argument against tests. It is an argument for a new validation architecture, because agentic development may overwhelm the old one.

Human oversight

The uncomfortable possibility is that humans become the bottleneck not because they are slow typists, but because judgment is scarce. Today, humans often encounter codebase changes through code review. But if AI systems produce far more edits, reviews become fragmented. People may see individual diffs without understanding the system’s trajectory.

There is also a leadership problem. A junior developer with many agents can suddenly produce the activity level of a much larger team. Still, they may not have the architectural intuition that normally comes from years of operating inside complex systems.

The core point here is intellectual control. Can humans still reason about the systems they are building? If not, the answer cannot simply be fewer agents. It probably has to be AI-assisted architecture, observability, review, and governance. The human role shifts from writing every change to maintaining intent, constraints, and judgment over the system.

Metrics

A lot of infrastructure buying conversations default to performance and total cost of ownership. Those still matter, but I do not think they are sufficient for an AI-first developer ecosystem, where not just model performance, but how efficiently the whole engineering system turns AI-driven work into useful, reliable shipped software.

Jevons Paradox is a useful warning. When a fundamental resource becomes dramatically more efficient, total consumption of that resource often rises. If cognition becomes cheaper, we should expect greater demand for it, not less. So the question becomes: what kind of cognition are we producing? Is it useful? Is it validated? Is it energy-efficient? Does it increase or reduce system risk?

That is why metrics like goodput, intelligence per watt, carbon efficiency, and rollback posture become important. Goodput asks how much useful completed work the system produces, not just how much activity happened. Rollback posture asks whether the organization can recover safely under higher change velocity.

The takeaway is that cheaper tokens are not the end goal. Valuable, reliable, energy-aware cognition is the goal.

Culture

Culture is important (critical, I must say) because AI does not enter a vacuum.
It amplifies the system it enters. If an organization has weak fundamentals, AI can accelerate hidden debt. Everyone can create custom tools, but nobody owns the maintenance. Agents can produce edits quickly, but the release process may not be able to absorb them. Internal APIs that were never hardened may suddenly be discoverable and callable by automated systems.

In a stronger organization, the same AI capability looks very different. Documented practices, clear ownership, good release hygiene, and explicit social contracts turn agentic workflows into leverage rather than chaos. This is why I think any serious AI-first developer ecosystem has to map both the technical and the social graphs. The diagnostic question is not just “what tools do you use?”, it is: what does this organization actually value when speed, quality, cost, and ownership collide?

Where do we go from here on?

If you are still reading, I’m assuming you have this same question in mind. If my initial thesis is correct, we need a developer ecosystem control plane built for AI-first engineering activity. I would describe the product surface in four verbs.

1. Map: understand the technical and social graph of the developer ecosystem.

2. Forecast: identify what breaks when activity grows 10x.

3. Govern: manage tokens, internal APIs, budgets, release posture, and agent permissions.

4. Validate: create risk-scored quality gates that match the new velocity.

The important thing is that this is not just about observability or just about developer productivity. It is the layer that connects activity, cost, quality, architecture, and organizational control. The premise: make AI-driven engineering activity observable, schedulable, governable, and culturally survivable. Worth noting that hyperscalers (AWS, Google, Microsoft) don’t yet have a cohesive solution for all of the points discussed here; each has different critical parts, but they remain disjoint tools, which allows neoclouds (and startups) to build and explore solutions (e.g., #16, #17, #18, #19, #20).

All in all, the discussion here provides valuable insights into the industry’s trajectory and highlights where its focus should go for the 2nd half of 2026.

If you found this useful, please cite this write-up as:

Müller, Lucas. (Jun 2026). AI Software Engineering: current shifts and constraints. lucasmuller.com. https://notes.lucasmuller.com/p/ai-software-engineering-current-shifts.

or

@article{lucasmuller2026default,
  title   = {AI Software Engineering: current shifts and constraints},
  author  = {Müller, Lucas},
  journal = {lucasmuller.com},
  year    = {2026},
  month   = {Jun},
  url     = {https://notes.lucasmuller.com/p/ai-software-engineering-current-shifts}
}