# janakiram-agent-platform-portability-contract-2026-07-20

## Veille

Analysis by Janakiram MSV (The New Stack, July 20, 2026) of the **architectural convergence** of the three hyperscalers' enterprise agent platforms: in nine months, **Amazon Bedrock AgentCore**, **Microsoft Foundry**, and **Gemini Enterprise Agent Platform** have converged on the **same six primitives** — runtime, memory, tool gateway, identity, observability, governance — under different brand names. What was a fragmented collection of libraries 18 months ago is becoming a distinct **platform layer**. The thesis: this convergence replays the **2011-2016 PaaS inflection**, where **Cloud Foundry** and **Heroku** unified VMs, load balancers, queues, and secret stores around a portable **application contract** — except that here **no equivalent contract yet exists**, and **no open source project has claimed it**. Consequence: an enterprise cannot **move an agent from one cloud to another** (session state, traces, and identity all end up with a single provider; migrating means rebuilding everything). The author proposes a **line-by-line mapping** of the Cloud Foundry contract onto agents, sets out three design principles (package the agent as **one deployable unit**, **attach** capabilities rather than embedding providers, integrate the **operational** layer into the abstraction), points to what open protocols (MCP, A2A, OpenTelemetry) leave out of scope — the **lifecycle** — and delivers three due diligence questions: **governance** (neutral foundation vs. vendor), **packaging** (the same artifact on two clouds without rewriting), **state** (exportable memory). Verdict: whoever ends up owning the **agent control plane** will define *what an agent is*.

## Titre Article

Amazon, Microsoft, and Google are converging on the same enterprise agent architecture

## Date

2026-07-20

## URL

https://thenewstack.io/agent-platform-portability-contract/

## Keywords

Enterprise agent platforms, architectural convergence, portability, lock-in, reversibility, application contract, Amazon Bedrock AgentCore, Microsoft Foundry, Azure AI Foundry, Foundry Agent Service, Entra Agent ID, Gemini Enterprise Agent Platform, Vertex AI, Agent Engine, Memory Bank, Agent Registry, Agent Substrate, runtime, memory, tool gateway, identity, observability, governance, agent control plane, PaaS, Cloud Foundry, Heroku, buildpacks, Cloud Native Buildpacks, service broker, service binding, Korifi, Kubernetes, Twelve-Factor App, attached resource, MCP, Model Context Protocol, A2A, OpenTelemetry, GenAI conventions, OCI images, LangGraph, LangSmith, checkpointing, Agentic AI Foundation, Linux Foundation, goose, AGENTS.md, Strands, harness export, due diligence, neutral governance, packaging, exportable state, hyperscalers, negotiating power, Janakiram MSV

## Authors

Janakiram MSV

## Ton

**Profile**: architect/analyst piece (infrastructure thought leadership) by Janakiram MSV — a practitioner, analyst, and Silicon Valley startup advisor — for The New Stack, addressed to platform teams and infra decision-makers. Analytical, structured register (a thesis, a sustained historical analogy, a mapping table, three principles, three diligence questions), high technicality but didactic, medium length (~1600 words).

**Style**: builds the entire argument on a **historical analogy** — the 2011-2016 PaaS trajectory as a mirror of the agent inflection — and follows it through to the end (buildpacks that outlive Cloud Foundry via CNCF/Korifi; Kubernetes winning the market but inheriting the principles). A distanced analyst stance: names the convergence "rational behavior rather than conspiracy" (the margin is in vertical integration), refuses vendor cheerleading ("whatever the platform brochure claims"). Wields **reusable decision tools**: a three-column table (PaaS abstraction → agent equivalent → where portability breaks today), three named design principles, three due diligence questions "in plain terms." Precise, dated factual sourcing (GA dates, renamings, Linux Foundation memberships). References the author's own earlier piece on Google's Agent Substrate. A deliberate forward-looking closing line ("Whoever ends up owning the agent control plane… defines what an agent is"). TNS editorial transparency note: shareholder Insight Partners invests in OpenAI, Anthropic, Real.

## Pense-betes

- **Core idea: three hyperscalers, one architecture.** In 9 months, Amazon, Microsoft, and Google have converged on the **same six primitives** for enterprise agents — runtime, memory, tool gateway, identity, observability, governance — under different brands. What was a fragmented collection of libraries 18 months ago is becoming a **platform layer** in its own right.
- **The gap: no contract, so no portability.** Convergence of *components* does not produce portability. What's missing is the **contract** (in the PaaS sense) that would make an agent agnostic about where it runs. Today, session state, traces, and identity **all end up with a single provider**; moving the agent a year later means **rebuilding everything**.
- **The guiding analogy: PaaS 2011-2016.** Before Cloud Foundry / Heroku, teams assembled VMs, load balancers, queues, secret stores, and monitoring agents, each with its own API. PaaS unified all of that around an **application contract**: "the app declares what it needs and stays agnostic about where it runs." **What mattered was the contract, not the implementation.**
- **Cloud Foundry lesson: the contract outlives the platform.** Cloud Foundry did **not** win the market (Kubernetes did), but its principles traveled: buildpacks born at Heroku (2011) → **Cloud Native Buildpacks** (Pivotal+Heroku, Jan. 2018, accepted into the CNCF in October); the Cloud Foundry abstraction rebuilt on K8s via **Korifi**. Companies on that foundation in 2016 had a portability that **most agent teams cannot buy today**.
- **The three platforms, stripped of marketing.** (1) **AgentCore** (GA Oct. 2025): 7 composable services (runtime, gateway, memory, browser, code interpreter, identity, observability); runtime = isolated **8-hour** execution windows; gateway plugs in existing **MCP** servers; observability exported via **OpenTelemetry** to CloudWatch. (2) **Microsoft Foundry** (renamed from Azure AI Foundry on **Jan. 1, 2026**): managed runtime isolated per session, **Entra Agent ID** identity, session/user/procedural memory, OpenTelemetry tracing. (3) **Gemini Enterprise Agent Platform** (Vertex AI name dropped at Cloud Next 2026): Agent Engine → **Deployments**, plus Memory Bank, Sessions, Agent Registry, Policies, Gateways.
- **Convergence isn't a conspiracy, it's the margin.** Infrastructure companies build **vertically integrated** platforms because "integration is where the margin is." The consequence falls on the **customer**: identity, telemetry, and deployment end up with a single provider → **the operational layer beneath the agent is what resists migration**.
- **The contract mapping (table, reusable for due diligence).** 8 rows "PaaS abstraction → agent equivalent → where portability breaks": app source → code+instructions+eval suite (each framework has its own package format); buildpack → framework detection+packaging (no shared build contract across SDKs); backing service → model/memory/retrieval/tool (providers wired into the logic); service binding → authenticated attachment (credentials issued by the host cloud); router → MCP/A2A endpoint (the protocols exist, not the lifecycle); logs → traces/tool calls/cost/quality (GenAI conventions still in development); release promotion → evaluate/version/progressively deploy (eval coupled to a vendor harness); policy → identity/permissions/approvals (identity tied to the provider's directory).
- **Three design principles.** (1) **Package the agent as one deployable unit**: code, instructions, tool dependencies, memory contract, permissions, and eval suite travel **together or not at all**. AWS comes close with its *harness export* (one command → **Strands** code preserving model, prompt, tools, memory, container), "the right instinct, pointed at a single cloud." (2) **Attach rather than embed** (the **Twelve-Factor** lesson): models, memory, retrieval, browsers, gateways = resources attached via config. "An agent that names its model provider in its application logic has already given up portability." (3) **Integrate the operational layer into the abstraction**: the right agent questions are whether the agent accomplished the task, chose the right tools, exceeded its authority, at what cost, and whether quality regressed after a model update.
- **An agent is not a web app with a model grafted on.** Three differences carry all the weight: **probabilistic** behavior (same inputs → different tool calls); **delegated authority** from the user (a permissions bug becomes a real side effect, not an error page); **dependencies change behavior without a code deployment** (a model update or a revised tool description changes what the agent decides). The Twelve-Factor "stateless process" rule doesn't survive here: it requires **disposable workers** *plus* **durable, inspectable, portable state**. **LangGraph** demonstrates this in open source (checkpointing at every step, human interruptions, crash recovery) — but its control plane sits in the commercial product **LangSmith**: the fragmentation shows up **within a single project**.
- **What open protocols leave out of scope: the lifecycle.** MCP (tool/data access), A2A (inter-agent discovery/communication), OpenTelemetry (GenAI conventions, most attributes still "in development"), OCI images (a packaging escape hatch): **almost all the primitives exist**. But **a foundation that governs how agents talk to tools says nothing about how to version an agent**, promote it across environments, or roll it back when an eval regresses. **Protocols ≠ lifecycle platform.**
- **The vendors' concession signal.** The **Linux Foundation** announced the **Agentic AI Foundation** (December 2025); founding projects: **MCP** (Anthropic), **goose** (Block), **AGENTS.md** (OpenAI); **AWS, Google, and Microsoft as platinum members**; Google contributed **A2A** to the Linux Foundation. The hyperscalers **admit** that a neutral layer matters.
- **Three due diligence questions (to keep in mind when choosing an agent platform).** (1) **Governance**: is the project controlled by a **neutral foundation** or by the vendor selling the managed version? (2) **Packaging**: does the same artifact run on **two clouds without rewriting**? (3) **State**: does the memory live **somewhere exportable** by the enterprise? **No open project answers all three today.**
- **The final stakes: whoever owns the control plane owns the definition.** Just as Kubernetes defined pods/deployments/services and shaped the thinking of an entire industry, the agent equivalent is **not yet settled**. Whoever ends up owning the **agent control plane** won't just own deployment: they will define **what an agent is**, what components it contains, what a platform team is allowed to replace. A neutral project would give enterprises back the **negotiating power** that buildpacks and service brokers once gave them — to the benefit of vendors as much as buyers.
- **Related**: "The Development Environment Is The Next Layer To Collapse" (Greyling) and "Building for trillions of agents" (Levie) on agent layers; agent identity (Uber Engineering entry, zero-trust/SPIRE) — the same delegated-identity problem handled on the infra side; the sovereignty / reversibility / **Design to Exit** family (ZML/LLMD entry) — the same logic of "paying upfront for the layer that makes the provider replaceable," transposed from silicon to the agent control plane.

## RésuméDe400mots

In nine months, Amazon, Microsoft, and Google have each launched or renamed an enterprise agent platform, and **all three have converged on the same architecture**: runtime, memory, tool gateway, identity, observability, and governance now appear in **Bedrock AgentCore**, **Microsoft Foundry**, and the **Gemini Enterprise Agent Platform**, under different names. What was a fragmented collection of libraries 18 months ago is becoming a distinct **platform layer**.

To read where this leads, Janakiram MSV invokes the **2011-2016 PaaS inflection**. Before, teams assembled VMs, load balancers, queues, secret stores, and monitoring agents, each with its own API. **Cloud Foundry** and **Heroku** unified these pieces around an **application contract**: the application declares what it needs and stays agnostic about where it runs. What mattered was the **contract, not the implementation**. Cloud Foundry didn't win the market — Kubernetes did — but its principles survived (buildpacks → Cloud Native Buildpacks/CNCF; the Cloud Foundry abstraction rebuilt on K8s via Korifi). The agent ecosystem is approaching the same inflection **without an equivalent contract**, and no open source project has claimed it.

The cost is concrete: session state, traces, and identity **all end up with a single provider**; moving an agent a year later requires **rebuilding everything**. The convergence is not a conspiracy but rational behavior — vertical integration, "that's where the margin is" — whose consequence falls on the customer.

The author proposes a **mapping** of the Cloud Foundry contract onto agents (app source → code+eval; buildpack → packaging; backing service → model/memory; binding → authenticated attachment; router → MCP/A2A; logs → traces/cost/quality; promotion → eval/versioning; policy → identity), then three principles: **package the agent as one deployable unit** (AWS comes close with its *harness export* to Strands code, "the right instinct, pointed at a single cloud"), **attach capabilities rather than embed providers** (the Twelve-Factor lesson), **integrate the operational layer into the abstraction**. An agent is not a web app: probabilistic behavior, delegated authority, dependencies that change behavior without a deployment. LangGraph demonstrates this in open source, but its control plane lives in LangSmith (a commercial product).

Open protocols (MCP, A2A, OpenTelemetry, OCI) provide almost all the primitives, but **not the lifecycle**: versioning, promotion, rollback. The **Linux Foundation** launched the **Agentic AI Foundation** (Dec. 2025, founding projects MCP/goose/AGENTS.md, hyperscalers as platinum members). Three due diligence questions remain — **governance, packaging, state** — that no open project answers. Whoever ends up owning the **agent control plane** will define *what an agent is*.

## GrapheDeConnaissance

- Amazon Bedrock AgentCore —converge_avec→ Microsoft Foundry (TECHNOLOGIE, 0.95)
- Microsoft Foundry —converge_avec→ Gemini Enterprise Agent Platform (TECHNOLOGIE, 0.95)
- Janakiram MSV —affirme_que→ les trois hyperscalers ont convergé sur les mêmes six primitives d'agent (runtime, mémoire, tool gateway, identité, observabilité, gouvernance) (AFFIRMATION, 0.95)
- Janakiram MSV —affirme_que→ l'écosystème agent manque du contrat de portabilité qu'aucun projet open source n'a revendiqué (AFFIRMATION, 0.92)
- Cloud Foundry —permet→ portabilité applicative via un contrat agnostique du lieu d'exécution (AFFIRMATION, 0.9)
- plateforme d'agents d'entreprise —s_inspire_de→ PaaS (Cloud Foundry, Heroku) (TECHNOLOGIE, 0.88)
- contrat de portabilité agent —réduit→ lock-in vis-à-vis d'un hyperscaler (CONCEPT, 0.85)
- Amazon Bedrock AgentCore —utilise→ Model Context Protocol (TECHNOLOGIE, 0.9)
- Amazon Bedrock AgentCore —utilise→ OpenTelemetry (TECHNOLOGIE, 0.9)
- Microsoft Foundry —utilise→ Entra Agent ID (TECHNOLOGIE, 0.9)
- Microsoft Foundry —est_variante_de→ Azure AI Foundry (TECHNOLOGIE, 0.9)
- Gemini Enterprise Agent Platform —remplace→ Vertex AI (TECHNOLOGIE, 0.88)
- LangGraph —permet→ état d'agent durable, inspectable et portable (checkpointing, reprise après crash) (AFFIRMATION, 0.9)
- LangGraph —fait_partie_de→ LangSmith (TECHNOLOGIE, 0.82)
- Model Context Protocol —fait_partie_de→ Agentic AI Foundation (TECHNOLOGIE, 0.9)
- Linux Foundation —publie→ Agentic AI Foundation (TECHNOLOGIE, 0.92)
- protocoles ouverts (MCP, A2A, OpenTelemetry) —s_oppose_à→ plateforme de cycle de vie agent (CONCEPT, 0.8)
- harness export AWS —permet→ conversion d'un harness configuré en code Strands (modèle, prompt, outils, mémoire préservés) (AFFIRMATION, 0.88)
- Twelve-Factor App —recommande→ traiter les capacités (modèle, mémoire, outils) comme des ressources attachées par configuration (AFFIRMATION, 0.85)
- Janakiram MSV —recommande→ évaluer une plateforme agent sur trois questions : gouvernance neutre, packaging portable, état exportable (AFFIRMATION, 0.9)
- Janakiram MSV —prédit→ celui qui possèdera le control plane agent définira ce qu'est un agent (AFFIRMATION, 0.85)
- Kubernetes —a_créé→ abstractions (pods, deployments, services) façonnant la pensée de l'industrie (AFFIRMATION, 0.85)

---
Canonical: https://www.thekb.eu/en/fiches/janakiram-agent-platform-portability-contract-2026-07-20/