On the Phase Change

J. Brodnax and Claude (Opus 4.7, Anthropic)
Engineering Notes, Volume 1, Issue 3
April 2026

Contents

1. The SharePoint Afternoon
2. What the Hours Actually Measured
3. Decisions as the Variable
4. The Sender-and-Receiver Illusion
5. Protocol History Rhymes
6. RPA Is the TCP/IP of AI Tool Use
7. Why Standardize Now
8. The Channel-Agnostic Bet

1. The SharePoint Afternoon

Moving seven million documents out of SharePoint and onto a disk, with their metadata rebuilt as a directory hierarchy at the destination, used to be an afternoon's work. Four to six hours, clearing the calendar, coffee, a notebook, and the resigned knowledge that the first two hours would not produce any documents at all — they would produce a working auth flow, a tolerable error handler, and a mental map of which of SharePoint's fourteen document types was about to behave strangely today. The actual file copies would not begin until the infrastructure around them had been assembled by hand, one scraped GitHub example at a time.

The same migration, last week, took under ten minutes. Describe the tenant. Describe the metadata. Describe the directory shape at the destination. Watch it run. Seven million documents, correctly organized, logged, checkpointed, resumable on failure. The ten minutes includes the conversation that produced the script.

This is not a productivity gain. A productivity gain is when you used to type eighty words a minute and now you type a hundred and twenty. The SharePoint migration is a different kind of thing entirely, and getting the shape of it right matters because most of the people writing about AI-assisted development right now are measuring the wrong variable. They are counting lines of code per hour. They are counting features per sprint. They are counting things that used to matter in a regime that has ended, and they are reporting disappointing numbers because the numbers they have chosen to measure have nothing to do with what changed.

2. What the Hours Actually Measured

If the migration used to take six hours, the six hours broke down roughly as follows. Perhaps twenty minutes of real work: the SharePoint API calls, the metadata mapping, the directory construction. Perhaps five hours and forty minutes of tax: finding a similar project on a code-sharing site, reading enough of it to trust it, cloning it, getting it to run locally, fighting the auth flow that was different in this tenant, discovering that the metadata schema had drifted, modifying, testing, failing, retrying. Some quiet swearing. A second coffee.

Every experienced engineer recognizes the breakdown. The interesting problem is always small. The tax around the interesting problem is always large. The entire software industry's "productivity tooling" layer, stretching back thirty years — package managers, boilerplate generators, code search engines, IDE autocomplete, stack-overflow-paste-buffers, the whole apparatus — has been a sustained effort to reduce the tax. Each tool has succeeded in reducing it somewhat. Not one has reduced it to zero.

What changed is not that the real work got faster. The real work was always twenty minutes. What changed is that the tax collapsed to nearly zero. A language model that has been trained on enough SharePoint migration scripts can write yours — against your specific tenant config, your specific metadata schema, your specific error-handling preferences — in the time it takes to describe the edge cases. It does not retrieve a similar script and adapt it. It writes the one you need, correctly, on first attempt.

The real work was always twenty minutes. What changed is that the five hours of tax collapsed to nearly zero.

This reframing matters because it explains a pattern that otherwise looks like either bluffing or delusion. When someone says "I built this in an hour," they are not claiming they typed faster than you, and they are not lying. They are reporting what it actually takes to do the work when the integration tax is gone. From the outside, the claim looks impossible; from the inside, it feels unremarkable, because the inside person is not doing anything clever. They are simply operating in a regime where the old overhead has disappeared.

3. Decisions as the Variable

The real consequence of the speed change is not the speed. The real consequence is that it changes what decisions can be afforded.

When a decision costs six hours to validate, decisions are batched. Meetings are held. Design documents are written. Stakeholders are consulted before commitments are made, because the cost of making the wrong commitment is large enough to justify the ceremony. This is not irrational overhead; it is rational behavior in a regime where undoing a decision is expensive. The entire apparatus of enterprise software governance — change advisory boards, architectural review committees, phased rollouts, release trains — is the visible surface of a culture that has learned, over decades, to be cautious with decisions because decisions were expensive.

When a decision costs fifteen minutes to validate, the rational behavior inverts. Batching is now more expensive than just running the experiment. Consensus is expensive to obtain and cheap to skip, because if the experiment fails, it fails in fifteen minutes and nothing has been committed. Meetings about whether to try the thing take longer than trying the thing. Design documents describing the approach can be written after the approach has been demonstrated to work, at which point they describe something real rather than speculating about something imagined.

An organization that tries to run its old governance cadence on the new decision cost drowns. Every attempt to ship something fast collides with the review process; every review takes longer than the thing being reviewed; the review process is structurally incapable of operating at the pace the tools now permit. From the inside this feels like chaos. From the outside it looks like the organization is slow for no reason. Both perceptions are correct, and neither of them identifies the actual problem, which is that the governance layer was calibrated for a decision cost that no longer applies.

The companies that move fastest in the next few years will not be the ones with the best AI tools. The tools are roughly the same everywhere. The fast companies will be the ones whose governance layer has absorbed the new decision cost — where a commit, a merge, a deploy, a schema change, a user-facing feature can all happen at something close to the speed at which the AI can produce them, because the organization has built arbitration mechanisms that run at that speed. The slow companies will have the same tools, and their engineers will watch their output get strangled by the review cycle, and the leadership will hire more process consultants, and the companies will lose to competitors whose engineers are not being strangled. This is already happening; it will accelerate.

4. The Sender-and-Receiver Illusion

Against this backdrop, the second-most-common error in the current discourse is worth naming, because it is load-bearing for the protocol-standards argument in the second half of this essay.

Most AI coding demonstrations are closed-loop. The model writes an emitter. The model writes a consumer. The model specifies the schema between them. Everything works perfectly, because one statistical mind produced all three parts and, naturally, its three parts agree with each other. The demonstration looks like a dialogue between systems; it is in fact a monologue presented as a dialogue.

The closed-loop demonstration is useful — it shows that the model can carry a coherent design through multiple files and multiple languages — but it is systematically misleading about what happens at integration time. The moment the emitter has to talk to something the model did not write — a partner's API, a vendor's service, a regulator's validator, a user's unexpected browser, an organization's existing auth layer — the reality of protocol design reasserts itself. The schema drifts. The version changes. A field that was optional last month becomes required this month. A capability that was hardcoded becomes negotiated. An encoding that was UTF-8 becomes something the sender swears is UTF-8 but actually contains a single smart quote in a document from 2003. All the classical network-engineering problems return, and they return to engineers who mostly did not learn to think about them, because the frameworks of the last twenty years papered them over.

The engineers who did learn to think about these problems — the ones who came up through network programming, through protocol engineering, through the long education in Postel's Law[1] and the end-to-end principle[2] and version negotiation and forward-compatibility — have a considerable advantage in the AI-integration era, and the advantage is not going to be obvious to anyone who lacks the background. Writing code that correctly emits a valid message is one problem. Writing code that correctly emits a valid message across a trust boundary to a receiver you did not write and cannot update is a different problem, and it is the one that matters for anything beyond demonstrations.

5. Protocol History Rhymes

The current discourse around AI communication protocols is having a conversation that networking engineers can recognize from three previous iterations, because the industry keeps rediscovering the same lesson.

In the early 1990s, the local-area-network world argued over whether IPX, ATM, Token Ring, or TCP/IP would become the universal interconnect standard.[3] The technical case for several of the non-TCP candidates was serious. ATM promised guaranteed quality-of-service at the cell level, genuine advantage for voice and video. IPX had a smaller protocol stack and simpler configuration. Token Ring offered deterministic latency bounds that Ethernet could not match. TCP/IP was in several objective ways the worst choice. It also became the universal standard, and the reason it became universal is instructive: it was the one that already ran everywhere, was dead-simple to understand at the packet level, and asked nothing from its adopters beyond a willingness to tolerate a certain amount of ugliness.

Ten years later, the web-services world had the same argument about SOAP versus REST.[4] SOAP was the elegant, negotiated, strongly-typed, enterprise-approved protocol. REST was a doctoral dissertation about HTTP that amounted to saying "just use the verbs that already exist." REST won, because every machine in the world already spoke HTTP, and adding SOAP required learning a new envelope format and a new service descriptor and a new discovery mechanism for the privilege of doing the same thing more slowly.

A decade after that, the mobile-application world had the argument again, in the form of native SDKs versus mobile web.[5] The native SDKs were faster, richer, and more capable. The mobile web was uglier, slower, and more limited. The mobile web won roughly half the market because it shipped everywhere without asking permission, and the half it lost it lost for specific reasons at the capability ceiling, not because the platform was inferior in kind.

The pattern is stable enough to warrant a name. In each case, a technically superior, negotiated, vendor-blessed protocol lost to a technically uglier, already-deployed, universal one. The uglier one required no cooperation from the target; the negotiated one required installation, adoption, and buy-in. When the cost of cooperation exceeds the benefit of elegance, elegance loses. Every time. This is not a rule about taste. It is a rule about where the deployment friction sits, and the party that gets to ignore deployment friction wins.

The dumb universal protocol has beaten the elegant negotiated one at least three times in living memory. It is about to do it again.

6. RPA Is the TCP/IP of AI Tool Use

Which brings us to the AI-protocol standards conversation currently underway.

Several serious efforts have been published or are in active development: Anthropic's Model Context Protocol,[6] OpenAI's function-calling schema, Google's agent-protocol work, the W3C WebMCP proposal,[7] and a handful of vendor-specific tool-description languages. The pitch for each is essentially the same: a structured, typed, efficient channel for AI-to-application communication that is dramatically better than having an AI fumble at a user interface.

The pitch is correct as far as it goes. A structured protocol is faster, cleaner, more deterministic, and easier to audit than having a language model click through a user interface. If you have the budget to implement it on both sides of the connection and the leverage to make your partners implement it too, the structured protocol is the superior design.

The problem is that, in late 2025 and early 2026, a different capability became broadly available: AI systems that can drive existing user interfaces through accessibility APIs and screen interpretation, at something approaching human parity, with zero cooperation required from the target application. Apple Intelligence ships this capability on macOS. Anthropic's Computer Use tool demonstrated it. Microsoft's Copilot Studio is shipping variants. The capability has a name that used to be slightly embarrassing in enterprise contexts — robotic process automation, or RPA — and now has been absorbed into the default operating model of every major AI platform.

This changes the economics of the protocol-standardization conversation in a way that most of the people having the conversation have not yet fully absorbed. The old argument was: a protocol is more efficient than an AI fumbling at the UI, therefore vendors should adopt the protocol. The new argument, from the vendor's perspective, is: the AI can drive my existing UI for free, without any engineering effort on my part, and the protocol adoption would cost me engineering cycles for a marginal efficiency gain. The vendor's math has flipped. The efficient protocol is no longer being compared to the ungovernable absence of any channel; it is being compared to RPA-through-the-existing-interface, which is already deployed, requires no adoption, and governs itself through the same authentication, audit, and ACL machinery the human user is already subject to.

This is the TCP/IP moment, exactly. The dumb, ugly, universal option — click the button that is already on the screen — has zero deployment friction and near-complete coverage. The elegant, efficient, negotiated option requires vendor buy-in that most vendors now have reduced incentive to provide.

7. Why Standardize Now

It is worth listing the reasons a standardized AI-communication protocol might still be worth building, because several of them are real, and the honest answer matters for anyone deciding where to spend their engineering attention.

Performance-critical tight loops. RPA through screen interpretation has round-trip latencies measured in hundreds of milliseconds. For most tasks, this is invisible. For high-throughput data pipelines, real-time control systems, or any loop where the AI needs to make thousands of decisions per second against a single target, the latency cost is prohibitive and a structured protocol earns its keep. This is a real but narrow category.

Headless server-to-server communication. When there is no user interface to drive, RPA is not an option. Server-to-server AI communication needs a protocol because there is no alternative. This is a legitimate category, though it is usually better served by the existing API-design toolkit — HTTP, OpenAPI, gRPC — extended with AI-friendly conventions, rather than by a wholly new vendor-specific protocol.

Richer semantic intent transfer. A structured protocol can carry intent more precisely than a sequence of clicks. The AI does not say click button 247; it says I want to archive this record, and the application chooses the implementation. When this works, it is a superior pattern. The question is whether vendors will implement it once RPA provides an adequate fallback. The evidence from previous protocol wars suggests most will not.

Platform control and rent collection. The less-discussed reason for the current flurry of protocol proposals is that protocols confer influence. Owning the protocol that becomes the standard means owning the implementation registry, the versioning cadence, the extension points, and — in the limit — a recurring economic position. Much of the energy behind the current AI-protocol work is this, dressed up in performance language. This is worth naming honestly, because the technical claims made in the service of this goal can be evaluated against their merits only if the goal is visible.

These four categories are the legitimate remaining use cases. They do not add up to a universal protocol. They add up to a niche protocol for specific high-performance scenarios, alongside an RPA-as-default fallback for everything else. The industry will probably converge on this split, the same way it converged on TCP-for-everything-plus-specialty-protocols-for-niches. The difference is that the specialty protocols this time may be proprietary rather than open, because the rent incentive is high enough to keep them that way.

8. The Channel-Agnostic Bet

Which leaves a design question for anyone building systems that have to accommodate AI callers, and the answer does not look like picking a protocol.

The durable position is to assume that AI will arrive through whatever channel is convenient at the moment — structured tool-call, RPA, webhook, chat, future-channel-not-yet-imagined — and to build the security, audit, and governance layers so they operate on the calling pattern rather than the calling protocol. What the caller asked to do matters. How they encoded the asking does not. A permission check that works only on one protocol's payload shape is going to be the weakest point in the system within eighteen months.

This is the design stance StoneForge has taken, and it was arrived at for different reasons than the protocol-standards analysis just given. The original motivation was simpler: building separate governance pipelines for every possible channel is obviously untenable, so there must be one pipeline, and the pipeline must accept messages from any channel that knows how to describe itself. The chmod-style ACL that appears in CRUD+ is not a theoretical preference; it is the simplest primitive that survived contact with this requirement. Bitsets compose across channels. Role hierarchies do not.

If the protocol-standardization analysis in this essay is right, the channel-agnostic stance will look like foresight in retrospect. If it is wrong, it will look like a reasonable design choice that happens to accommodate multiple channels anyway, which is also a fine outcome. The bet has positive expected value in every plausible branch of the future, which is roughly the test that should be applied to any foundational design choice.

The broader observation, which is really the reason this essay exists, is that the industry is about to spend several years relearning lessons that networking engineers settled in the 1990s, lessons that web-services engineers settled in the 2000s, and lessons that mobile-platform engineers settled in the 2010s. The lessons do not change. The dumb universal interface beats the elegant negotiated one. The protocol that asks for nothing beats the protocol that asks for adoption. The layer you should invest in is the one that sits above whichever protocol wins, because betting on the protocol is betting on the coin flip, and betting on the layer above is betting on the fact that there will be a layer above no matter which way the coin comes down.

The speed change and the protocol-history lesson are, in the end, two sides of the same observation. The speed change is what happens when the cost of running an experiment collapses. The protocol-history lesson is what happens when that collapse has occurred enough times that certain patterns become visible. You do not have to pick the winning protocol. You have to position yourself so that the protocol is not the thing you are betting on. The organizations that understand this are going to operate at a different speed than the ones that don't, and the speed gap is going to compound.

Related Reading

This is the third essay in StoneForge Engineering Notes. The earlier pieces lay out the protocol and the decision discipline referenced above.

On Convergence (Issue 2) On Starting with an RFC (Issue 1) CRUD+ Whitepaper RFC SF-004

J. Brodnax and Claude
April 2026

References

1. Postel, J., "Transmission Control Protocol," RFC 793, September 1981. The robustness principle — "be conservative in what you send, liberal in what you accept" — appears in §2.10 and is one of the most cited design maxims in the history of network engineering.
2. Saltzer, J. H., D. P. Reed, and D. D. Clark, "End-to-End Arguments in System Design," ACM Transactions on Computer Systems, 2(4), November 1984. The canonical argument that application-level concerns should not be pushed down into the network layer.
3. Abbate, J., Inventing the Internet, MIT Press, 1999. The historical account of how TCP/IP displaced the alternatives, with particular attention to the deployment-friction argument.
4. Fielding, R. T., "Architectural Styles and the Design of Network-based Software Architectures," Ph.D. dissertation, University of California, Irvine, 2000. Chapter 5 defines REST; the subsequent industry reception is documented extensively in the IETF and W3C archives.
5. Charland, A. and B. Leroux, "Mobile Application Development: Web vs. Native," Communications of the ACM, 54(5), May 2011. A contemporaneous snapshot of the native-versus-web argument at its peak.
6. Anthropic, "Model Context Protocol Specification," November 2024. Available at https://modelcontextprotocol.io
7. W3C Community Group, "WebMCP: Model Context Protocol for the Web," draft specification, 2025. The proposal to expose application capabilities to AI callers via standardized HTML attributes and a navigator.modelContext API.
8. Brodnax, J., Ed., "CRUD+ Protocol: A Cell-Based Standard for Governed Data Emission in Agent-Native Systems," RFC SF-004, StoneForge Working Group, April 2026. The channel-agnostic governance pipeline referenced in §8.