AI Didn't Reinvent Distributed Computing—It Finally Gave It a Purpose
AIARCHITECTURE
Every decade seems to produce one architectural idea that shows up before the rest of the ecosystem is ready for it. The idea gets the whiteboard diagrams right. It gets the pitch decks right. Then it runs into production, and the gap between vision and execution becomes impossible to ignore.
I first felt that gap when Microsoft introduced external tables and distributed querying. At the time, it felt inevitable. Data volumes were exploding, centralizing every dataset into a single warehouse was becoming impractical, and the promise of querying data wherever it lived—without moving it first—was exactly the kind of simplicity architects had been waiting for.
The idea was right. The execution wasn't.
When Distributed Computing Looked Like the Future
By the mid-2000s, enterprise data had outgrown what a single, tightly coupled database engine could reasonably absorb. Vertical scaling had limits. That pressure is what gave rise to the broader distributed computing movement—and to Microsoft's own answer, external tables, which let a query reach out to data sitting outside the database rather than demanding it be ingested first.
I saw the appeal firsthand on a project integrating an EHR system with a CRM platform. The goal was straightforward: give clinical and commercial teams a unified view without duplicating sensitive records across systems. Distributed queries looked like the obvious path—no ETL pipeline, no synchronization headaches, just query the data where it lived.
In practice, it didn't hold up. Every query triggered large volumes of data movement across the network. Execution plans were poor because the engine had no real visibility into the shape of the remote data. What was supposed to be the simpler architecture became, operationally, the harder one to run.
The problem wasn't the vision. The problem was knowing when the vision should be applied. The technology could execute the plan. It couldn't decide whether the plan was worth executing.
Cloud Solved One Problem but Revealed Another
Snowflake's arrival changed the equation. Its architecture separated storage from compute in a way that made distributed access to data dramatically more practical, and later its external tables feature—introduced in preview in 2019 and generally available in 2021—let organizations query data sitting in raw form in cloud object storage without first loading it into a proprietary format. That was genuine progress, and it's worth acknowledging as such.
But a new tradeoff emerged in its place. Performance improved. Cost became unpredictable.
I ran into this on a second project, another opportunity to skip a traditional ETL pipeline in favor of querying external data directly. And once again, the team pulled back toward conventional data movement—not because the technology failed, but because of cloud compute economics, the cost profile of external table queries, and a preference for operational predictability over architectural elegance.
The pullback wasn't really a technical decision. It was an organizational one.
Finance teams could budget for a fixed, scheduled ETL job. They could not easily budget for compute costs that scaled with query volume and data shape in ways nobody could predict in advance. Given a choice between an architecture that was elegant but variable and one that was clunky but predictable, most organizations will choose predictable every time—and the people making that call were architects and finance leaders, not the platform itself.
Looking back, the pattern is clear: we weren't avoiding distributed architecture because it didn't work. We were avoiding it because experienced architects understood the tradeoffs better than the technology did.
That realization raises the real question: what was actually missing?
The Missing Layer Was Never Infrastructure
Distributed systems have long been able to connect, scale, move data, and execute workloads across boundaries. What they couldn't do was reason about whether any of that was the right call in a given moment.
Every successful distributed architecture I've been part of still depended on someone who knew when not to distribute the work.
It's worth noting this isn't a new problem, either. Semantic layers and knowledge representation have existed in enterprise data for years, well before anyone was talking about AI in this context. What's changed isn't that semantics were invented—it's that something can now reason over them in ways that used to require a human in the loop.
This is where AI changes the conversation.
AI Changes the Consumer of Distributed Systems
None of the building blocks above are new. APIs, microservices, semantic layers, and external data access—including the PolyBase and Snowflake capabilities described earlier—have existed and matured for years. What AI introduces is a different kind of consumer for all of it.
Enterprises have had orchestration engines for a long time—scheduling tools, ETL frameworks, workflow platforms. Those systems are very good at executing a plan reliably. What they can't do is question the plan. A workflow engine runs the steps it was configured to run, in the order it was configured to run them, regardless of whether today's conditions still make that the right call. It has no opinion on cost, no sense of whether the data has changed shape, no ability to notice that a cheaper or faster path just became available.
That's the real distinction between orchestration and reasoning: one executes a fixed sequence, the other evaluates whether the sequence is still the right one before it runs.
One of the first places we're seeing this shift is agentic tool calling, where an AI system decides which external tool or data source to call based on the task in front of it, rather than following a step it was pre-wired to execute. The Model Context Protocol (MCP) is a good example of the plumbing behind this: a standardized way for an AI system to discover and call external tools and data sources, without getting too deep into the mechanics. The important part isn't the protocol itself—it's that the caller is now a reasoning system deciding whether and how to invoke something, not a fixed workflow executing a predetermined step.
Concretely, that means a system can start to weigh things a workflow engine never could: where computation should happen, what data actually needs to be retrieved, which service should be invoked, and whether the cost of running a given query is justified based on current conditions. Those are the same judgment calls the EHR/CRM project and the cloud cost tradeoffs above required from a person. It's worth being honest about where this stands today: most of this is still early and forward-looking rather than fully proven at scale. But the direction is already visible in how these tool-calling systems are being built, and that's a meaningfully different starting point than a static pipeline had a decade ago.
This pattern isn't unique to data platforms. The same shift is showing up in developer tooling, where coding agents decide which repository, service, or test suite actually needs attention, and in enterprise applications, where agents are beginning to choose which backend system should handle a request rather than following a hardcoded integration path.
Architecture Is Becoming More Dynamic
The implication for enterprise leadership is that architecture is shifting from designing every workflow in advance toward designing systems that can make informed decisions within defined guardrails.
That doesn't mean less governance. If anything, it demands more explicit governance, because the decisions being made dynamically still need boundaries: acceptable cost ranges, approved data sources, latency thresholds, compliance constraints. What changes is the nature of the architect's work. Rather than prescribing every execution path in advance, architects increasingly define the boundaries, the objectives, and the acceptable tradeoffs—and let the system operate within them.
Picture a query that needs recent transaction data. A workflow engine would run the one path it was configured to run. A system with this kind of judgment could instead weigh several options dynamically—read directly from an Iceberg table, pull from a cached warehouse copy that's a few hours stale, or invoke a downstream service—and pick based on how fresh the data needs to be, what it costs to run each option, and what governance allows for that particular request. The architect's job shifts from choosing the path to defining the guardrails the system chooses within.
This doesn't eliminate the architect. It changes where the architect adds value.
Conclusion
Some technologies fail because they're bad ideas. Others fail because they arrive before the missing piece exists. Distributed computing, at least in my experience, belongs to the second category. The engineering has been remarkable—predicate pushdown, columnar pruning, metadata caching, and now open table formats like Apache Iceberg have closed most of the performance gap that made early external tables so painful to operate. But performance was never the whole story. Judgment was the missing layer, not more infrastructure.
The organizations best positioned for AI may not be the ones with the largest models. They may be the ones that have spent years building the APIs, semantic models, cloud platforms, governance frameworks, and distributed capabilities that AI can now orchestrate intelligently.
That has a few concrete implications worth sitting with. APIs stop being plumbing and start being strategic assets—the more cleanly a capability is exposed, the more useful it becomes to something that can now reason about when to call it. In organizations where semantic models have been treated primarily as documentation overhead, they become something more: the thing that lets a reasoning system understand what your data actually means rather than just where it lives. And governance stops being a constraint bolted on after the fact and starts functioning as architectural infrastructure in its own right—the guardrails are now doing real work, not just paperwork. Enterprises that have quietly invested in these areas for years, without necessarily calling it "AI readiness," may find they're further along than they realize.
Perhaps AI's greatest architectural contribution won't be replacing the systems we've spent years building. It will be finally allowing them to work together the way we always imagined. The question worth carrying forward isn't whether AI is intelligent enough for that—it's whether our platforms are ready to be reasoned about at all.