← Field Notes

Field note · Multi-cloud architecture · July 2026

Designing a portable agent platform across AWS, Azure and Google Cloud

Portability should preserve business contracts, evidence and authority boundaries, not flatten three mature cloud platforms into the least capable common denominator.

AudienceCTOs · enterprise architects · multi-cloud platform teams
PerspectivePortable agent control-plane architecture
Reading time18 minutes
Portable contractsIdentity context · typed plans · MCP · A2A · OpenTelemetry · evaluation cases
AWSAgentCore
AzureFoundry + Entra + APIM
Google CloudGemini Enterprise Agent Platform

Portability means preserving contracts

A portable agent platform does not promise that one deployment manifest can reproduce every managed service. It preserves the meaning of identity, intent, tool schemas, policy facts, workflow state, evaluation cases and evidence across clouds.

Cloud-specific adapters should implement those contracts using AgentCore on AWS, Foundry and Entra on Azure, or Gemini Enterprise Agent Platform on Google Cloud.

Create a canonical request envelope

Every agent invocation should carry an authenticated principal, tenant, purpose, conversation or workflow ID, data classification, budget, requested capability and correlation ID. This envelope becomes the stable input to routing, policy, tracing and audit.

Do not make an OpenAI, Bedrock or Gemini request schema the core business contract. Translate the canonical envelope at the model gateway.

Use MCP and A2A at interoperability boundaries

MCP is useful for tools and resources. A2A is useful for task-oriented communication between independent agents. Keep capability metadata, risk, identity and evidence outside the protocol payload when the standard does not define them.

Gate every tool behind a versioned schema and capability ID. An agent should discover only the tools allowed for its identity, tenant and purpose.

Map one agent identity contract to native identity

The portable contract should distinguish the end user, agent workload, delegated authority and downstream resource identity. On AWS, map this to AgentCore Identity and IAM. On Azure, map it to Entra Agent ID, managed identities and RBAC. On Google Cloud, use Agent Identity and IAM.

Keep secrets outside prompts, memory and tool arguments. Prefer short-lived tokens and native audit trails.

Keep policy external and deterministic

Define policy facts in a cloud-neutral schema: principal, action, resource, data classification, risk, amount, environment, approval status and time. Evaluate them with AgentCore Policy, Azure API Management and Entra controls, Google Agent Gateway and IAM, or an external OPA or Cedar service.

The model can explain policy, but it cannot waive policy or approve its own exception.

Do not confuse agent sessions with workflow state

Agent sessions and memory support conversation continuity. Durable workflows own retries, timers, approvals, compensation and exactly-once business intent.

Use Step Functions, Temporal, durable application services or equivalent workflow infrastructure behind a stable workflow contract. This prevents a cloud migration from rewriting every business process around one agent SDK.

Standardize evidence before dashboards

Emit OpenTelemetry traces with consistent attributes for agent, model, tool, policy, workflow and evaluation IDs. Store golden datasets, adversarial cases and release thresholds in a portable repository.

Cloud-native systems can then enrich the same evidence: CloudWatch and AgentCore Evaluations, Application Insights and Foundry evaluations, or Agent Platform traces, topology and online monitoring.

Separate global metadata from customer data planes

A global control plane may store approved agent metadata, versions, capability definitions and release evidence. Prompts, customer documents, embeddings, credentials and raw traces should remain in the selected customer or regional data plane unless an explicit export policy permits otherwise.

This design also supports VPC, BYOC, on-premises and sovereign deployments without changing the product contract.

Reference blueprint

  1. Experience gatewayAuthenticates the caller and creates the canonical request envelope.
  2. Agent runtime adapterInvokes AgentCore Runtime, Foundry hosted agents or Agent Platform Runtime.
  3. Capability gatewayPublishes versioned MCP, HTTP and A2A capabilities with native cloud governance.
  4. Identity and policy adapterMaps workload and delegated identity to native tokens and deterministic decisions.
  5. Durable workflow layerOwns business state, retries, approval and recovery independently of model sessions.
  6. Evidence planeNormalizes OpenTelemetry, evaluation results, audit links, cost and release attestations.

Avoid false portability

Do not recreate AgentCore, Foundry or Google Agent Platform in your own Kubernetes cluster merely to claim neutrality. That transfers security, scaling, patching and evaluation responsibility to your team.

Keep the business and governance contracts portable, then deliberately use the strongest native service for the deployment boundary. Portability is an option, not an obligation to avoid managed capabilities.

Executive takeaway

The durable assets are your capability schemas, identity model, policy facts, workflow contracts, evaluation suites and evidence. Cloud runtimes are replaceable implementations around those assets.

Primary reading

  1. Amazon Bedrock AgentCore overview
  2. Azure API Management AI gateway
  3. Microsoft Foundry Agent Service
  4. Microsoft Entra Agent ID
  5. Gemini Enterprise Agent Platform overview
  6. Google Agent Identity
  7. Agent Platform Runtime
  8. Agent2Agent specification
  9. Model Context Protocol architecture
  10. OpenTelemetry documentation