Muslim
For decades, the invisible machinery of the internet—the protocols that allow disparate systems to communicate—has relied on a rigorous, human-centric feedback loop. From the foundational layers of HTTP to the modern ubiquity of OAuth and OpenAPI, the evolution of software standards has been a process of friction. A proposal is made; client maintainers, who bear the burden of implementing these standards in real-world applications, push back. They test the changes, report on the awkwardness of the implementation, highlight excessive costs, or signal a lack of developer interest. This "trial-by-fire" process, while slow and often contentious, ensured that only the most robust, useful, and implementable features survived to become industry standards.
Today, that machinery is quietly coming apart. As artificial intelligence moves from an experimental tool to the primary intermediary between humans and software, the feedback loops that once kept protocols clean and intentional are being replaced by the "black box" of LLM-driven adaptation.
The Chronology of a Disappearing Loop
The evolution of protocol design has historically followed a predictable arc:
- The Proposal Phase: Stakeholders identify a need and draft a specification.
- The Implementer’s Veto: Client maintainers—the people who build the libraries and applications—test the draft. If it is too complex or non-functional, they reject it.
- The Refinement: The specification is reshaped based on the implementer’s feedback.
- Production Hardening: Once shipped, the real-world usage data informs the next iteration.
This second loop—the production feedback—has historically been the most honest. It revealed what actually broke, what was ignored, and where developers had to build "hacks" to bypass the spec. However, as the industry pivots toward agentic AI frameworks, the second loop is vanishing. We are no longer designing for human developers who report bugs and request features; we are designing for models that are inherently designed to "make it work" regardless of the underlying protocol’s intent.
The Death of the "Client Owner"
The first systemic break in this process is the dilution of client ownership. In the past, the people sitting at the table designing the protocol were the same people responsible for writing the code that would implement it. If a proposal was impractical, the "client owners" were present to stop it in its tracks.
Now, the room is filled with platform owners, server-side architects, and product visionaries—but rarely the people who maintain the client libraries. When working groups ask, "Who is actually interested in this?" the room is often silent. There is no one who can commit to the heavy lifting of implementation because the client landscape has shifted. The majority of the ecosystem now relies on a small number of massive vendors or a "long tail" of agentic frameworks that treat protocols as mere suggestions. These frameworks often bypass manual implementation entirely, instead feeding the raw protocol data to a Large Language Model (LLM) and allowing the AI to "figure it out" at runtime.
The Model as a "Black Box" Buffer
The second, and perhaps more dangerous, break is the emergence of the model as an automated buffer that masks technical debt. When a legacy client encountered a protocol primitive it didn’t understand, it failed loudly. Developers saw errors, documentation was consulted, and the standard was corrected.
Today, when an AI-driven agent encounters a primitive it doesn’t understand, it does not crash. It "flattens" the data. If a protocol introduces a complex resource structure, the agent ignores the nuances, converts the resource into a generic tool call, and proceeds as if nothing happened. From the perspective of the specification, the code is "working." In reality, the protocol’s intent is being bypassed by a model that is simply good at improvisation.
One prominent coding agent recently adopted a strategy where every server request is routed through a code-execution sandbox. Instead of the client actually implementing the protocol’s features, the model writes the "glue" code on the fly. While this is efficient and keeps context windows small, it creates a total lack of transparency. There is no implementer to report that a primitive was unclear, and no production data to signal that a feature was unused. We have moved from a system of review to a system of survival: we release a change, point a model at it, and see what "survives" the AI’s interpretation.
Survival is Not the Same as Review
Proponents of this new, AI-driven paradigm often argue that "survival" is the ultimate test of a protocol. If a feature is useful, it will be used; if it is not, it will be ignored. They argue that this "dogfooding" approach allows for faster iteration and prevents the need for endless, bureaucratic consensus.
However, this ignores the hidden cost of "silent adoption." A protocol primitive that is never truly implemented as a first-class citizen doesn’t die—it lingers. It becomes technically "adopted" but practically invisible. Because the AI masks the failure to implement, the specification maintainers never receive the signal that the feature is broken or redundant. They read this silence as consensus, leading to "protocol drift," where the standard on paper and the standard in reality diverge significantly.
Furthermore, we are seeing the rise of "AI-assisted drift." When maintainers use AI to translate reference implementations into multiple languages, the specification becomes the output of the very tools it was intended to constrain. If the AI model has a bias or a misunderstanding of the protocol, that error is codified into every SDK generated thereafter.
Implications for Future Engineering
The implications of this shift are profound. As we move further into an agentic future, the following risks emerge:
- Loss of Interoperability: As agents "route around" standards, we risk creating a fragmented ecosystem where two systems appear to be using the same protocol but are actually executing entirely different logic based on how their respective models interpreted the spec.
- Degradation of Debugging: When something goes wrong in an AI-mediated system, the "failure" is no longer a clear protocol violation. It is an emergent behavior of a model’s hidden logic, making it nearly impossible to trace back to a specific line in a specification.
- Stagnation of Standards: By assuming that the "model will work it out," we remove the incentive for developers to innovate on the protocols themselves. Why improve a standard if the AI can just patch over the flaws?
A Call for Instrumented Specifications
We cannot—and should not—attempt to return to the slow, manual processes of the past. The speed of AI is here to stay. However, we must evolve how we build specifications to accommodate this new reality. If models are the primary consumers of our protocols, we must treat them as such.
We need to transition toward instrumented specifications:
- Reference Harnesses: We must build rigorous reference harnesses that treat every primitive exactly as the spec intends. This ensures that there is at least one "source of truth" client that can define what the protocol looks like when fully honored.
- Conformance Testing: We need automated testing suites that fail when a client (or an agent) attempts to "flatten" or bypass a primitive. Conformance should be a hard requirement, not a soft suggestion.
- Explicit Usage Signaling: Since the "model worked it out" is not a valid measurement of success, we must implement purposeful telemetry. We need to collect data on which primitives are being used, which are being ignored, and which are being interpreted in ways not intended by the creators.
- The "First-Class" Audit: Before a new primitive is finalized, the working group should explicitly document which clients will treat it as a first-class feature and which are likely to route around it. Writing this down creates a roadmap for future development and identifies potential dead ends before they are codified.
The client side of the software industry has become a "dark continent" where specifications are decided by the opaque heuristics of Large Language Models. We have stopped asking the clients what they need, and in doing so, we have lost our primary source of quality control. It is time to stop watching the dogs and start building the instruments necessary to hear what they are actually doing. Only then can we ensure that the protocols of the future remain as robust, transparent, and intentional as the ones that built the web of today.
Lina Irawan
Sagoh
