In the Headless Era, Where Does Pincered Value Collect? — Vertical Compression of the Builder Layer

When the Builder’s Seat Narrows from Above and Below

The Part 1 picture was the commoditization of the canvas alongside the explosion of the market. The container thins; the automation market grows roughly 4× over five years. Part 2’s picture was that even when code agents move into the empty seat, no-code doesn’t die. The more probabilistic generation rises, the more the value of deterministic scaffolding rises with it. The builder relocates as the execution-governance layer for agents and survives.

Part 3’s question goes one layer deeper. What happens when the seat the builder occupies starts narrowing from above and below at the same time?

From above, hyperscalers (AWS, Azure, Google Cloud) are pushing agent runtimes down into infrastructure primitives. From below, frontier labs (OpenAI, Anthropic, Google DeepMind) are absorbing builder capabilities into their chat interfaces. What’s interesting is that this pincer is not an abstract trend — it’s the accumulation of concrete events between October 2025 and April 2026, a seven-month window. The space the builder occupies narrows from both sides.

Part 3’s one-line thesis:

The builder layer compresses vertically, and value shifts to the layer above it — custom ops assembly and the defensibility created by data exhaust.

Now look at the three positions — above, below, middle — in turn. What pressure descends from above, what pressure ascends from below, where does the builder layer get pushed, and at the new place where value settles, what stays defensible?

Pressure From Above — Hyperscalers’ Upstream Integration

The strongest signal is that AWS, Microsoft Azure, and Google Cloud — three hyperscalers — pushed agent runtimes to GA (General Availability) within the same six months. All three pushed the bundle builders used to sell down into infrastructure primitives.

Platform	GA Date	Core Capabilities
AWS Bedrock AgentCore	October 13, 2025	Runtime, Memory, Gateway, Identity, Code Interpreter, Browser, Observability, Evaluation, Policy
Azure AI Foundry Agent Service	November 2025	M365 integration, one-click Teams deploy, 10,000+ customers before GA
Google Vertex AI Agent Engine	Q1 2026	Gemini integration, Vertex Pipelines linkage, enterprise SLA

What the three platforms share, once you summarize it — nearly the same bundle builders used to sell. Runtime, memory, identity, governance, observability. The core of the builder’s value proposition is now a default capability of cloud infrastructure.

AWS Bedrock AgentCore — Twelve Pay-As-You-Go Components

AWS shipped the thickest, most explicit bundle. AgentCore’s core services consist of nine pieces.

Runtime — agent execution environment, session isolation. Priced at $0.0895 per vCPU-hour + $0.00945 per GB-hour by active CPU usage + peak memory.
Memory — short-term context and long-term knowledge store.
Gateway — authentication and routing for tool/API calls.
Identity — which agent acts on behalf of whom with what permission.
Code Interpreter — sandboxed code execution.
Browser — cloud browser for web manipulation.
Observability — logs of every call and result.
Evaluation — agent performance and accuracy measurement.
Policy — policy engine running outside the agent. Priced per authorization request at $0.000025.

Map this bundle to what builders called “our unique value” in Parts 1 and 2 and the overlap is nearly one-to-one. n8n 2.0’s sandboxed code execution, persistent memory, and data sovereignty correspond directly to AgentCore’s Code Interpreter, Memory, and Identity. What builders advertised as differentiation has descended one layer to infrastructure primitive.

One signal worth flagging is AgentCore’s expansion velocity. On May 11, 2026, AgentCore added Payments (Preview) — Coinbase CDP and Stripe Privy wallet integration, letting agents directly handle payments and transfers. Coinbase CDP runs at $0.005 per wallet operation. The infrastructure is building out the trajectory where the agent’s action surface extends from SaaS calls to payments and real-world transactions — first.

The first six months of AgentCore adoption show how directly this competes with builder SaaS.

CloudZero (FinOps platform) — built a cloud cost optimization agent on AgentCore. Migrated off prior builder tools.
Apex Fintech Solutions — moved financial crime investigation workflows onto AgentCore. Infrastructure-level isolation was decisive in a strong-compliance environment.
Genpact — built the riskCanvas® Data Explorer solution with agent-to-agent communication patterns. Adopted because multi-agent orchestration came as an infrastructure primitive.
Reply + Totemia — Reply partnered with Totemia, a French childhood vacation camp matching platform, to build an Offer Agent on AgentCore. Using AgentCore Runtime + Gateway + Memory, the agent narrows 60 options down to 5–10 tailored recommendations for Totemia’s 30,000 monthly users. Search time down 65%, bookings up 40%, conversion up 25%, projected first-year ROI 200–300%.

What these four share — they connected directly to AgentCore without a builder SaaS in between. Totemia’s 30K MAU Offer Agent could have been built on top of Zapier or n8n, but they chose AgentCore for infrastructure isolation, scalability, and SLAs. As this pattern repeats, the builder SaaS’s middle position narrows.

Azure AI Foundry — 10,000+ Customers Before GA

Microsoft creates a different kind of pressure. 10,000+ customers were already secured before GA when the product officially launched. One-click Teams deploy looks like a soft feature, but it has outsized effect. For organizations where employees already use Microsoft 365, there’s less reason to bring in a separate builder SaaS.

Azure AI Foundry combines two assets. One is Azure infrastructure’s isolation/compliance — VPC, Private Link, regional data residency. The other is M365 data/identity — the user already has a Microsoft account, and SharePoint/Outlook/Teams data lives in one place. Combine the two and you get an agent environment where identity, data, and execution all live inside one account. For a builder SaaS to deliver the same bundle, it has to plumb separate SSO, data sync, and identity mapping.

The UX advantage builders used to own — one person visually builds a workflow and deploys it immediately — becomes equally possible inside Microsoft’s ecosystem. And governance and audit sit beneath, provided as infrastructure primitive.

Google Vertex AI Agent Engine — Bound to Gemini

In Q1 2026, Google officially launched Vertex AI Agent Engine. Deep integration with Gemini models and linkage to Vertex Pipelines (Google’s existing ML pipeline infrastructure). Later than AWS and Azure in timing, but native attachment to Workspace data (Google Docs, Sheets, Gmail) is the key.

The fact that three hyperscalers pulled the same bundle into GA within the same six months isn’t accidental. For infrastructure companies, the agent runtime is the next basic unit of computing. Virtual machines, containers, functions (serverless), and now agents — the next slot in a stepwise abstraction of infrastructure. So even when they absorb the builder’s core value, the intent isn’t to kill builders. It’s to seize the infrastructure standard. The result is that the builder layer gets pincered, but the intent isn’t that.

Pressure From Below — Frontier Labs’ Product Expansion

At the same time, pressure rises from the opposite direction. Frontier labs are climbing up from chat interfaces, absorbing builder capabilities into their products.

The peak of this trajectory was April 22, 2026. Within one week, five giant platforms launched enterprise agent products nearly simultaneously. (Anthropic released Claude Managed Agents in public beta two weeks earlier, on April 8.)

Date	Company	Product	Core
2026-04-08	Anthropic	Claude Managed Agents (public beta)	Sandboxed exec, checkpointing, scoped permissions, tracing. Token rates + $0.08/session-hr. Notion/Asana/Sentry pre-launch adopters
2026-04-22	OpenAI	Workspace Agents	Codex-powered cloud-native, schedule/Slack triggers, Business/Enterprise/Edu plans
2026-04-22	Microsoft	Copilot Studio + Agent 365	Agent build atop M365 data, per-employee licensing
2026-04-22	Google	Gemini Enterprise Agent Platform	Workspace/Vertex bound, A2A (Agent-to-Agent) protocol announced
2026-04-22	Salesforce	Agentforce 360	CRM-data agents, sales/service automation

What the simultaneous launch says is one thing — the builder’s core use cases are being absorbed into frontier-lab and SaaS-giant products.

OpenAI Workspace Agents — Codex Replacing Workflows

The use cases OpenAI Workspace Agents called out make the picture clearer. Internal software request triage, product feedback routing, sales lead qualification, accounting reconciliation — exactly the workflow catalog Zapier, n8n, and Gumloop have sold for the past decade.

The key shift in Workspace Agents is the level of autonomy. The previous ChatGPT required a user prompt every time. Workspace Agents are triggered by schedule (every weekday 9 AM) or a Slack message, and they run autonomously in the background. Build one and the whole team uses it inside ChatGPT or Slack; it handles multi-step work across tools. Less reason to fire up a separate builder tool.

The pricing model competes directly with builders too. Bundled into Business/Enterprise/Edu/Teachers plans, free-tier for two weeks after launch (until May 6, 2026), then credit-based pricing. Since it sits inside an existing ChatGPT subscription, the entry barrier is lower than a separate builder SaaS license.

Anthropic Claude Managed Agents — What MCP-Native Means

Anthropic shipped two weeks earlier (April 8) with Claude Managed Agents in public beta. A different angle. If OpenAI Workspace Agents embeds agents inside the chat interface, Anthropic provides a managed runtime that developers pull into their own systems.

Sandboxed execution, checkpointing (save and recover intermediate state), scoped permissions, tracing (execution recording). Pricing: standard Claude API token rates + $0.08 per session-hour. Production adopters before public launch were Notion, Asana, and Sentry — Rakuten joined as an early adopter after. That these companies adopted is itself a signal. They each could have built their own builder infrastructure, but chose Anthropic’s managed runtime. A build-vs-buy decision that the managed side won.

And one more important point — Claude Agent SDK is MCP (Model Context Protocol) native. The peak of the integration-standardization flow from Part 1. Developers define agents in code, pull integrations through MCP, and run reasoning via Claude API. For users who don’t need a visual builder, the bypass route around the canvas is well-paved from day one.

Two Frontier Labs Arriving at the Same Answer in Seven Days

Part 2 touched briefly on this event; in Part 3 we look at its meaning again. Anthropic on April 8, OpenAI on April 22. Two frontier labs reached nearly the same architecture seven days apart. Both emphasized the same items — sandboxed execution, credential management, separation between the control plane (decision layer) and execution plane (action layer).

This can’t be coincidence. Two companies arriving independently at the same conclusion signals that the conditions for production agents are converging across the whole market. And the conditions are structurally the same bundle no-code builders have sold for the past decade.

Microsoft, Google, Salesforce’s Integration Absorption

On the same April 22, three giants moved together.

Microsoft Copilot Studio + Agent 365 — agent builder bundled into M365 licensing, with per-employee pricing. The biggest threat to standalone builder SaaS comes from here. Organizations already paying Microsoft don’t need to add another license.
Google Gemini Enterprise Agent Platform — launched bundled with Workspace and Vertex. Announced simultaneously was the A2A (Agent-to-Agent) protocol, an attempt to standardize agent-to-agent communication. Where MCP is model-to-tool, A2A is agent-to-agent.
Salesforce Agentforce 360 — sales/service agents on top of CRM data. An agent built inside Salesforce naturally carries CRM data context. That’s the position outside builders find hardest to replicate.

The most symbolic event is the OpenAI–AWS partnership. OpenAI Frontier holds AWS’s exclusive third-party distribution rights and is built as a stateful runtime on top of AWS Bedrock AgentCore. The pressure from above (AgentCore) and the pressure from below (OpenAI products) meet and merge at the same spot. The picture of the builder layer being pincered shows most clearly here.

The result of this pincer is one thing — “where the operational machinery lives” — the control plane — became the new battleground. Companies are no longer just picking which chatbot to use. They decide where the actual execution engine of their AI work lives. Inside the Microsoft stack? Inside OpenAI’s API layer? Inside Anthropic’s managed runtime? On top of AWS AgentCore? Inside an open framework? Or a hybrid of all of these?

The builder’s seat became one candidate inside this control plane. Other candidates — cloud infrastructure, frontier lab SDKs, incumbent SaaS giants — aim for the same seat.

Where the Builder Layer Gets Pushed — Compression and Relocation

When the infrastructure descending from above and the products ascending from below narrow the builder’s seat, the builder doesn’t disappear — it moves position. Organize the new position and a 4-layer picture emerges.

---
config:
  look: handDrawn
  theme: neutral
---
flowchart TB
    L4["Layer 4 — Custom ops / ERP<br/>Per-org infinite personalization<br/>(seat of capability)"]
    L3["Layer 3 — Builder / orchestration<br/>Domain-specific assembly tools<br/>(builder's new seat)"]
    L2["Layer 2 — Control plane<br/>Frontier labs + hyperscalers' joint battleground<br/>(OpenAI · Anthropic · Copilot · Agentforce)"]
    L1["Layer 1 — Infrastructure / runtime<br/>AgentCore · Foundry · Vertex<br/>(hyperscalers)"]
    L4 --> L3
    L3 --> L2
    L2 --> L1

The character of each seat —

Layer 1 — Infrastructure/runtime. Runtime, memory, identity, governance descend to infrastructure primitive. The hyperscaler’s seat. As AgentCore’s adoption cases (CloudZero, Apex Fintech, Genpact, Reply+Totemia) show, builders can’t win here.
Layer 2 — Control plane. The real battleground of “where the operational machinery lives.” The spot where frontier labs come up from chat interfaces and clouds come up from infrastructure and collide. OpenAI Frontier living on AgentCore and Anthropic Managed Agents’ managed runtime symbolize the merge.
Layer 3 — Assembly/orchestration. The builder’s new seat. Redefined as a tool that assembles domain-specific ops on top of the runtime. CrewAI, LangGraph, SmythOS, and LangChain — named as “partners” in AgentCore’s docs — sit here.
Layer 4 — Custom ops / ERP. The infinitely personalized operational layer that differs per organization. The seat of capability, not tools. Where margin and scarcity actually live.

Notice that the builder’s new position is Layer 3. The builder isn’t the end product — it gets redefined as a creator’s tool that assembles custom ops on top of infrastructure. Pulling Part 1’s music industry metaphor in, the builder isn’t Spotify (Layer 1, infrastructure) or the audio codec (Layer 2). It’s the DAW (Digital Audio Workstation) that producers use. It deepens into a creator’s tool that the end consumer doesn’t see.

One interesting signal of this relocation is AgentCore’s official documentation, which names CrewAI, LangGraph, SmythOS, and OpenAI Agents SDK as “partners.” The word “partner” is the point. Not competitors fighting for the same seat — upper-layer tools running on AgentCore, with their positions reorganized. The builder becomes AgentCore’s frontend, and AgentCore becomes the builder’s backend infrastructure.

What a16z’s ‘Losing its Head’ Adds — UI Was the Product

a16z’s analysis adds one decisive piece to this pincer/relocation picture. In “Is Software Losing Its Head?” a16z throws out one redefinition — what enterprise software has sold for the past twenty years isn’t a database, it’s UI.

Salesforce makes it clearest. What Salesforce sold to sales leaders wasn’t a sales database. It was “how a sales leader runs their team” — pipeline views, dashboards, the quarterly close screen. Many sales leaders bring Salesforce when they switch jobs not because the database is great, but because of the muscle memory they built in that UI. A moat born from humans living inside the interface.

But when agents read and write data directly through APIs, that moat evaporates. When UI disappears (headless), the defense line shifts down (data model, permissions, workflow logic, compliance) and up (network, proprietary data generation, real-world execution). The SaaS version of “the canvas thinning and value moving to other layers” from Part 1. Just as data and governance layers thickened where the builder’s canvas thinned, data models and execution layers thicken where SaaS’s UI thins.

The newest concept a16z adds is data exhaust.

Defensible data isn’t data imported from outside — it’s data generated by the product’s unique existence. The best businesses don’t pile data warehoused from elsewhere. They generate new data exhaust by being inside the loop — observed behavior, response rates, timing patterns, process outcomes, exception patterns, agent performance.

— a16z, “Is Software Losing Its Head?”

This concept deepens the value of Layer 4 (custom ops) by one more layer. It’s not just assembling ops — whether those ops, while running, generate proprietary data is the real moat. Data that someone else couldn’t produce with the same tool, generated inside your own loop. In music terms, it’s curating while simultaneously recording new tracks.

Six Criteria of Defensibility — A New Scorecard

The six criteria a16z proposes in the same piece work as a scorecard for the new value seat after the builder pincer. Six questions to ask whether a solution at Layer 4 is defensible.

Criterion	Question	Applied to the Builder Layer
1. SoR replication difficulty	How hard is it to replicate the System of Record (the source of truth)?	Simple workflow definitions get replicated easily. Domain depth becoming SoR-like makes it harder.
2. Proprietary data	Is there meaningful proprietary data?	Whether patterns, exceptions, success rates from workflow execution accumulate.
3. Action-layer ownership	Just observation, or inside execution?	The builder is the execution layer. But if execution is only external API relay, value is weak.
4. Real-world execution	Does it touch elements beyond digital?	Manufacturing, field service, logistics workflows are strong. Pure SaaS-to-SaaS is weak.
5. Network effects	Does value grow as users grow?	Standard workflow libraries, integration catalogs, collaboration — partially implemented.
6. Buyer technical capacity	Does the buyer have the skill to build it themselves (less = higher value)?	The biggest opportunity is in categories that are operationally complex but technically underdeveloped.

Unpack each criterion.

Criterion 1 — SoR Replication Difficulty

A System of Record is where the company’s source-of-truth data lives. Sales data in Salesforce, HR data in Workday, financial data in Oracle/SAP. Swapping an SoR costs astronomically. For the builder layer to become an SoR, it has to go beyond a simple workflow catalog — the company’s core operational data has to accumulate inside the builder. General builder SaaS is weak here. Domain-specific builders (e.g., financial back-office only) have a chance to evolve into SoR.

Criterion 2 — Proprietary Data (Data Exhaust)

The key concept covered above. Do the results of workflows the builder executes — success rates, failure patterns, response times, frequency of human intervention — accumulate as data unique to that builder? If yes, you can use it for next-workflow optimization, anomaly detection, recommendations. One year of execution data inside a builder is an asset another company can’t get even by adopting the same builder.

Criterion 3 — Action-Layer Ownership

Systems that only observe — dashboards, log analyzers — are weaker than systems inside execution. The builder is by nature an execution layer. It runs workflows, sends Slack messages, updates DBs, processes payments. But if that execution only relays external API calls (e.g., Zapier just moving A’s data to B), value is weak. The direction AgentCore Payments (Preview) points — agents handling real-world transactions — deepens the action layer.

Criterion 4 — Real-World Execution

Pure SaaS-to-SaaS automation is locked in the digital. Workflows that touch the outside — manufacturing lines, field service technicians, logistics trucks, medical equipment — are hard for digital-only systems to imitate. This is where builder SaaS is weak and where domain-specific ops (Layer 4) has its biggest opportunity. Reply+Totemia’s Offer Agent (30K MAU) is strong precisely because hotel and air-camp booking touches real-world transactions.

Criterion 5 — Network Effects

In the builder market, network effects partially work through integration catalogs (app A is in the builder, so app B has to join), standard workflow templates (more users = more shared templates), and collaboration (team sharing). But the guMCP and MCP-standardization flow from Part 1 weakens the network effect of integrations themselves.

Criterion 6 — Buyer Technical Capacity

The deepest criterion. Even in a world where anyone could theoretically build their own agent, the actual capacity gap is large. The biggest opportunity is in operationally complex but technically underdeveloped categories — manufacturing back-office, construction site management, industrial/field service workflows, accounting, healthcare administration. Buyers in those spaces are unlikely to build and maintain their own DB, logic, agent stack, and governance.

Overlay these six criteria onto the post-pincer builder market and an interesting conclusion appears. It’s hard for a builder tool itself to satisfy all six criteria. The tool provides integration, execution, observation; proprietary data, real-world execution, and domain SoR depth have to be created by the user of the tool. Value shifts from the tool to the user — more narrowly, to the capacity to assemble the tool into a domain. The seat the six criteria point to is exactly Layer 4 in the 4-layer picture.

Closing — Where Value Settles Inside the Pincer

Pull everything together in one line. The builder layer compresses vertically from above (hyperscalers) and below (frontier labs), and the result is value moving to Layer 4 (custom ops) and the data exhaust above it.

The events between October 2025 and April 2026 — AgentCore GA (October), Azure Foundry GA (November), Vertex Agent Engine GA (Q1), Anthropic Managed Agents (April 8), OpenAI Workspace Agents and Microsoft, Google, Salesforce simultaneous launches (April 22) — aren’t coincidence. They’re the accumulation of one market moving in the same direction at once. From above, from below, toward the same seat.

The result is that the place where the most value collects is capability, not tools. Who understands the client’s work, designs which ops to assemble on top of which runtime, and closes the loop where those ops generate proprietary data — that assembly/curation capacity isn’t pincered. It grows.

Pulling Part 1’s music industry metaphor across the series — in the streaming era, the biggest value wasn’t infrastructure (Spotify) or codecs (audio quality). It was curation and A&R (Artists & Repertoire). On top of infinite supply, the person who knows “what to combine, for whom, how.” The same seat emerges in the builder market. The builder gets absorbed into infrastructure, but the value of “the curator who designs custom ops” isn’t pincered — it grows.

Compress the conclusion of all three parts:

What ends is the canvas. Not the builder category. The container of value shifts from canvas to context/execution/governance, and on top of that, custom ops assembly and data exhaust create a new curation premium.

a16z’s picture has one blind spot. This series applied a16z’s insight to the builder layer, but a16z itself is an AI-native startup investor, so its lens naturally tilts toward “incumbents are shaken.” Where to discount that bias, and how to read the cracks a16z’s own text lets slip (the underestimation of switching cost), will be taken up in a separate post.

Series — The Future of Builders

Part 1: Is “No-Code Builders Are Over” Actually True? → /en/blog/builder-future-1-dematerialization
Part 2: Will No-Code Get Eaten or Get More Precious? — Two Sides of the Code-Agent Era → /en/blog/builder-future-2-deterministic-scaffold
(this post) Part 3: In the Headless Era, Where Does Pincered Value Collect? — Vertical Compression of the Builder Layer
Series index: /en/series/builder-future

References

AWS, “Bedrock AgentCore General Availability” (October 13, 2025)
AWS, “AgentCore Pricing — 12 Components” (Runtime $0.0895/vCPU-hr, Memory $0.00945/GB-hr, Policy $0.000025/request)
AWS Partner Network Blog, “Enterprise AI Agent Solutions with AgentCore” (CloudZero, Apex Fintech, Genpact, Reply+Totemia case studies)
AWS, “AgentCore Payments (Preview)” (May 11, 2026, Coinbase CDP + Stripe Privy)
Microsoft, “Azure AI Foundry Agent Service GA” (November 2025, 10,000+ customers, Teams integration)
Google Cloud, “Vertex AI Agent Engine” (Q1 2026)
Anthropic, “Claude Managed Agents Public Beta” (April 8, 2026, Notion/Asana/Sentry pre-launch adopters + Rakuten early adopter, platform.claude.com/docs/managed-agents)
OpenAI, “Workspace Agents” (April 22, 2026, Codex-powered)
Microsoft, “Copilot Studio + Agent 365” (April 22, 2026)
Google, “Gemini Enterprise Agent Platform + A2A protocol” (April 22, 2026)
Salesforce, “Agentforce 360” (April 22, 2026)
VentureBeat, “The Agent Control Plane is the Next Enterprise Battleground”
a16z, “Is Software Losing Its Head?” (UI as product, data exhaust, 6 criteria of defensibility)