The Quiet Protocol Now Carrying the Autonomous Agent Economy — MCP at 97 Million Installs and What It Changes

The Protocol Nobody Is Writing Think Pieces About

There is a specific category of technology that reliably fails to generate hype cycles even as it reshapes everything downstream of it. It is the category of infrastructure protocols. HTTP in the early 1990s. TCP/IP in the 1980s. USB in the late 1990s. REST APIs in the 2000s. GraphQL and OAuth in the 2010s. In each case the protocol itself never produced breathless headlines, yet without it the applications that did produce headlines would have been impossible to build at the speed and scale that happened.

The Model Context Protocol is that kind of technology. MCP was announced by Anthropic in late 2024 as an open specification for connecting AI models to external data sources, tools, and context. The initial reaction from the broader AI industry was polite indifference. It was another specification among many. It was not even a particularly novel specification — the idea of a protocol for tool use had been proposed by others before. What was different about MCP was that Anthropic released it as genuinely open, shipped a reference implementation that worked out of the box, and aligned the interface design with the way enterprise tools actually expose functionality.

In March 2026, MCP crossed 97 million installs. Every major AI provider now ships MCP-compatible tooling as the default mechanism by which agents connect to external tools, APIs, and data sources. Every major enterprise SaaS vendor has shipped or announced an MCP server. The standardization happened quietly and completely in roughly eighteen months, which is an astonishing velocity for an infrastructure protocol.

You do not hear about it because it is boring, and because the people who benefit from its existence have no incentive to talk about it. But nothing in the autonomous coworker transition — not Claude Cowork, not ChatGPT Enterprise agents, not the enterprise Copilot rollouts, not the mid-cap tech layoffs being announced this week — would be happening at the speed it is happening without MCP as the underlying connective tissue.

What MCP Actually Is

For readers who have not looked at the specification closely, MCP is worth understanding in its actual form rather than through the usual hype-abstracted framing.

The Model Context Protocol defines a standard way for an AI agent to discover, authenticate to, and call external tools. Before MCP, every AI agent that wanted to interact with an external system had to implement a bespoke integration for that system. Connecting Claude to Salesforce required Salesforce-specific code. Connecting GPT-5 to ServiceNow required ServiceNow-specific code. Connecting either to a company's internal tooling required a custom adapter for each tool and each model, built and maintained separately.

The combinatorial explosion was obvious. Every new model required building connectors to every tool. Every new tool required building connectors to every model. Every enterprise AI deployment required months of integration work before any value could be produced. The economics did not work at scale.

MCP solves the combinatorial problem by defining a single protocol that any tool can implement once, and any model can speak once, and the two can then communicate without further custom integration. The protocol handles authentication, capability discovery, invocation semantics, streaming responses, error handling, and version negotiation. Tool publishers ship an MCP server. Model providers ship an MCP client. Enterprise customers connect them.

This is the same pattern as USB-C for device connectivity, HTTP for web resource retrieval, or OAuth for authorization delegation. The protocol does one specific thing well, it is open enough that everyone has incentive to implement it, and once critical mass is reached it becomes the default.

The growth curve is classic infrastructure adoption. Slow in the first six months while early adopters validate the protocol. Linear growth through the next six as adoption moves into mid- market deployments. Exponential acceleration once the critical mass is reached and the protocol becomes the default choice for every new integration.

Who Is Implementing MCP

The list of MCP server implementations, as of April 2026, is a rough map of the enterprise software industry. Category by category.

CRM and customer operations. Salesforce, HubSpot, Zendesk, Freshdesk, Intercom, ServiceNow, Dynamics 365, and a long tail of smaller vendors all ship MCP servers. Customer data queries, record updates, workflow triggers, and report generation are all exposed through a standard MCP interface across every major platform. An agent trained to use one CRM's MCP server can typically interact with another's with minimal modification.

Financial systems. Workday, SAP, NetSuite, Oracle Financials, Sage Intacct, QuickBooks, Xero, and the major banking APIs have all shipped MCP servers. General ledger queries, journal entries, AP/AR operations, and reporting are all standardized. The financial analyst work that OSWorld-V parity has brought within reach of autonomous agents is now actually reachable, because the agents can actually connect to the financial systems.

Collaboration and productivity. Microsoft 365 and Google Workspace both ship MCP servers that expose email, calendar, document editing, and spreadsheet operations. Slack, Teams, Zoom, and Atlassian products all have MCP servers. This is the connective tissue that lets an agent participate in workplace communication rather than just compute in isolation.

Data and analytics. Snowflake, Databricks, dbt, Looker, Tableau, Power BI, and every major data platform has an MCP server. Query execution, dataset discovery, schema navigation, and report generation are all standardized. Data analyst work is reachable at the same level as financial analyst work, for the same structural reason.

Developer tools and code intelligence. GitHub, GitLab, Bitbucket, Jira, Linear, Jenkins, CircleCI, and the major IDE vendors all expose MCP servers. This is the infrastructure behind the autonomous software engineering agents that have been accelerating through Q1 2026.

Specialized verticals. Epic and Cerner in healthcare. Rocket and Unity in games. Autodesk and Bentley in engineering. Bloomberg, Refinitiv, and FactSet in financial data. Every vertical SaaS category has at least one major vendor with an MCP server, and usually most of them.

The vendor-by-category distribution of MCP server implementations. Roughly 270 distinct enterprise software vendors have shipped production-grade MCP servers. That is a remarkably fast standardization curve relative to any prior enterprise API protocol.

Why This Matters Strategically

The reason MCP matters is not that it is technically superior to the alternatives. It is roughly comparable to a well-designed REST API with extra metadata, streaming support, and capability discovery. You could argue about whether gRPC or GraphQL or some other protocol would have been a better foundation. Those arguments are intellectually interesting and strategically irrelevant, because the protocol that standardizes first tends to win.

MCP standardized first. Whatever technical compromises it made are locked in by the network effects. Every new vendor that wants to sell into the enterprise AI market now implements MCP because that is what the agents can speak. Every new agent vendor implements MCP because that is what the tools expose. The standardization is self-reinforcing, and the switching costs to any alternative protocol have become prohibitive.

The strategic implications for enterprise AI buyers are concrete.

First, vendor lock-in is now at the protocol level, not the product level. Before MCP, enterprises worried about being locked into Claude versus GPT-5 versus Gemini because switching between them required rebuilding every integration. With MCP, the integration layer is model-agnostic. A company that builds its agent infrastructure on MCP can swap the underlying model with far less friction. This is a meaningful shift in the negotiating dynamics between enterprise buyers and model providers, and it is why OpenAI adopted MCP support for its enterprise products despite being a late adopter.

Second, the integration layer has been commoditized. The consulting firms and integration specialists that built businesses around custom enterprise-AI integration work have seen their value proposition compress. The work is still there, but the unit economics are different. Implementation projects that took six months now take six weeks. The consulting margin is lower. The value has moved up the stack into supervision, specification, and outcome management, as the HAR analysis of financial analyst work discussed.

Third, agent capability is decoupling from model capability. The most important question about an enterprise AI agent in 2024 was: which model is it running. In 2026, the question is increasingly: which tools does it have access to, and how are they permissioned. The model is becoming a commodity inside a larger architecture whose value is in the integration layer. MCP is what made that decoupling possible.

The Vendor Dynamics MCP Unlocked

MCP's adoption curve was not inevitable. There were several plausible alternative histories where a different protocol won, or where no protocol won and the market fragmented into model-specific integrations. Understanding why MCP specifically reached critical mass is worth a paragraph or two for anyone trying to understand analogous standardization moments in other parts of enterprise technology.

Anthropic released MCP as genuinely open. Not open-washed, not open with strings attached, not open in a way that reserved the best functionality for their own models. The protocol was released under a permissive license, with a reference implementation that worked identically regardless of which model was on the other side. This matters because enterprises have learned to be suspicious of "open" protocols that are actually vendor strategies. MCP was not that. Enterprises could verify it was not that. The credibility accrued quickly.

The initial tool implementations were credible. Anthropic partnered with a small group of vendors — Slack, Linear, and several developer-tooling companies — to ship production MCP servers at launch. Those early servers were good. They worked. Developers who tried them did not hit the "reference implementation is a toy, real implementation is impossible" problem that dooms many protocol launches. The bar for adoption by other vendors was visibly low.

The timing aligned with capability. MCP launched at the exact moment when agent-driven enterprise workflows were becoming reliable enough for production use. Enterprises that had been evaluating agent platforms in 2024 suddenly had a protocol that let them build without committing to a single vendor stack. The adoption pressure came from the demand side, not the supply side. Vendors implemented MCP because their enterprise customers were asking for it specifically.

Competitive dynamics forced adoption. Once Claude Cowork shipped with MCP-native integrations, enterprise customers started asking OpenAI and Google whether their products supported MCP. The answer "not yet" became a competitive liability. OpenAI announced MCP support in mid-2025. Google followed in late 2025. By early 2026 the protocol was universal across the major model providers, which meant vendors had no reason to implement any alternative.

The MCP adoption curve by model provider. Anthropic was at 100 percent from launch. OpenAI reached parity by Q4 2025. Google followed shortly after. By Q1 2026 essentially the entire market supported the protocol.

What MCP Unlocked For Enterprise Deployments

The strategic framing above matters, but it is worth being concrete about what specifically MCP made possible at the deployment level that was not possible before.

Before MCP, a Fortune 1000 company deploying an AI agent to do financial reporting work would face a deployment path that looked roughly like this. Three months scoping the integration with Workday, NetSuite, or SAP. One to two months per additional connected system (the spreadsheet platform, the BI tool, the CRM, the email system, the collaboration platform). Another month for security and compliance review of each custom adapter. Another month for end-to-end testing. Another month for pilot and evaluation. A typical deployment spanning seven or eight connected systems would consume nine to fifteen months before producing measurable business value.

After MCP, that same deployment looks different. The agent platform ships with MCP client support. Each connected system has an MCP server that has already passed security review from the vendor. Integration time drops from months-per-system to days-per-system. The deployment consumes two to four months rather than nine to fifteen. The compounding effect across many deployments is that enterprise-wide agent rollouts that would have taken three years can happen in twelve to eighteen months.

This is the infrastructure enabling the layoff patterns that are showing up in mid-cap tech company announcements. It is not that the underlying AI capability reached a milestone in isolation. It is that the AI capability reached a milestone at the same time as the integration layer reached critical mass. Both conditions together produced the deployment velocity that is driving the current displacement cycle.

The compression of enterprise deployment timelines from roughly 15 months pre-MCP to roughly 3 months with standardized MCP. The 5x compression is the leverage that turned a technically interesting capability milestone into an economically consequential one.

How MCP Actually Works Under The Hood

It is worth spending a section on the actual mechanics of the protocol, because the mechanics explain the adoption curve and predict the failure modes.

At its core, MCP defines three role types: clients (the AI agent or application making requests), servers (the tools exposing capabilities), and the transport that carries messages between them. The transport layer is flexible — implementations support JSON-RPC over stdio for local tools, over HTTP with Server-Sent Events for networked tools, and over WebSockets for tools that need persistent bidirectional communication. This transport flexibility was important for early adoption because it let vendors choose whatever transport fit their existing architecture without having to restructure.

Every MCP server exposes three primitives. Resources are read-only contextual data that the agent can request — a user's calendar, a database schema, a folder of documents. Tools are discrete operations the agent can invoke with structured arguments — creating a Jira ticket, running a SQL query, sending an email. Prompts are templated interactions that guide the agent through multi-step workflows — the vendor's recommended pattern for how their tool should be used in an agentic context.

The capability discovery step is what makes the protocol work at scale. When an agent connects to an MCP server, it asks "what can you do," and the server responds with a structured manifest of available resources, tools, and prompts. The agent can then decide at runtime which capabilities to invoke based on the user's request. This dynamic discovery is what removes the need for bespoke integration code. The agent does not need to know in advance what a specific server offers. It can find out, and it can adapt.

The authentication model supports OAuth 2.1, API key bearer tokens, and mutual TLS for enterprise deployments that require stronger guarantees. Permission scopes are negotiated at connection time, which means an agent connecting with read-only scopes cannot escalate to write operations without re-authenticating. The enterprise security community has spent two decades making this pattern well-understood in other contexts, which made MCP's adoption easier — the security architecture was already familiar.

The complexity-versus-friction map for MCP's core components. The protocol's success came from keeping all five components low-to- moderate on both dimensions. Protocols that fail tend to have at least one component that is very high on both axes. MCP does not.

The Historical Parallels That Predict Where This Goes

MCP's adoption curve is not unprecedented. Several prior infrastructure protocols have followed similar arcs, and looking at them tells us plausible things about where MCP goes from here.

HTTP (1991 onward). Tim Berners-Lee published the HTTP 0.9 specification in 1991 as a minimal protocol for retrieving hypertext documents. It was competing against Gopher, WAIS, FTP, and several other protocols with broader feature sets. HTTP won not because it was technically superior but because it was simple enough to implement in a weekend, well-documented enough to adopt without vendor support, and tied to an implementation (NCSA Mosaic, then Netscape) that rapidly became the default. By 1996 HTTP was the undisputed protocol of the web. By 2000 alternative protocols had effectively disappeared. The analogy to MCP is direct: a simple specification, a good reference implementation, and network effects that compounded quickly once critical mass was reached.

USB (1996 onward). USB started as a collaboration between Intel, Microsoft, IBM, and a handful of other companies to solve the proliferation of incompatible device connectors. The first version (USB 1.0) was slow and had real technical limitations, but the standardization of a single connector across most peripheral categories was so valuable that adoption was inevitable. Each successive version (USB 2.0, 3.0, USB-C) refined the implementation while preserving backward compatibility. MCP's likely trajectory includes similar version refinements over the next five years, with the core protocol maintaining compatibility while expanding capability.

OAuth (2007 onward). OAuth addressed a different but analogous problem: how to delegate authorization to third-party applications without exposing credentials. OAuth 1.0 was finalized in 2007, OAuth 2.0 in 2012, and the protocol became the dominant model for API authorization by 2015. The relevant parallel to MCP is the governance evolution — OAuth started as a vendor-led specification and migrated to the IETF for long-term stewardship. MCP has not yet made that transition but probably will before 2028.

REST (2000 onward). REST was an architectural style rather than a specific protocol, but its adoption curve is instructive. Roy Fielding's 2000 dissertation introduced REST as the architectural model underlying HTTP. For a decade it competed with SOAP, JSON-RPC, XML-RPC, and several other API paradigms. REST eventually won because it was simpler and more flexible, but the standardization was informal — there was no authoritative specification, no central body defining what REST meant. MCP has chosen a middle path: a formal specification with flexible implementation details, which seems likely to produce a cleaner maturation than REST achieved.

The common thread in each of these cases is that the protocol that won did so through a combination of technical simplicity, good timing, credible initial implementations, and an open governance posture that let early adopters feel confident committing to it. MCP has all four of those factors. The historical base rate for protocols in this position becoming durable winners is high.

How MCP Competes With Other Agent Protocols

MCP is not the only agent protocol that has been proposed in the last two years. It is the one that won, but the competitive history is worth understanding because it reveals what might challenge MCP's dominance from here.

OpenAI Function Calling. Predating MCP by roughly six months, OpenAI's function calling specification was the first major attempt at a standardized tool invocation protocol. It achieved significant adoption in 2023 and 2024 but was explicitly OpenAI-specific — the specification was tied to OpenAI's models and could not be used cleanly with alternative providers. This limitation became a competitive disadvantage once MCP arrived as a vendor-neutral alternative. OpenAI added MCP compatibility to its enterprise products in mid-2025 while continuing to support function calling for backward compatibility.

Google's Agent-to-Agent Protocol (A2A). Announced in early 2025, Google's A2A was an attempt to define a standard for agent coordination rather than agent-to-tool communication. The positioning was that MCP handled the tool layer and A2A would handle the agent collaboration layer. Adoption has been modest, partly because the problem A2A addresses is less pressing than the one MCP addresses, and partly because enterprise customers prefer not to commit to multiple emerging protocols simultaneously.

Microsoft's Semantic Kernel plugins. Microsoft's approach was to define an SDK-level abstraction rather than a wire protocol, aiming for tight integration with the .NET and Python ecosystems rather than vendor-agnostic interoperability. Semantic Kernel has healthy adoption within the Microsoft ecosystem but has not become a broader industry standard. Microsoft added MCP compatibility to its enterprise Copilot products in early 2026.

LangChain Tools and LangGraph. LangChain has a rich ecosystem of tool integrations that long predates MCP, and for a period in 2024-2025 LangChain's integrations were more mature than the equivalent MCP servers. That gap has been closing as MCP servers matured, and LangChain itself added MCP support so its tool ecosystem can be used via MCP-compatible clients.

The competitive landscape for agent protocols, scored on three dimensions. MCP has pulled clear of every alternative on vendor adoption and future momentum. The competitors are not disappearing, but the network effects are now firmly behind MCP.

The Hidden Risks of Protocol Concentration

There is a version of the MCP story that is entirely positive — standardization enables faster deployment, unlocks enterprise value, levels the competitive field between model providers. That version is mostly correct. But the complete picture includes some specific risks that enterprise AI buyers should be aware of as the protocol continues to entrench.

Dependency on Anthropic's ongoing stewardship. MCP is formally open and governed by a loose coalition of implementers, but Anthropic is the effective maintainer. If Anthropic's strategic interests diverge from the broader MCP ecosystem's interests, there is no clean institutional mechanism for the ecosystem to reclaim control. This is the classic open-governance problem that affects every successful open protocol. The Linux kernel eventually established governance independent of any single commercial entity. MCP has not yet reached that maturity level.

Security concentration. A single MCP server implementation vulnerability now exposes every agent that connects to that server, across every vendor. The surface area has grown enormously. The security community is beginning to pay attention, but the bug-reporting, disclosure, and remediation infrastructure is not yet at the maturity level needed for a protocol carrying this much enterprise traffic.

Permission and audit gaps. MCP's permission model is flexible by design, which means different servers implement permissions differently. Enterprise security teams trying to apply consistent least-privilege policies across dozens of MCP servers are discovering that the consistency is shallow — the same nominal permission can mean different things to different servers. This is producing a slow-burning compliance problem that will need protocol-level standardization to resolve properly.

Vendor-neutral governance of semantics. MCP defines a protocol for tool invocation, but it does not define a standard vocabulary for what tools mean. Two CRM vendors with MCP servers can expose "update customer record" operations that have subtly different semantics. Agents that work correctly against one server may fail silently against another. The protocol is the wiring. The semantic layer on top is still being built, and is where the next generation of integration problems will appear.

What MCP Does Not Solve

A complete assessment of the protocol requires being specific about the problems MCP does not address, because those problems are where the next generation of enterprise-AI infrastructure work is going to concentrate.

Long-running workflow coordination. MCP is a request/response protocol with streaming support, but it does not provide native primitives for workflows that span hours, days, or weeks. An agent that needs to kick off a job on Monday, check its status periodically through Thursday, and take action based on the result on Friday has to handle the durability and state management above the MCP layer. This gap has been filled inconsistently — some agent platforms bolt on workflow engines, others push the complexity onto the user — and will eventually require either a companion protocol or an extension to MCP.

Multi-agent coordination. When two or more agents need to collaborate on a task, MCP does not define the protocol for that collaboration. Google's A2A tried to fill this gap but has not achieved meaningful adoption. The multi-agent coordination problem is real and will become more pressing as enterprises deploy agent teams rather than solo agents. MCP's scope does not cover it, which is fine, but it means the next layer of infrastructure still has to be built.

Semantic consistency across vendors. MCP standardizes the wire protocol but not the vocabulary. A CRM from vendor A and a CRM from vendor B can both ship MCP servers that expose semantically different versions of "update contact." Agents that need to work across multiple CRM vendors have to handle the semantic translation themselves. This is the same problem that plagued SOAP-era enterprise integration, and MCP does not yet have a convincing answer to it. Industry-specific vocabulary standards layered on top of MCP will probably emerge over the next few years.

Pricing and metering. Commercial APIs usually have pricing models attached — rate limits, per-call fees, per-token charges. MCP does not define how that commercial layer works. Vendors are handling it idiosyncratically, which produces real operational friction for enterprise customers trying to manage agent spending across many tools. Expect an MCP-adjacent pricing metadata standard to emerge as the market matures.

Observability and tracing. Enterprise operations teams need to trace agent behavior across multiple tool invocations for debugging, compliance, and capacity planning. MCP provides enough hooks to build observability on top, but the observability tooling itself is not standardized. The early versions of the tools that do this are starting to ship, but the space is young and will consolidate over the next two years.

None of these gaps invalidate MCP's importance. They define the next generation of enterprise-AI infrastructure work that will sit on top of MCP. Companies and developers positioning themselves for the 2027-2029 wave of agent infrastructure should be paying attention to these gaps specifically, because they are where the next Anthropic-scale opportunities exist.

What To Do With This Understanding

For enterprise technology leaders reading this article, three takeaways are worth acting on in the next two quarters.

Audit your current agent deployments for MCP coverage. If you are running agent workflows against bespoke integrations rather than MCP servers, the long-run maintenance cost of those integrations is rising relative to MCP-native alternatives. A migration project to shift from custom integrations to MCP-based equivalents is often justified on a pure TCO basis, even ignoring the architectural benefits.

Negotiate MCP compliance into new SaaS vendor contracts. If a SaaS vendor you are evaluating does not yet ship an MCP server, the likelihood that they will by the end of 2026 is high — competitive pressure will force them. Contracts signed now should include MCP delivery commitments with specific timelines. This is one of the handful of specific contract terms where having leverage in Q2 2026 will pay off across multi-year vendor relationships.

Invest in internal MCP server implementations for your proprietary tools. Every enterprise has internal tooling that AI agents would benefit from reaching — custom data warehouses, internal apps, proprietary workflow systems. Building MCP servers for those tools has become the default integration strategy. Companies that build their internal MCP servers well will be able to deploy agent capability against their proprietary workflows at the same velocity as the external tools.

Consider where your own organization stands on MCP governance. If your company depends materially on MCP for its enterprise AI strategy — which, by the end of 2026, will be approximately every Fortune 1000 company — your interests are aligned with the broader MCP ecosystem staying open, well-governed, and secure. Participating in the governance conversations matters at the strategic level, even if the technical details are beneath the attention of most executives.

The Protocols That Shaped The Decades

In 1994, HTTP was a protocol that a small number of researchers thought was interesting and that the broader computing industry did not pay much attention to. Within three years it was carrying the commercial internet. Within ten it was the default for every application that touched a network. The specific technical details of HTTP became load-bearing for trillions of dollars of economic activity, and almost no one who benefited from those details ever needed to know how HTTP actually worked.

MCP is in the same position in 2026 that HTTP was in 1995. It is the protocol quietly carrying an economic transformation. The people building products on top of it are not writing think pieces about it. The people being affected by the consequences downstream of it do not know the protocol exists. The media coverage is minimal because the story is too technical for mainstream outlets and too boring for technical ones.

And yet, if you want to understand why the autonomous coworker transition is happening at the speed it is happening — why OSWorld-V parity translated into immediate enterprise deployment rather than multi-year integration delays, why mid-cap companies are able to restructure workforces within weeks of model capability milestones, why the infrastructure story and the capability story suddenly converged in Q1 2026 — the answer sits underneath every other story, in the quiet protocol that standardized the wiring before anyone was paying attention.

MCP at 97 million installs is the infrastructure announcement of the decade. Nobody will call it that. The people who understand why it is will have a noticeable advantage over the people who do not.

What Comes After Critical Mass

The last useful thing to note about MCP is that its trajectory from here is not a continuation of the current growth curve. It is a transition to a different phase of the standardization lifecycle.

Phase one — the phase that ends roughly now — is the race to critical mass, during which the protocol's value was proportional to how fast new vendors adopted it. Phase two — the phase starting now — is the maturation phase, during which the protocol's value shifts to how reliably, securely, and consistently the existing implementations perform. The vendors that invest in phase-two maturity will be the ones that capture the enterprise trust. The vendors that ship minimum-viable MCP servers and move on will see their implementations quietly displaced by competitors with better ones.

Phase three, which probably arrives in 2028 or 2029, is the governance and institutional consolidation phase. That is when MCP either develops the kind of vendor-neutral governance that HTTP did through the IETF and W3C, or fragments into vendor- specific dialects as commercial incentives pull different implementations apart. The work of getting to the first outcome rather than the second is mostly political, mostly tedious, and mostly invisible — which is to say, it is exactly the work that tends to get underinvested in during boom phases like the current one.

Whichever path MCP takes, it is now the load-bearing piece of enterprise AI infrastructure. The agent economy that is producing the Snap layoffs, the OpenAI enterprise pivot, the OSWorld-V milestone coverage, and everything else is running on top of it. Understanding the wiring is the prerequisite for understanding anything happening above it.

The protocol won. The implications are still arriving. Most of the people being affected by them do not yet know why things are happening as fast as they are. The answer sits at 97 million installs, in a specification that almost nobody reads, published eighteen months ago by a company that is now using it to reshape the economics of knowledge work.

That is the story under the story. It is worth paying attention to.