AI is Two Things. Which One is on Your Side?
A Texas war vet's victory over a telco, a sixty billion dollar acquisition, and the part of AI no one told you was separate
I haven’t posted an essay these past couple of weeks because I’ve been consuming my nights and weekends, working heads down on a white paper for an invention, a proposal that might change how AI gets delivered to people. This essay is my case for why we need it, and it starts in a small town in Texas about 60 years ago with a phone.
The farther and farther away we get from having telephones attached to our walls and having to physically go to where the phone is to be able to speak to someone far away, the more strange the idea gets. Did you know that it was even stranger before? Until the late ‘60s, the telephone that was on your wall wasn’t even yours. It belonged to the phone company. When you signed up for phone service, they would install it, and it remained theirs.
Now, at that time, there was no real innovation in the handset technology, and there was no shopping around for different models and different features. And that’s how the phone company saw it. There was nothing there to develop. A handset was just a commodity, a piece of equipment, a fine innovation in itself, which enabled the onboarding of customers to their service network.
We certainly know today that despite the network providers’ near-sightedness, it was more than possible to innovate on that component of the service. You could argue that it is the one daily-use device that has undergone the most user-centric feature augmentation year-over-year, for a long time. The bland providers’ endpoint that was screwed to the wall is now reimplemented to not only talk to grandma, but enable both the consumption and production of videos, track real-time movement of global air traffic, find you a job, and on and on, and it sits in your pocket.
That’s worth giving a moment to sink in. But, at the time, if I would have described half of what a smart phone would be like to a person whose phone is screwed to the wall, it would have sounded as strange as their world does to us. We can’t go anywhere without our phones, and we even configure them to talk some sense into us when we’ve been paying too much attention to them.
Component stacking as a business strategy can be called vertical integration. It often works well when the customer doesn’t realize the integration is separable. Not coincidentally, the design of integrated products often takes pains to hide the seams. For companies, vertical integration can allow a less profitable component of a system or service to be subsidized by a higher margin one. However, it can also be a structure which “double dips” from a customer’s wallet by providing a benefit the customer was looking for, and tying on another they can’t refuse.
Sometimes, as a society we come to realize that it was happening and then decide that it was unfair, either for competitive or consumer reasons. Sometimes we don’t.
At this moment, I propose that another such situation has emerged right under our noses. This time it involves the most rapidly adopted consequential technology the world has ever seen. That, of course, is AI.
Almost no one I ask understands this one basic point. So, it’s worth stating plainly, and maybe repetitively. The AI that you think you know and love, and interact with every day, is at least two separate pieces. The app you download on your phone or laptop does not have the model, it enables you to speak with the model.
The frontier-level models, Claude, Gemini, Grok, Kimi, ChatGPT, et cetera, those are running on datacenters that you will never see or touch. The average person, even the average company, could not afford the hardware it takes to run a model even a fraction of the size or capability. When you press the “Send message” button your text is sent back to home base and the model’s response is sent all the way back to you. These two components could be built by different companies. In fact, they already are.
Once handsets were manufactured apart from the network providers, people could see the potential and the benefit of having a choice on that component of the service. Before then, it was not something that anyone questioned. For AI, many today just don’t question that the app that you use to interact with your favorite AI model is a component that would have to be made by the model’s maker.
Part of what hides the seam is our own psychology. We have a term in development, WYSIWYG, pronounced “wizzywig,” it stands for what-you-see-is-what-you-get. Most people who interact with software associate what we call the frontend user experience with the application, with the product. That’s not to say that the backend doesn’t influence user experience, but it is much, much less present in the user’s own perception.
In dev shops the world around, the divide is so ordinary, their teams face off in the foosball tournament. Frontend and backend roles are so different that there is an entire meme tradition built around chiding either side’s idiosyncratic subcultures. The audience of a good backend developer is just not the direct consumer. The reason there is a title “Full-stack” developer, is because you don’t stack one thing.
This is not at all special to software. You use “stacked” products all day long. The outward appearance and function of the keyboard is a separate design from the inner hardware and the circuit boards. The interface that you mostly associate with your car is the interior surfaces, and they’re made to appear a certain way. Underneath the sophisticated pleather upholstery, and the rubberized pull handles, it’s just stainless steel and greased-up springs.
You can replace the frontend components, and you can use different ones as long as they’re compatible with the backend.
The same is true for AI.
If you have two things you’ve been calling by one name, one of the best ways to start thinking of them differently is to name them separately. In AI, Claude, and Grok are models, then what is the app you use called?
In model-serving infrastructure, an inference client is the library that sends a request to an inference server, and by that definition every person reading this already has one. It is supplied by the model provider, it runs on their terms, and it is exactly the arrangement this essay is about.
What I am making the case for is not just another client, but a class or category of client. It needs its own word because the distinction is not primarily technical, but what it owes.
We call it an inference advocate. It holds the person’s data on their own device rather than the provider’s servers. It verifies which model actually produced a given response, applies the laws of the user’s own jurisdiction at the point of delivery, and enforces standards against providers not by adjudicating individual complaints but by the aggregate, statistical methods that tamed email spam. It is, in one sentence, the advocate that every other high-potency industry already has and this one does not.
We actually are already seeing this specific use case arise on its own, independently. Specifically, it comes from the software development trade itself. That is because of an existing previous technology that already gave us the form factor, which is what we call an integrated development environment.
An integrated development environment is basically the software developer’s desktop work surface, if you will. It is a place where a software developer can access a consolidated tool set that interfaces with the end product, the code base, and augments the developer’s ability to modify and inspect that code base.
When AI came along, since AI can also assist with modification and inspection of code bases, it made sense for the AI chatbots to be integrated with the IDE. What ended up happening is that the model providers opened up APIs for the IDEs to implement their own chat interface however they saw fit. The user interface would be designed by the IDE makers themselves, and the chatting functionality is served over the wire.
The biggest example of those is Cursor, which my team uses every single day. Cursor is built as one of so many forks from the original Visual Studio Code, Microsoft’s prolific MIT-licensed IDE, a solid foundation someone else laid, and it talks to models someone else trained. It’s an inference client bolted onto someone else’s editor, connecting to other companies’ models, and it reached about four billion in ARR in less than four years. About half of Fortune 500 companies have devs using it. This author has it open in the window behind the one I’m typing in.
In June, SpaceX signed a sixty billion dollar all-stock agreement to buy Anysphere, Cursor’s parent company. SpaceX merged with xAI, makers of Grok, earlier this year, so the buyer is a frontier model company. The stated aim is to put Cursor together with Grok, and level-up Cursor’s own models now that they have access to xAI’s Colossus supercluster, and build a vertically integrated AI stack. Statements from both companies, and their joint projects already underway speak to this reality. The deal is expected to close this quarter, pending regulatory approval.
However any market analyst might put it, there is one thing that acquisition declares. Inference clients are valuable. No one agrees to the largest ever acquisition of a venture-backed startup for a custom skin on an open-source editor. The transaction value of $60 billion significantly surpasses the previous record holder, Google’s $32 billion acquisition of Wiz in 2025, and more than triples the $19 billion Meta paid for WhatsApp in 2014.
Back to the phone history lesson, the seam between phones and phone service didn’t open because somebody made a good argument. It happened because of innovation.
In the 1950s, certain businesses would use two-way radios to communicate with their people out in the field, like oil drill operators or florists. A man named Tom Carter, who came from Mabank, Texas, at the time a small town outside of Dallas of less than a thousand people, was a radio technician during the war. Afterwards, he started Carter Electronics Corporation, and he leased those radios. His customers kept asking for the same thing. They wanted their mobile radios to connect directly to the network instead of having to relay every message through a base station operator. With the demand evident for a new product in a category that was only occupied by the network provider’s own standard device, he innovated.
In 1959, the Carterfone was born, an augmentation to the user interface layer of the landline phone network. AT&T didn’t sue him. Instead, they threatened his customers. They told them that anyone using a Carterfone was risking having their phone service shut off. This was a move from their playbook that had worked before, a decade earlier, against a plastic cup that was designed to muffle your handset. Sure enough, his customers began returning the Carterfone, and the business was dying before any ruling was made.
But Carter wasn’t going to take it lying down.
In true Texas fashion, he filed an anti-trust lawsuit in November 1965. It was at those hearings that AT&T said that the rule was necessary for safety. They claimed that any devices that weren’t manufactured by the network provider themselves might harm the network. Carter wasn’t buying it. He said this was simply anti-competitive. On June 26, 1968, the FCC made a ruling, 6-0, that the tariffs were unreasonable, unlawful, and unreasonably discriminatory, and had been since the beginning.
Now, the next part is one to pay attention to. The remedy the FCC proposed wasn’t simply an order that allowed AT&T customers to attach things to their phones. They also gave the carriers permission to file new tariffs so that they could protect their network against any harmful devices, but only if they specified technical standards. They weren’t banning the idea, but they also established the concept of standardization for compatible inventions.
In this case, consumers’ choice was upheld over concerns for network safety. Today, the concern is consumer safety and choice over the providers’ vertical business model.
The innovation didn’t stop with the Carterfone. A few short years after the FCC decision, humanity got an invention that would usher in one of the most revolutionary changes in human society brought about by technology, the modulator-demodulator, or “modem.” The modem was the thing that unlocked the Internet because phone technology was already so widespread. It was a client-side innovation that added immense value to the existing system.
At the introduction of the original telephone handset, one could hardly envision devices like the modem, fax, or answering machines. Now the likeness of the traditional handset has been relegated to a universal symbol of long distance voice communication, which appears invariably on the touch screens of its distant descendants, today’s Androids and iPhones.
Back in 1967, in that hearing room, no one was arguing for any of this. One man was arguing that he had a right to innovate at the middle layer.
Today I’m making a similar argument, but not to regulators. Instead, directly to the market, to you. Now is the part where I need to tell you what the benefits are. Like Tom Carter, I can tell you where they start, but I can’t tell you where they end:
First, you keep your own context with you. Chat histories, contextual files, bio data, it all stays on your device, and comes with you to whatever model provider(s) you choose to buy inference from.
Comparative shopping: not only do you have portable context, but you can see the value of any free or paid services you choose, side-by-side, with an account of what you got for the price.
Parental control: one of the most crucial problems we need to solve in AI gets a major reinforcement with the inference advocate, and the AIDP network protocol.
Verified provenance on the source of your AI conversation history.
Multi-layered delivery policies allowing for jurisdictional rules and individual families’ rules in the same mechanism.
Independent semantic moderation without giving up privacy, to flag incidents and surface trends in real-time to enable immediate intervention.
All of this would be made possible not only by the introduction of the inference advocate, but by a standard I’m calling Accountable Inference Delivery Protocol (AIDP). Being a componentized system rather than centralized, this means that all parts of the system can improve independently of one another. Innovation can happen at each of the component levels.

Beyond what I believe the initial benefits are, which are many, the rest of the list is for the future to hold. If history has anything to offer us, the list will probably grow.
Generally, there is trust that is pulled back from the model creators and providers and control that’s pulled back into the consumer’s own hands. This enables the consumer to have more choice amongst market competitors for all of those things that the client facilitates access to, and gives consumers a duty-bound advocate in every AI inference transaction.
The two reasons everyone should want this are not in competition, even though that’s how they often get portrayed.
We are seeing problematic patterns in our society due to AI that need some surface for intervention, moderation, monitoring, certification, tracking, in a word, control. The need is inarguable. The harm, we’re already experiencing. Taking action doesn’t have to mean imposing a punitive, heavy-handed regime, but we have the possibility to create a system that gives us the control surfaces that we need and adds even more value in the form of consumer choice. The only downsides are for wayward models or malicious actors, but for the rest of the AI-consuming population, the rewards are plenty.
The Carterfone story already ran this experiment. The network didn’t open up because handsets needed innovation. The standards regime came about as a protective technical requirement so that third-party equipment couldn’t harm the provider network, which is to say that the safety case is what precipitated the later innovations. The initial benefit was safety and standardization, and the value of subsequent developments absolutely dwarfed it.
As much as consumer-owned handsets and later internet modems were the better way of using the telecom networks, clients on our own side, inference advocates, are the better way to use AI. Consumers have every reason to normalize a scheme like this for our own sake, to have freedom and control over our data. Society at large gains the greater benefit of the protection of the vulnerable and oversight against abuse.
But before you sit back and assume that this plan will unfold on its own, let’s come back to Cursor, because that example proves that the position is not just real but very much in demand. It also shows you 60 billion reasons the control tends to drift away from the end user.
As this idea has come together in my mind, being a long-time customer of Cursor, I was admittedly inspired by their user experience. Indeed, I thought that Cursor would be the perfect candidate to be a champion of AIDP. They were the first AI-native IDE, an inference client at heart, built from the ground up around an AI development workflow. And they basically had no incentive to resist this merger. We will see if they recognize the right incentive to implement the protocol anyway, to keep the client-provider relationship honest.
No one behaved badly in this deal. Taking sixty billion in stock is the correct move for a company that doesn’t owe a duty to anyone but the shareholders (which is every other company as well), because nothing requires otherwise.
But this is a pattern we see that doesn’t stop because of one victory for society. Carter won with a unanimous vote in June 1968. By November, AT&T had filed the new tariffs allowed by the ruling, which enabled customers to attach equipment to their phones as long as they used a protective coupler supplied and rented from AT&T. The FCC’s staff later testified that this went well beyond what the ruling required. The verdict was clear, and yet the corporate impulse survived.
This isn’t a story about the phone company versus the man. It’s just an old pattern that repeats. The companies that have the seat are run by people who are making a sensible choice for the good of their company. Maybe we should be asking about that on its own terms someday, but for now we should notice what follows from it. You don’t build a system that depends on the occupant of the middle seat being good. You put something good in that seat.
We’ve seen what holds that seat open before. One of those things is a standard, published, open, and specific enough that anyone can build according to it, and anyone can check whether a given implementation followed it.
I have written one. Not a fantastically innovative scheme, but one that has been tried and proven in a similar context. It’s published: the protocol and the architecture. These are dedicated to open use, and the reference implementation has an open license with an express patent grant attached. I don’t make money if this gets adopted. And that is a design requirement, because a standard that one party owns is not a standard.
You can read the AIDP paper on Zenodo at1: https://doi.org/10.5281/zenodo.21610185
What can you do to help? That depends on who you are. If you use AI at all, then there’s certainly something you can do right now that costs nothing. You can prefer to use a client that you didn’t get from the model maker and notice the moments when you can’t get one. That’s how unlocked phones went from being the rare case to the obvious choice.
If you build with AI, then there’s more you can do:
You can implement the protocol.
You can make your own inference advocate client.
You can look at the spec, and you can tell us where it can be improved.
You can call your representatives in government and say that this is what you want.
If you sit on a committee or body considering AI standards, you can advocate for this approach.
I’m building an inference advocate, more on that later. I would rather not be the only one. I hope somebody beats me to it.
Accountable Inference Delivery Protocol (AIDP): An Advocate for AI Users and a Surface for Policy Implementation, Justin Philip Flores, July 2026 https://doi.org/10.5281/zenodo.21610185



