02. Platform landscape map — three families, real players, what each is built to do¶

~17 min read. You decided both bank agents belong on a hyperscaler runtime. But "hyperscaler runtime" is three rival products with different strengths, and the families bleed into each other in 2026. This file is the map you read before you walk.

Built on 01-build-vs-buy-decision.md. You picked a family by boundary. This file fills in the three families with current real players, names what each optimizes for, and — critically — shows where the families now overlap, because the clean diagram from file 01 has blurry edges in practice.

What the boundary decision left open¶

File 01 placed both bank agents on the hyperscaler-runtime family by reasoning about boundaries and drift. That decision narrowed the field but did not pick a product. "Hyperscaler runtime" today means AWS Bedrock AgentCore, Google Vertex AI Agent Builder with Agent Engine, or Microsoft Foundry Agent Service — and they are not interchangeable. One is deepest on cloud-native security primitives, one on model breadth and managed memory, one on enterprise-IT and Microsoft-365 integration. The boundary is the same; what sits behind it differs.

This file also corrects a simplification. File 01 drew three clean families. In 2026 the edges blur: hyperscalers host open frameworks, frameworks ship managed cloud versions, and SaaS vendors expose framework-style customization. You need the map and the blur, because a real decision often combines families — a framework orchestration on a hyperscaler runtime calling a SaaS component as a tool.

What this file solves¶

A team has narrowed to a family but cannot tell the players apart, so it picks by brand familiarity or the loudest sales team. This file gives you a positioning map: what each real player optimizes for, where the families overlap, and how to read a new entrant against the map in six months when half these names have changed. The first move is to stop seeing "platforms" and start seeing "what is this one built to be best at, and what does it concede to be best at that."

Why a flat vendor list is useless¶

A flat list — "AWS, Google, Azure, OpenAI, LangGraph, CrewAI, Sierra, Decagon, Glean…" — tells you nothing, because it hides the structure that makes the choice. Two vendors in the same family compete on the same axes; two vendors in different families are barely comparable. Comparing Decagon to LangGraph is like comparing a managed payroll SaaS to a programming language. The map's job is to group by family first (the boundary), then position within family (the optimization), then mark the overlaps (the blur).

When two runtimes look identical until you push on them¶

The bank's platform lead pulls up Bedrock AgentCore and Vertex Agent Engine side by side. Both say: managed runtime, any framework, any model, built-in memory, observability, identity. On the slide they are twins. Push on one requirement and they diverge:

Requirement: "Sign every model call with our own KMS key and pin all
state to ap-south-1 (Mumbai) for the regulator."

AWS Bedrock AgentCore:  KMS integration native; runtime + memory in
                        ap-south-1; AgentCore HIPAA-eligible since Feb 2026;
                        deep IAM identity model the bank already uses.

Vertex Agent Engine:    strong residency + Gemini/Claude model access;
                        Agent identity via IAM (Preview); Memory Bank GA;
                        but the bank's core systems are on AWS, so cross-cloud
                        identity and egress become the friction.

Neither is "better." The deciding factor is the bank's existing cloud, identity system, and where its core-banking data already lives. So the real differentiator between two runtimes in the same family is rarely the agent features; it is which cloud your data and identity already live in. That is the gravity that makes one runtime cheap to adopt and the other a cross-cloud integration project.

The map rule. Group platforms by family (boundary), then by what each optimizes for within the family, then mark where families overlap. A platform's family tells you what you give up; its optimization tells you what you get; the overlaps tell you what you can combine.

1) The three families on one map — how to read it¶

                    HYPERSCALER RUNTIME              AI-NATIVE FRAMEWORK            SAAS VERTICAL AGENT
                    (own logic, rent ops)            (own everything)               (own config only)
                    ─────────────────────            ───────────────────            ───────────────────
  Optimizes for     managed ops + cloud-native       control + portability          time-to-value + packaged
                    security + model breadth         + lowest per-token cost        domain expertise

  Real players      AWS Bedrock AgentCore            LangGraph                      Sierra (CX)
  (2026)            Google Vertex Agent Engine       CrewAI                         Decagon (CX)
                    Microsoft Foundry Agent Svc      LlamaIndex                     Salesforce Agentforce
                                                     OpenAI Agents SDK              NiCE Cognigy (contact center)
                                                     Microsoft Agent Framework      Glean (knowledge search)

  You give up       cloud lock-in (identity,         the ops burden — you run       control of orchestration,
                    networking, billing)            servers, tracing, on-call      model, runtime, often data

  You get           scaling, memory, identity,       any model, any deploy target,  a working domain agent in
                    security plumbing — free         total customizability          days, vendor-run

  ◀── overlap ──▶   runtimes HOST frameworks         frameworks ship managed        SaaS expose framework-style
                    (LangGraph on AgentCore,         clouds (LangGraph Platform)    customization + MCP tools;
                    Agent Framework on Foundry)      blurring toward runtimes       some run on hyperscalers

The map is the file. Read columns for "what do I give up / get," read the bottom row for "what can I combine." The bank lives in the left column and will reach into the others: it may call a SaaS knowledge agent (Glean) as a tool from its runtime-hosted framework, which is the overlap row in action.

2) Hyperscaler runtimes — positioned against each other¶

All three give you a managed runtime that hosts open frameworks and any model. They diverge on what they are deepest at.

AWS Bedrock AgentCore¶

Optimizes for: secure, modular, consumption-billed runtime that runs any framework and any foundation model, with deep AWS-native security and identity. As of 2026 it exposes a dozen independently billable components (runtime, gateway, memory, identity, browser, code interpreter, and a preview payments capability built with Coinbase and Stripe). AgentCore became HIPAA-eligible in February 2026. The deciding strength: if your data and identity already live in AWS, the boundary is nearly free to cross — IAM, KMS, VPC, S3 all line up.

Google Vertex AI Agent Builder / Agent Engine¶

Optimizes for: model breadth and managed long-term memory. Agent Engine offers a fully-managed runtime with GA Sessions and Memory Bank, evaluation, and code execution; ADK provides portable orchestration with a one-command adk deploy. Model Garden exposes 200+ models including Gemini and Anthropic Claude as first-class options. Tool governance via the Cloud API Registry lets admins manage which tools developers can use org-wide. The deciding strength: managed memory at GA and the strongest model menu under one runtime.

Microsoft Foundry Agent Service¶

Optimizes for: enterprise IT integration and the Microsoft estate. Hosted agents run external frameworks (Microsoft Agent Framework, LangGraph) on a fully managed Foundry runtime with built-in scaling, observability, and governance. It speaks A2A (preview) for agent-to-agent, supports multi-agent orchestration and a tool catalog, and offers Agent Commit Units for committed-spend discounts. The deciding strength: if the enterprise runs on Microsoft 365, Entra identity, and Azure, the agent slots into existing IT governance.

Teacher voice. Three runtimes, one shape, three centers of gravity: AWS pulls on cloud-native security primitives, Google pulls on model breadth and memory, Microsoft pulls on the enterprise IT estate. You do not pick the "best agent runtime." You pick the one whose gravity matches where your data, identity, and IT already live. For the bank, that is whichever cloud holds its core-banking systems.

3) AI-native frameworks — positioned against each other¶

Frameworks all live in the right column: you own everything. They diverge on the orchestration style and the center of competence.

LangGraph — cyclic, graph-based orchestration with the most low-level control, best production-readiness, and best token efficiency among frameworks, at the cost of the steepest learning curve. The default when you need fine control over the loop and state.
CrewAI — role-based "crews" modeled on human teams; easiest learning curve, most intuitive for readable multi-agent collaboration, least low-level control. The default when the team wants legible role/task structure fast.
LlamaIndex — retrieval-first; the framework to build on when the agent is fundamentally a RAG system and retrieval quality is the core competency.
OpenAI Agents SDK — a tiny primitive set (agents, handoffs, guardrails) plus built-in tracing; the lightweight default for teams standardizing on OpenAI, now with sandboxing and subagents. AgentKit wraps it with a visual Agent Builder, a Connector Registry, and ChatKit.
Microsoft Agent Framework — the open framework that also runs hosted on Foundry, deliberately straddling the framework/runtime boundary.

The overlap to notice: a framework is just a library, so it is the orchestration layer you can place on a hyperscaler runtime. The bank's plan from file 01 — LangGraph on AgentCore — is precisely a right-column library running in a left-column runtime. That combination is why the bank keeps its orchestration portable while renting the ops.

4) SaaS vertical agents — positioned by domain, not by features¶

SaaS agents are not compared on orchestration; they are compared on which domain they own and how deep that ownership goes.

Sierra — front-line customer service, especially transactional CX (refunds, billing, account changes). Owns the support workflow end to end.
Decagon — omnichannel support automation, natural-language-driven, tuned for speed and consistency across channels.
Salesforce Agentforce — CX and sales agents inside the Salesforce ecosystem, priced per conversation or per action; deepest when your CRM is already Salesforce, and it pulls in a mandatory Data Cloud dependency.
NiCE Cognigy — contact-center agents across voice, messaging, and social, built for organizations whose center already runs on that stack.
Glean — enterprise knowledge search and assistance; owns the "find the answer across fragmented internal sources, permission-aware" problem rather than workflow automation.

The deciding question for a SaaS agent is never "does it have feature X." It is "is my problem this vendor's domain, and will my problem stay inside it?" A bank evaluating Sierra is really asking: is automated transactional support our problem, and will it stay there? File 01 already answered no — it drifts — which is why Sierra is at most a component, not the platform.

5) The overlap row — why the clean three-family diagram blurs¶

The most important thing on the map is the bottom row, because real architectures live in the blur.

flowchart LR
    subgraph Framework
      LG[LangGraph orchestration<br/>you own & can move]
    end
    subgraph Runtime[Hyperscaler runtime]
      RT[AgentCore / Agent Engine / Foundry<br/>managed ops, identity, memory]
    end
    subgraph SaaS[SaaS verticals as tools]
      GL[Glean knowledge search]
    end
    LG -->|deployed on| RT
    LG -->|calls as a tool| GL
    RT -->|hosts| LG

Three families, one system. The bank's support agent is a LangGraph orchestration (framework, owned, portable) running on AgentCore (runtime, managed ops) that calls Glean (SaaS, knowledge search) as one of its tools. Each family is doing what it is best at, and the boundary still sits where the bank wants it — at "our code vs the machine" — because the orchestration is owned and the SaaS appears only as a replaceable tool, not as the platform.

This is why "which family" from file 01 was necessary but not sufficient. The real answer is usually a composition, with one family carrying the orchestration boundary and the others appearing as managed substrate (runtime) and replaceable capabilities (SaaS-as-tool).

Mini-FAQ. "If everyone hosts everyone, does the family distinction still matter?" Yes — it tells you where the boundary sits. A LangGraph orchestration on AgentCore keeps the boundary at your code; a Sierra deployment keeps it at the config surface even if Sierra runs on a hyperscaler underneath. The hosting blurs the infrastructure, not the ownership boundary. Ownership is what causes the wall.

6) The cost and time-to-value movement across the map¶

Family / player class	Time to first working agent	Per-task cost shape	Ops you own	Portability of your work
SaaS vertical (Sierra, Decagon, Agentforce)	days	high, fixed per conversation/action	~none	low — config doesn't move
Hyperscaler runtime (AgentCore, Agent Engine, Foundry)	weeks	tokens + runtime/component fees	minimal (managed)	medium — logic portable, memory/identity sticky
Framework self-host (LangGraph, CrewAI)	weeks–months	tokens + your raw infra (lowest at scale)	all of it	high — you own the code and data

The movement, not the numbers, is the lesson: as you move up the map toward SaaS, time-to-value collapses and portability collapses with it; as you move down toward self-hosted frameworks, portability rises and so does the ops you carry. The hyperscaler runtime sits in the middle on time, cost, and portability — which is why the bank, with a small team and a high bar, lives there and reaches into the other families only as substrate and tools. The subsystem that absorbs the runtime's middle position is the cloud bill plus a few weeks of build, traded for a movable boundary.

7) Operational signals — is your reading of the map still accurate?¶

Healthy. Each platform in your architecture is used for what it optimizes for: the runtime carries ops, the framework carries portable logic, the SaaS carries a bounded domain capability as a tool. Nobody is bending a SaaS into a platform or a framework into a managed service.

First metric that degrades. The fraction of a platform's capability you are fighting rather than using. When you find yourself working around a SaaS's closed orchestration or re-implementing a runtime's managed memory because it doesn't fit, you've used a platform outside its optimization — the map reading was wrong.

Misleading metric people watch. Feature-parity checklists across vendors. Two runtimes can have identical checklists and diverge entirely on which cloud your data lives in. The checklist hides the gravity that actually decides.

The signal an experienced lead checks first. "Where do our data, identity, and existing systems already live?" — because that gravity, not the feature list, decides which same-family player is cheap to adopt. The bank's answer (AWS core-banking) is the real differentiator between AgentCore and Agent Engine for them.

8) Boundary of applicability — when the map itself misleads¶

Strong fit for map-based thinking. Evaluating a known field of mature players, where families are stable and you are choosing within and across them. The map turns a flat vendor list into a structured decision.

Where the map becomes pathological. Treating the family labels as permanent. In 2026 the families actively converge — frameworks ship managed clouds, runtimes host frameworks, SaaS expose customization. A team that learned the map in 2024 and never updated it will mis-place a 2026 entrant. The map is a snapshot; the families are verbs, not nouns.

Scale / regime that invalidates the intuition. The intuition "SaaS = no control, framework = full control" breaks at the overlap row, where a SaaS exposes MCP tools and custom logic (more control than expected) and a managed framework cloud takes over your ops (less control than expected). At the blurred edges, you must check the actual ownership boundary, not the family label.

9) The wrong model to drop: "the families are separate aisles in a store"¶

The tempting picture is a store with three aisles — pick one aisle, buy one product. Reality is a kitchen: you compose ingredients from all three. The bank's real architecture pulls a framework (LangGraph), a runtime (AgentCore), and a SaaS-as-tool (Glean) into one dish. Thinking in aisles makes you force the whole solution into one family and either over-build (framework for everything) or over-buy (SaaS for everything).

Replace the aisle picture with the composition picture from section 5: one family owns the orchestration boundary, the runtime is the substrate, and SaaS verticals are replaceable tools. The skill is deciding which family carries the boundary, then borrowing freely from the others.

10) Other failure shapes when reading the landscape¶

Brand-gravity selection — picking the runtime whose logo the CTO trusts, ignoring where the data actually lives.
Stale-map error — using a 2024 mental model where families don't overlap, then mis-placing a 2026 hybrid offering.
Checklist parity trap — declaring two same-family runtimes equivalent because their feature tables match, missing the cloud-gravity differentiator.
SaaS-as-platform overreach — buying a vertical agent and trying to make it the orchestration layer for unrelated workflows.
Framework-as-managed-service illusion — assuming a framework gives you ops for free; it gives you a library and a bill for running it.
Ignoring the overlap row — refusing to compose families, so you reject a SaaS knowledge agent you could have called as a tool and rebuild it badly yourself.
First-gate skip — evaluating SaaS verticals on features before asking whether your problem is even that vendor's domain.

11) Pattern transfer — where landscape-mapping recurs¶

Model vendor strategy (module 12) — the same family-then-position logic applies to model providers: group by deployment shape (API, in-cloud, self-hosted weights), then position by capability and price; the platform map nests on top of the model map.
Build-vs-buy (file 01) — this map is the resolution of file 01's family choice; the boundary picked there selects the column you read here.
Tool integration contracts (module 19) — the overlap row's "SaaS-as-tool" is exactly a tool contract; calling Glean from your runtime is honoring a tool schema across a vendor boundary.
Capacity / vendor landscapes in classic infra — choosing among managed DB, DBaaS, and self-hosted is the same map with different nouns; the families and gravity logic transfer wholesale.

12) The landscape audit — five yes/no questions¶

Have you grouped candidates by family (boundary) before comparing them, instead of using a flat list?
For same-family rivals, have you identified where your data, identity, and existing systems already live — the real differentiator?
Have you named what each candidate optimizes for, and confirmed your use case wants exactly that?
Have you checked the overlap row — can you compose a framework + runtime + SaaS-as-tool instead of forcing one family?
Is your map current to this year, accounting for runtimes hosting frameworks and frameworks shipping managed clouds?

Where this appears in production¶

Hyperscaler runtimes and their gravity: - AWS Bedrock AgentCore — chosen by AWS-native shops because IAM, KMS, VPC, and S3 line up, making the boundary cheap to cross; HIPAA-eligible since 2026. - Google Vertex Agent Engine — chosen for model breadth (Gemini + Claude in one Model Garden) and GA managed memory (Sessions, Memory Bank). - Microsoft Foundry Agent Service — chosen by Microsoft-365/Entra/Azure enterprises so the agent inherits existing IT governance and A2A interop. - A bank on AWS core-banking — picks AgentCore over Agent Engine purely because cross-cloud identity and egress would otherwise be a project.

Frameworks as the portable orchestration layer: - LangGraph — the controllable graph orchestration teams deploy onto a runtime to keep logic portable (the bank's choice). - CrewAI — role-based crews where readable multi-agent structure matters more than low-level control. - LlamaIndex — the base for RAG-first agents where retrieval is the core job. - OpenAI Agents SDK / AgentKit — lightweight primitives plus a visual builder and connector registry for OpenAI-standardized teams. - Microsoft Agent Framework — deliberately runs both self-hosted and hosted-on-Foundry, embodying the overlap row.

SaaS verticals owning a domain (and appearing as tools): - Sierra — transactional customer service; bought when CX stays inside CX. - Decagon — omnichannel support tuned for speed and consistency. - Salesforce Agentforce — CX/sales inside Salesforce, per-conversation pricing, mandatory Data Cloud. - NiCE Cognigy — contact-center voice/messaging for stacks already on it. - Glean — permission-aware enterprise knowledge search, frequently consumed as a tool by an owned agent rather than as the platform.

Pause and recall¶

Name the three families and one thing each optimizes for.
What actually differentiates two same-family hyperscaler runtimes for a given company?
What is the overlap row, and what real composition does the bank build from it?
Why is a flat vendor list useless? What does the map add?
How do you compare two SaaS vertical agents — by features or by something else?
What does a framework give you, and what does it not give you, that a runtime does?
Why is the "three aisles in a store" picture wrong, and what replaces it?
What makes the map go stale, and how do you keep it current?

Interview Q&A¶

Q1. We've narrowed to a hyperscaler runtime. AgentCore vs Vertex Agent Engine — how do you decide? A. By gravity, not features. Both host any framework and any model with managed ops, so the feature tables look like twins. The decider is where the company's data, identity, and existing systems live. An AWS-native bank picks AgentCore because IAM/KMS/VPC/S3 line up and the boundary is nearly free to cross; on Vertex, cross-cloud identity and egress become a project. I'd also weigh model breadth (Vertex's Model Garden) and managed memory maturity if those are core. Common wrong answer to avoid: "Compare their agent feature checklists and pick the longer one." Same-family checklists match; cloud gravity decides.

Q2. A PM says "let's just use Glean for our internal agent." When is that right and when is it wrong? A. Right when the problem is permission-aware knowledge search across fragmented sources and stays there. Wrong when you need it to be the orchestration platform for workflows it wasn't built for. The better pattern is often Glean as a tool called from an owned orchestration — the overlap row — so you get its knowledge capability without making a SaaS your platform. Common wrong answer to avoid: "Glean does search, so it can be our agent platform." Domain ownership ≠ platform; forcing it makes you fight its closed orchestration.

Q3. Why isn't "framework" simply the most powerful family you should always prefer for control? A. A framework is a library; it gives you control and portability but hands you the entire ops burden — servers, tracing, identity, on-call. For a small team or modest volume, that burden costs more in engineer-months than the control is worth. The runtime gives managed ops while still hosting your framework, so you keep portable logic without owning the ops. Power without the capacity to operate it is not power. Common wrong answer to avoid: "Frameworks = full control = best." Control you can't operate is a liability, not an asset.

Q4. The bank's architecture mixes LangGraph, AgentCore, and Glean. Isn't mixing families a smell? A. The opposite — it's the mature pattern. Each family does what it's best at: LangGraph carries the portable orchestration boundary, AgentCore is the managed substrate, Glean is a replaceable SaaS-as-tool. The boundary still sits at "our code vs the machine" because the orchestration is owned and the SaaS appears only as a tool. Mixing is a smell only when no single family owns the orchestration boundary. Common wrong answer to avoid: "Pick one family for the whole system." That forces over-building or over-buying; real architectures compose.

Q5. How do you keep your landscape map from going stale? A. Treat families as verbs, not nouns. Re-check quarterly whether runtimes now host more frameworks, frameworks now ship managed clouds, and SaaS now expose more customization — all of which were true in 2026. When a new entrant appears, place it by boundary (what does it own vs you), not by its marketing family label, which is often aspirational. Common wrong answer to avoid: "The families are fixed; learn them once." The families actively converge; a stale map mis-places hybrids.

Q6. Is the choice between AgentCore and Foundry a landscape question (file 02), a build-vs-buy question (file 01), or a cost question (file 05)? A. It's a within-family landscape question: file 01 already chose the runtime family by boundary, and cost (file 05) refines later. AgentCore vs Foundry is positioning within the runtime column, decided by cloud gravity — which estate (AWS vs Microsoft) the company already runs on. If the question were "runtime vs SaaS," that's file 01; if it were "this runtime is too expensive at 100×," that's file 05. Common wrong answer to avoid: "It's purely a cost comparison." Cost matters, but cloud gravity and existing identity usually dominate the within-family choice.

Design/debug exercise (10 min)¶

Step 1 — Model it. Position the bank's support agent on the map:

Family (from file 01): hyperscaler runtime, with owned framework on top
Within-runtime gravity: AWS (core-banking + identity already on AWS)
  → AgentCore over Agent Engine / Foundry
Orchestration: LangGraph (owned, portable) deployed on AgentCore
SaaS-as-tool: Glean for internal knowledge lookups, called as one tool
What each family does: framework=portable logic, runtime=managed ops,
  SaaS=replaceable domain capability. Boundary stays at "our code vs machine."

Step 2 — Your turn. Position the bank's internal-ops agent on the map: same family, same runtime gravity, but list which SaaS-as-tool components (if any) it composes — does it need Glean, a document store, an internal KYC service? Then position one agent from your own backlog: family, within-family gravity, owned orchestration, and any SaaS-as-tool.

Step 3 — Reproduce from memory. Redraw the three-column map (optimizes-for / real players / give-up / get / overlap) cold, then draw the composition diagram from section 5 connecting it to file 01: the family you chose there becomes the column you read here, and the overlap row is where the real architecture lives. If you can reproduce both, you can place any new platform you meet.

Operational memory¶

This chapter turned a flat vendor list into a structured map: three families grouped by boundary, positioned by what each optimizes for, with an overlap row where real architectures actually live. The important idea is that family tells you what you give up, optimization tells you what you get, and the overlap tells you what you can compose — and that within a family, the decider is cloud gravity, not the feature checklist.

You learned to read the map in three moves: group by family, position by optimization, and check the overlap row for compositions. That solves the "which player" problem the boundary decision left open — for the bank, AgentCore wins over its same-family rivals purely because the bank's data and identity already live on AWS, and the real architecture composes LangGraph + AgentCore + Glean-as-tool rather than forcing one family.

Carry this diagnostic forward: when two platforms look identical, push on one concrete requirement and watch where they diverge — it's almost always cloud gravity or the ownership boundary, not the feature list. And keep the map current; the families converge every quarter.

Remember:

Group by family (boundary), then position by optimization, then check the overlap row for compositions.
Same-family runtimes are differentiated by where your data and identity already live, not by feature parity.
Compare SaaS verticals by which domain they own and whether your problem stays in it — not by features.
Real architectures compose families: framework owns the boundary, runtime is substrate, SaaS verticals are replaceable tools.
Families are verbs, not nouns — runtimes host frameworks, frameworks ship managed clouds; re-check the map quarterly.
A framework gives you a library and a bill, not managed ops.

Bridge. Now we can name the players and place them. But "AgentCore optimizes for cloud-native security" and "LangGraph optimizes for control" are still slogans — they don't tell us whether a given platform can actually orchestrate, call tools, hold memory, do RAG, run multi-agent, trace, eval, gate on humans, and swap models well enough for this use case. To choose between two real candidates we need to turn slogans into a defensible score. The next file builds the capability rubric and runs the bank's candidates through it. → 03-capability-evaluation-rubric.md