The Agentic Stack Wars: Part Two - ARCHITECTURE
Same Stack, Different Hoodie. Every AI agent vendor is building the same architecture we invented decades ago. The only real question is where they want to own YOU.
This is Part 2 of a four-part series that I will be publishing over the course of a week. It provides advice about how the agentic stack is being managed and positioned by the major vendor players in the Agentic Stack Wars. Please keep watching your inbox for the next two parts, or start with Part 1: CONFESSION
If you have spent any time reading product announcements on agentic AI from the major players lately, you are probably suffering from a particular kind of fatigue. Not information overload exactly. More like being told repeatedly that everything is new and innovative, everything is revolutionary, and each vendor has invented a fundamentally different future of work.
They have not.
Strip away the landing page language from Google Gemini Spark, Perplexity Computer, Microsoft Copilot Studio, and Anthropic’s Claude Cowork/Code, and what you find underneath is the same five-layer architecture that anyone who has been building enterprise software systems for the past few decades will recognize immediately. (I made the same case a few weeks back about the term harness engineering:
Horse of a different color?
A few weeks ago, I suddenly noticed a word turning up everywhere I looked.
But what I see is, the competitive battle being fought right now is not about who invented the better paradigm. It is about who gets to own which element of a stack that is (architecturally at least) not new at all.
Understanding that stack is probably the single most useful thing you can do before committing budget, workflow, or institutional dependency to any of them.
Act One: The Stack
Every serious AI agent operating today is built on the same five-layer blueprint. The marketing is different. The architecture is not.
Layer One: The Data Layer
This is the foundation — the personal, corporate, or accessible knowledge store that grounds what the agent actually knows. Without this layer, the agent is reasoning in a vacuum, and the outputs reflect that. The quality, accessibility, and governance of your data at this layer determines the ceiling of what any agent built on top of it can actually deliver. This is also, not coincidentally, the layer where the deepest vendor lock-in tends to accumulate.
Layer Two: The Orchestrator
This is the planning brain. The model or system that takes your ambiguous high-level goal and maps out how to execute it. It interprets intent, sequences tasks, decides what tools to invoke, and manages the logic flow across everything else. Every vendor has one. They all call it something a little different.
Layer Three: The Connectivity Layer
This is the bridge between the orchestrator and the rest of your world — the APIs, MCP servers, native connectors, permissions, and identity controls that let the agent reach into other systems and do something useful.
This layer splits into two distinct flavors: the vendor-managed ‘orchard’ of pre-built native connectors, and the open bridge of custom-configured developer integrations. Your choice of vendor determines how much of this layer you inherit by vendor choice versus how much you have to build and maintain yourself (often with yet another toolset).
Layer Four: The Action Layer
Once the orchestrator has a plan and the connectivity layer has cleared the path, the system spawns sub-agents, tools, “scripts”, and background processes to execute the actual tasks. This is where the work happens.
It is also where things break in interesting and expensive ways when the layers below it are not properly governed.
Layer Five: The Compute
Where does the master program (and, depending on the vendor, many of the subagent and tool actions) actually live, burn compute cycles, and eat storage?
This is the layer that most buyers underestimate, and most vendors deliberately obscure in their marketing. It determines how much of your agentic execution runs on your own iron versus someone else’s infrastructure — and therefore how much control you retain over cost, continuity, and terms when the vendor decides to change them.
The honest picture is a spectrum rather than a binary. Google and Microsoft are fully cloud-native by design and by commercial instinct. That’s their core business, and they have no reason to apologize for it.
Anthropic and OpenAI are in active transition, more locally tethered today but moving steadily toward persistent cloud execution, with features like mobile-to-desktop workflow initiation already changing the practical reality for users.
In the prosumer market, Perplexity occupies its own lane for now. Genuinely cloud-executed without demanding ecosystem submission. The direction of travel for all of them is the same. More of your work, running on their infrastructure, on their terms, at their price.
The Four Vendor Bets
The vendors are not selling different architectures. They are making different bets about which layer to own, and what kind of dependency or friction they want to create for the customer in the process.
Google: Submit to the Machine
Google’s strategy is straightforward and should be obvious to anyone who has watched them operate for the past twenty years. They want to be the central switchboard. Gemini Spark runs entirely off-machine in an ephemeral cloud VM — your agentic workflows live in Google’s infrastructure, grounded in Google Workspace data, connected through Google’s growing ecosystem of native MCP connectors to third-party enterprise platforms.
The execution is genuinely frictionless if you submit. The 24/7 background operation is real. But so is the lock-in. Every workflow you build inside Spark increases the gravitational pull of the Google ecosystem and makes the exit conversation harder.
That is not an accident. That is the strategy.
Microsoft: Governance as the Product
Microsoft is not really selling an AI agent. They are leveraging their long developer and engineering experience in Copilot Studio but the orchestrator and action brain power in reality is buried in corporate partnerships. They were all about CHatGPT buried underneath Copilot, now Claude is also churning under the covers. You don’t so much get a choice as it’s all wrapped up in copilot but that’s their bet.
What they are REALLY selling is a governance framework with an AI agent inside it. Copilot Studio is built for environments where improvisation is a liability and auditability is a compliance requirement.
The data layer demands structured mapping to Microsoft Graph or relational databases. The connectivity layer is a hybrid — a massive pre-built Power Platform orchard for anything inside the O365 boundary, and a significant configuration and maintenance burden the moment you step outside it.
Once assembled, these agents run as permanent server-side cloud services on Azure. The target buyer (often corporate) is not looking for intelligence at any cost. They are looking for control, and Microsoft has correctly identified that there is an enormous institutional market for exactly that.
Anthropic and OpenAI: The Intelligence at Your Desk
Lacking the legacy cloud infrastructure gravity of Google or Microsoft, both labs have made a different bet. Their bet is that they are best served if raw model capability and the immediate desktop experience win.
The grounding is context-window centric, relying heavily on what you feed into the active session. The connectivity layer leans into custom developer bridges and open-source MCP configurations. And the runtime is (currently) hardware-tethered. The orchestrator often needs an active live session on a local machine. Close the laptop, pause the work.
This is a real limitation, and they both know it.
It will change.
But that current constraint shapes who these tools work best for right now — people who are present, engaged, and running high-bandwidth intellectual work in active sessions rather than delegating background operations to a persistent cloud process.
Perplexity: The Interesting Middle Ground
Perplexity is the genuinely unusual case in this landscape for the prosumer and is worth understanding on its own terms.
They don’t own a legacy cloud ecosystem. They also do not have a family of foundational models to protect. What they have is an exceptional search infrastructure, a model specifically tuned for agentic orchestration rather than general conversation and subagent behaviors, and a cloud execution environment that does not require you to live inside their ecosystem to use it.
Their multi-model commitment is real. Perplexity will route to whichever of the other frontier models is best suited to the task at hand, which is a meaningfully different philosophical position from the vendors who need you on their model to make the economics work. Their execution runs off-machine in a cloud sandbox without the Google or Microsoft demand for ecosystem submission.
The question is not whether the product is interesting. It clearly is, and it will find its users. The question is whether an independent player can hold that lane against the two ‘gorillas’ with essentially unlimited infrastructure capital and the two ‘chimps’ with rapidly deepening pockets and loyal developer communities.
There are two possible endings to that story. One involves Perplexity winning a durable independent position in the market. The other involves an acquisition conversation. Business execution will determine which one it is.
Summary
Every one of those five layers costs money. The more of them you hand to someone else’s cloud, the less control you have over what that bill looks like when the terms change. Which is why the five buyer archetypes below exist — and why the last one among them will never, ever go away.
Act Two: Who Are You in This Landscape?
The architecture is the same across all of them. The vendor bets are different. But the most important variable is neither of those things.
It is you!
It doesn’t matter if that’s your singular, you the company, or you the corporation. What matters is:
Your operational reality;
Your tolerance for dependency;
Your technical capacity and;
What you are actually trying to accomplish.
There are five recognizable archetypes in this buyer landscape. Most people reading this will find themselves in one of them, or uncomfortably straddling two.
The Concentrated Operator
You have already made your ecosystem bet. Your organization runs on Google Workspace or Microsoft 365, your data lives there, your people work there, and the friction cost of operating outside those walls is real.
For you, the cloud-native agentic tools from Google or Microsoft are not a lock-in risk to be managed — they are the logical next layer of an infrastructure you already own. The decision is not which ecosystem.
The decision is how fast to deepen the integration, how to govern the usage costs that will follow, and whether your procurement process can keep up with a pricing model that is changing quarterly
The Sovereign consultant
You operate across multiple client environments, none of which belong to you. Your stack is fluid by necessity — you work inside your clients’ Salesforce instances, their SharePoint, their Jira boards, their proprietary systems.
A vendor that demands you live in their ecosystem is a vendor that immediately creates friction with half your client base. What you need is genuine platform independence, best-of-breed model routing, and execution that does not require you to reconfigure everything when you move between engagements.
Perplexity’s model-agnostic orchestration is genuinely interesting for this profile. So is a carefully configured open-source setup if you have the technical appetite for it.
The Process Architect/Operator
You are not looking for intelligence. You are looking for reliability. Your organization has high-stakes, highly repetitive workflows — compliance processes, regulatory reporting, structured approval chains — where an AI that “figures it out” is a liability rather than an asset.
You need deterministic behavior, auditability, and a governance framework that your legal and compliance teams can actually sign off on. Microsoft Copilot Studio was built for you, and the configuration burden is the price of the control you require. The risk is not that it will not work. The risk is underestimating the implementation cost before you are genuinely live.
The Active Developer Maker
You are present, engaged, and running complex intellectual work in active sessions. Research, writing, analysis, code, strategic synthesis — work that benefits from a high-bandwidth thinking partner right there on the screen, not a background process filing reports while you sleep.
The hardware-tethered limitation of Anthropic and OpenAI’s current desktop implementations is not a dealbreaker for you because the work you are doing requires your active presence anyway. The risk for this archetype is not the current limitation.
It is the temptation to build workflow dependencies on a runtime model that will change as both labs move toward persistent cloud execution — and the assumption that the pricing will stay where it is when that happens.
The ‘Morgan Car’ Builders
You know who you are.
You are not looking for a polished corporate subscription. You want the ‘build credit’, architectural transparency, and the ability to understand every component of what you are running. You are driven by some combination of intellectual satisfaction, ideological objection to vendor lock-in, a genuine need for capabilities that the mainstream tools do not offer, and the very reasonable suspicion that the pricing trajectory of the corporate platforms is going to get ugly.
You scavenge the ecosystem. Open-weight models. Local vector databases. Custom Python bridges. Terminal configurations that would make a normal IT department’s eyes water and Information security squirm. You will always find the cheaper, faster, home-brewed alternative to whatever enterprise vendors charge.
The honest assessment of this archetype is that a small number of Morgan Car Builders produce something genuinely extraordinary and beautiful. But it doesn’t scale. It’s often a unit of one or ten. The majority eventually reach the point where the infrastructure maintenance burden outweighs the benefits of independence and quietly migrate to a managed platform, telling themselves it is temporary.
The archetype never disappears, though. Every wave of corporate pricing pressure sends a fresh cohort back to the garage.
Summary
The vendors will keep announcing ‘revolutionary’ paradigms. The underlying architecture will remain the same five layers it always has been.
The useful question has never been which vendor has the best demo or set of features. It has always been which layer you are willing to let someone else own, and what the bill looks like when they decide to change the terms.
That sounds like a warning, and it is one. But it is also the most useful map you will get all year, because once you can SEE the five layers, you can see which ones actually hold you and which only feel like they do.
The model is the layer everyone fixates on, and it has suspects that it has the weakest grip of the lot. I predict models for most tasks and workflows will commoditize, and the prices will stabilize; you will be able to swap one for another in an afternoon.
What actually binds you sits lower and quieter: your data, the integrations wired around it, the governance laid over the top. And underneath even those, the layer that this whole article keeps circling — the runtime compute. Whose machine does the work run on, and what happens when the terms change?
Keep those layers portable, or keep them yours outright, and let the model be the rented part. The model is ultimately the part that is safe to rent.
So before you sign anything, ask the unglamorous question almost nobody asks early enough: how hard is it to leave each layer, and how much of it can I take with me when I go? That one question tells you more than any demo ever will.
And it reads the same from the other side of the table, just inverted. If you are the one building and selling agentic solutions, do not stake the business on the model layer, where the margin is already draining away in a price war you cannot win.
Build where the value dependency actually forms. In the data gravity and integration, your customer cannot easily rebuild, and you end up on the same solid ground they are. That is the only kind of stickiness that survives changes to features and terms, which they always do.
In the end, don’t let the Agentic stack be a cage. It is a map of where you should plant your feet as you navigate the ground.
Keep haverin’.
SM
The Agentic Stack Wars — the full series:
Part One — Confession: Google (Finally) Just Said The Quiet Part Out Loud
Part Two — Architecture: Same Stack, Different Hoodie (this article)
Part Three — Extraction: Your AI Budget Is Already Wrong (Coming June 4)
Part Four — Reckoning: The AI Free Lunch Was Always a Fairy Tale (Coming June 6)
The five layers have different lock-in mechanisms and they are not equally durable.
Data layer lock-in is inherited from existing platforms like Snowflake or Databricks. The agent vendor does not create it, they just attach to it.
Connectivity lock-in is weaker where protocols like MCP are adopted, because standardisation pushes that layer toward portability, though proprietary connectors and permission models still create friction.
The durable bet is orchestration, where lock-in is earned through workflow dependency. Teams build policies, audit rules, and agent logic around an orchestrator's abstractions, and that is genuinely hard to unwind.
Vendors fighting over connector counts are fighting for margins. Vendors competing on workflow stickiness are competing for the next decade.