How to Select an AI Agent Runtime for Production

The agent platform market grew up fast. Two years ago "deploy an AI agent" meant pasting a system prompt into a notebook. Today there are at least seven serious platforms competing for the production workload, and they make very different bets about where the trust boundary lives, who owns the runtime, and what "declarative" is allowed to mean.

This post compares Agyn against the six platforms we hear about most when teams evaluate alternatives: AWS Bedrock AgentCore, Cloudflare Agents, Google AX, Anthropic Claude Managed Agents (the platform behind Claude Code Cloud), kagent, and Vercel Open Agents. The seven criteria we score on are the capabilities you cannot retrofit later: self-hosting, multi-vendor agents, per-MCP-server isolation, declarative configuration, serverless execution, credential isolation, and zero-trust networking.

The headline, after a careful pass through each vendor's current documentation: no other platform scores above 3.75 out of 7 — and only AgentCore clears 3.0; the rest sit between 2.0 and 2.75. Each competitor skips two or three capabilities, or only delivers them as something you assemble yourself rather than something the platform ships. They aren't bad platforms — they're platforms that made a different trade-off. Agyn is the one that refuses to.

If you read nothing else, here is the matrix:

Agent platform comparison at a glance

Click the image to enlarge. Legend: ● Built-in (default platform property, 1.0) · ◐ Opt-in (ships in product, requires config, 0.5) · ◔ Composable (documented vendor/community recipe to assemble from primitives, 0.25) · ○ Absent (0).

The pattern that comes out of the matrix is the one we'll spend the rest of the post on: every other platform forces a trade-off — managed convenience against self-hosting, declarative config against an imperative SDK, or developer ergonomics against credential safety. Agyn was built to refuse those trade-offs.

The seven capabilities that decide a platform

Each criterion below is something we've watched real teams discover the hard way, late, in production.

• Self-hostable — can you run the orchestration loop on your own infrastructure? Not the sandbox, not the inference endpoint — the loop. Regulated industries, sovereign deployments, and air-gapped environments need this to be a hard yes.
• Multi-vendor agents — does the platform ship pre-built agents from multiple vendors (e.g., Claude Code from Anthropic, Codex from OpenAI) ready to deploy? Single-vendor platforms automatically can't run the competitor's agent.
• Per-MCP-server isolation — does each MCP server run in its own container (or equivalent strong boundary), so a compromised tool can't reach another tool's filesystem or secrets? Speaking MCP is table-stakes by 2026; isolating MCP servers from each other is not.
• Declarative config — agent definitions in version control as declarative manifests (YAML / HCL / CRDs), peer-reviewed, applied by automation — not imperative code or a web form.
• Serverless — agents spawn on demand, scale horizontally under load, and scale to zero when idle. The alternative is a long-running process per agent instance that keeps eating CPU and memory while it sits idle between requests.
• Credential isolation — tool secrets never reach the LLM context. The model is the most untrusted process you've ever put in front of your internal systems; treat it like one.
• Zero-trust networking — per-identity, deny-by-default network policy enforced at the platform layer, not assembled from RBAC + NetworkPolicy + service mesh by hand.

A note on weighting: we score every criterion equally. A security-conscious buyer would reasonably weight credential isolation and zero-trust at 2×, in which case Agyn's lead widens — so the equal-weighted view here is the conservative one.

Now, platform by platform, ordered by score.

Cloudflare Agents: a TypeScript SDK to build agents on, not a ready-to-use platform

What it is. Cloudflare Agents is an open-source TypeScript SDK (MIT) for building stateful AI agents on Cloudflare Workers. Don't confuse the SDK with Workers AI (model inference) or AI Gateway (an LLM-call proxy) — Agents uses both but is neither.

Cloudflare terms used in this section

• Workers — Cloudflare's serverless runtime; runs JavaScript/TypeScript (and WASM) in V8 isolates, not containers.
• Durable Objects (DO) — Cloudflare's stateful compute primitive: a single-threaded, globally-addressable object with embedded SQLite. The substrate the Agents SDK is built on.
• McpAgent — the base class for building an MCP server on Cloudflare; each one is backed by its own Durable Object.
• WebSocket Hibernation — lets a Durable Object holding open WebSocket connections be evicted from memory and re-hydrated on the next message, pausing compute billing while state persists (Cloudflare's scale-to-zero mechanism).
• Mesh — Cloudflare's private-networking product for agents: encrypted private-IP connectivity between agents, services, and users; integrates with the Agents SDK. A zero-trust posture requires composing Mesh with Cloudflare's broader Zero Trust suite (Gateway, Access).
• Outbound Workers for Sandboxes — a network-layer credential broker that TLS-intercepts a sandbox's outbound traffic and injects credentials, so the workload never holds the token (launched April 2026).
• Workers AI — model inference for open-source models. AI Gateway — an observability/control proxy that sits in front of any model provider (and can broker LLM keys).
• wrangler.jsonc — Cloudflare's deployment manifest, declaring bindings (Durable Objects, secrets, routes).

What it does well. McpAgent gives real isolation: each MCP server you author is its own Durable Object with its own state and env — credentials the MCP server uses sit in that DO, separate from the main agent. WebSocket Hibernation is the cleanest scale-to-zero pattern out there — an Agent holding open sockets can be evicted from memory and re-hydrated on the next message, with Duration billing paused and SQLite state intact. For sandboxed shell tools reaching internal services, Outbound Workers for Sandboxes TLS-intercepts the sandbox's outbound HTTP(S) with an ephemeral per-sandbox CA and injects credentials at the network layer — a CLI inside the sandbox never holds the real token. The developer experience is genuinely polished.

Where it forces a trade-off. One pattern runs through everything below: Cloudflare ships rich primitives, but secure defaults are opt-in — every isolation, broker, and policy is something you wire up and implement yourself, not something the platform gives you out of the box.

1. MCP isolation only if you rewrite the server in their SDK. The Durable Object isolation applies to MCP servers authored as McpAgent classes in TypeScript. Existing Go/Python/Rust MCP servers can't run isolated on Cloudflare — Workers run isolates, not containers — so you'd rewrite, or host off-platform without the isolation.
2. Not self-hostable. The Workers runtime (workerd, Apache-2.0) is open source, but the Agents SDK requires Durable Objects — which is not part of workerd and has no on-prem equivalent. The agent loop runs only on Cloudflare's edge. The cleanest disqualifier for regulated, sovereign, or air-gapped environments.
3. Zero-trust is composable, not built-in. Mesh is Cloudflare's private-networking product for agents — encrypted private-IP connectivity between agents, services, and users. It isn't sold as a zero-trust product; for an actual zero-trust posture you compose it with Cloudflare's broader Zero Trust suite (Gateway, Access, identity policies). Default fetch() egress from a Worker is unfettered.
4. Config is split and Cloudflare-specific. Behaviour lives in imperative TypeScript classes; bindings in wrangler.jsonc (or the Terraform provider). Declarative for infra, imperative for the agent — and the deployment unit only runs on Cloudflare.

When to choose it: teams ready to build a solution on top of Cloudflare's TypeScript primitives — not teams looking for a ready-to-use platform. Best fit if you're already a Cloudflare/Workers shop and have the TypeScript bandwidth to implement the agent loop, author the MCP servers, and accept Cloudflare-edge vendor lock-in as the trust boundary.

AWS Bedrock AgentCore: the deepest Claude integration of the managed bets

What it is. Bedrock AgentCore is AWS's managed runtime for production agents — launched on 2025-10-13 across nine regions, the most architecturally complete managed option, with Runtime, Gateway, Identity, Memory, Code Interpreter, Browser, and Observability as composable primitives. Each session lands in a dedicated Firecracker-style microVM; billing is by active vCPU/GB-hour with idle LLM waits excluded.

What it does well. Session-level microVM isolation by default is stronger than most self-hosted platforms ship. AgentCore Identity is a real OAuth token vault. And the Claude integration runs deep: AWS publishes a Claude Code web-agent sample and a Claude Agent SDK deployment starter, the Marketplace AI Agent Starter Pack ships pre-configured with Claude, and Claude Platform on AWS launched in May 2026 (native Managed Agents, MCP connector, Agent Skills via IAM credentials). That's why Multi-vendor agents is ● — Marketplace catalogs 800+ agents from many vendors and Bedrock supports multiple model providers, even though Codex is absent (OpenAI competes with Bedrock).

Where it forces a trade-off.

1. Not self-hostable. AgentCore runs only in AWS regions on AWS-managed microVMs. No on-prem, air-gapped, or BYO-Kubernetes option. AgentCore Identity can run alongside on-prem workloads, but the runtime cannot.
2. Declarative config is mixed. CloudFormation shipped at launch (October 2025); CDK and Terraform landed later, in April 2026 (not at launch, as some write-ups still claim). The Managed Harness lets you declare an agent as model + system_prompt + tools — genuinely declarative. But the custom-container path puts the agent loop in imperative Python/Node, and the resource graph is AWS-dialect (IAM, ECR, KMS, VPC), not a portable manifest.
3. Credential isolation depends on whether the supplier supports OAuth. AgentCore Identity stores OAuth tokens and API keys in a KMS-encrypted vault. If the supplier supports OAuth, long-lived credentials (refresh tokens, client secrets) stay in the vault — but the short-lived access token is still handed to the agent to use, and lives in its memory during the call. If the supplier doesn't support OAuth, the long-lived API key itself has to be fetched into the agent and can't really be isolated at all. Either way, the agent process holds some credential at the moment of use — AgentCore isn't a transparent broker.
4. No per-identity zero-trust networking. PrivateLink and VPC endpoints exist, but AWS's own documentation states that VPC endpoint policies cannot restrict OAuth callers by identity. Network segmentation is subnet-shaped, not per-workload-identity. You can approximate zero-trust by composing security groups, IAM roles, and VPC endpoint policies — but that's AWS-stack composition, not what AgentCore itself enforces.

When to choose it: AWS-locked enterprise teams that want deep Bedrock + Claude integration and have settled the regulatory questions.

Google AX: an open K8s runtime built around Google ADK

What it is. Google AX — "Agent eXecutor" — is Google's open-source distributed agent runtime, announced 2026-05-21 at github.com/google/ax. It's a different artefact from the A2A protocol (Linux Foundation) and the ADK SDK — AX sits below both as the runtime that executes agents and speaks A2A as one of several pluggable transports. The launch blog flags it as preview-grade: "these interfaces will change before a stable release."

What it does well. Durable execution as a primitive — the controller writes an event log for resumption and trajectory branching. A2A is first-class through the in-tree bridge adapter, so any A2A-compliant agent drops in (and wrapping Claude Code or Codex as A2A servers is a supported path — hence ◔ Composable on Multi-vendor agents). Sandboxed code execution via GKE Sandbox and Kata Containers. It's Apache-licensed and self-hostable on any Kubernetes via the companion Agent Substrate project.

Where it forces a trade-off.

1. Agents speak Google's gRPC. Remote agents implement Google's native AgentService interface (proto/ax.proto). Three adapters ship in-tree (ADK-Python, A2A bridge, experimental Colab); anything else must be wrapped or reimplement the contract.
2. MCP is aspirational in AX itself. The architecture diagram lists MCP; the repo's actual protocol surfaces are A2A and AX's own gRPC. MCP support in an AX deployment arrives via the agent you host (an ADK agent using FastMCP), not from AX — so per-MCP-server isolation is ○ for the runtime.
3. Declarative config is mixed. The controller YAML is declarative for the actor catalogue, but remote agents are imperative gRPC services. No agent-level CRD.
4. The safety story lives in a different product. Google's vaulted-credential model (Agent Identity, Agent Gateway, "agent can never access the raw credential") and zero-trust posture (mTLS, DPoP, IAP for Agents) are part of the managed Gemini Enterprise Agent Platform (formerly Vertex AI Agent Builder) — not part of google/ax. A self-hosted AX install ships neither.

When to choose it: Kubernetes teams using Google ADK who need cross-vendor A2A interop, in non-regulated workloads where you can add credential isolation and zero-trust yourself.

Anthropic Claude Managed Agents: the platform behind Claude Code Cloud

What it is. Claude Managed Agents (public beta, April 2026) is Anthropic's hosted platform for building and operating agents — sandboxed code execution, checkpointing, credential management (Vaults), scoped permissions, MCP connectors, and tracing, all defined through a public API. Claude Code Cloud (claude.ai/code) — the asynchronous coding agent that clones your repo, runs the loop, and opens a PR — is the flagship app built on this platform. We compare the platform here, since that's the apples-to-apples competitor to AgentCore and the rest; Claude Code Cloud is one application on top of it.

What it does well. A few things are genuinely distinctive. Anthropic-curated MCP connectors work without manual auth setup — closer to a one-click integration than other platforms. The git credential model is unique in the category: a dedicated proxy enforces invariants like "pushes go to the working branch," and the model never sees the GitHub token. Vaults is a server-side credential proxy where "vault credentials never enter the sandbox," so MCP-server secrets stay off the model. Per-session VMs with a ~7-day filesystem cache give a stateful per-task workspace without operator effort. And unlike the consumer app, the platform lets you define agents and environments through an API rather than a fixed agent — which lifts the declarative-config rating to ◐.

Where it forces a trade-off.

1. Not self-hostable. The agent loop — the LLM-calling, tool-dispatching cycle — runs on Anthropic by design. The execution sandbox where tool code runs can be relocated to a third-party runner, but the loop driving it stays at Anthropic. Anthropic has recently made it easier for regulated industries (e.g., healthcare) to sign up, but the platform still runs on their infrastructure rather than yours.
2. Claude-only, no Codex. You define Claude-based agents; there's no Codex or non-Claude runtime, and Claude Code Cloud is the platform's own flagship app rather than a deployable agent — hence ○ on Multi-vendor agents.
3. Declarative-by-API, not by manifest. Agents and Environments are created through a public API (the environment's egress allowlist is even expressible as JSON), which is more GitOps-friendly than the consumer app's web form — but it's imperative SDK usage, not a declarative manifest like a CRD or HCL module.
4. Credential isolation is partial. Vaults is MCP-only: every credential binds to an mcp_server_url. Non-MCP, non-git tool secrets still sit in env vars the model can read.
5. Zero-trust is per-environment, not per-identity. MCP Tunnels (mTLS, outbound-only, customer-held certificate) plus per-environment egress allowlists give a real network-layer posture — but it's applied per environment, not per agent identity.

When to choose it: teams building Claude-only agents on Anthropic-hosted infrastructure, who don't need self-hosting and accept Anthropic as the runtime.

kagent: the CNCF-native option that treats Kubernetes RBAC as enough

What it is. kagent defines AI agents as first-class Kubernetes objects — created at Solo.io, donated to CNCF in early 2025, 1,000+ stars and 300+ contributors. A Go controller watches custom Kubernetes resources (Agent, ModelConfig, RemoteMCPServer); a Python engine that runs agents written for AutoGen, LangGraph, CrewAI, or Google's ADK drives the loop; agentgateway, an Envoy-based gateway, fronts MCP tool servers.

What it does well. Custom Kubernetes resources are a strong declarative config story — agents slot into existing Argo/Flux pipelines with zero new tooling. The open-source distribution ships pre-built agents for infrastructure operations (Kubernetes, Istio, Helm, Argo, Cilium, Prometheus, Grafana) — though none of them are Claude Code or Codex, which is why Multi-vendor agents is ○ here. agentgateway is a real Envoy-based MCP gateway with OAuth, and built-in MCP servers run as their own services rather than inside the kagent process.

Where it forces a trade-off.

1. Always-on. Agents run as long-lived Pods. There is no scale-to-zero or per-invocation model in the core; you'd add KEDA or Knative yourself, and the new SandboxAgent resource (one shared instance) is the opposite of scale-to-zero. Idle agents keep running Pods, paying for compute that's doing nothing — which is why kagent is the wrong fit for many short-lived agents.
2. No credential isolation. LLM API keys live in Kubernetes Secrets, mounted into the agent Pod as env vars; the agent's code reads them directly. agentgateway's OAuth checks who's calling in to the MCP gateway; it doesn't manage the credentials MCP servers use to call out to suppliers.
3. Zero-trust is BYO. RBAC, agentgateway, and NetworkPolicy patterns are provided; mTLS, restricting which outbound destinations are allowed, and a fresh identity that expires after each call are not enforced. Solo's "agentic zero-trust" recipe composes kagent + agentgateway + Istio, but the burden is on the operator.

When to choose it: Kubernetes platform / SRE teams with a handful of long-lived agents in always-on workloads, comfortable treating Kubernetes' security model as sufficient.

Vercel Open Agents: a clean template, not a platform

What it is. Open Agents is a reference template from Vercel Labs (MIT, April 2026) — the canonical fork-and-adapt blueprint for a background coding agent on Vercel. It is create-next-app for agents, not a supported product with an SLA. Three layers: a Next.js web app, a Vercel AI SDK loop wrapped in the Workflow SDK for durable execution, and Vercel Sandbox (Firecracker microVMs) for code execution, with the agent running outside the sandbox and calling in via tools.

What it does well. The architecture is clean, and the safety primitives are better than the "template" framing suggests. AI Gateway BYOK with OIDC tokens keeps LLM provider keys out of the agent function in the recommended config. The Sandbox firewall does SNI-based egress filtering, CIDR blocks, and runtime-mutable policy — a real (if sandbox-scoped) zero-trust posture. Active-CPU billing approximates scale-to-zero.

Where it forces a trade-off.

1. Not self-hostable as shipped. The AI SDK is Apache-2.0 and the Workflow SDK has a documented Postgres self-host, but Sandbox, Fluid compute, and AI Gateway are closed Vercel services. The template assumes Vercel; running the loop elsewhere means rebuilding around 3–4 swapped components.
2. Config is imperative. Agent behaviour — model, prompt, tools, sandbox lifecycle — is TypeScript in modules and route handlers. No agent CRD, no YAML, no Terraform for the agent itself; vercel.json describes only the Next.js deployment.
3. No platform-managed MCP isolation. The AI SDK can call remote MCP servers over HTTP, but Vercel doesn't host them, sandbox them, or enforce a per-server boundary — you bring your own MCP servers and host them wherever. The "separation" is just MCP-over-HTTP, not something the platform provides.
4. Credential and zero-trust coverage stops at the sandbox. AI Gateway brokering protects the LLM key, and the sandbox firewall protects outbound traffic from sandboxed code. But any other secrets the agent needs (databases, third-party APIs) still sit as plain environment variables in the agent function, and the agent function's own network calls aren't covered by the sandbox firewall — which is why both land at ◐.

When to choose it: product engineering teams on Vercel building a coding-agent SaaS (Devin-/Cursor-shaped), forking the template as a starting point.

Agyn: a Kubernetes platform with credential isolation and zero-trust by default

What it is. Agyn is an open-source agent platform — it runs your agents and gives you everything you need to operate them: identity, networking, configuration, monitoring, and governance, all on top of Kubernetes. Agents run as Docker containers that the platform treats as black boxes. MCP servers run as separate containers alongside them. Credentials and network identity are managed by the platform, not the agent. The whole setup — agents, models, tools, identity rules — is defined in Terraform and visible from a management console. Architecture is documented in the Agyn paper (arXiv:2605.27575). Commercial support and SLAs are available via agyn.io.

What it does well. Multi-vendor agents — Claude Code (Anthropic), Codex (OpenAI), and Agyn's own agent ship as containers ready to deploy, no agent code to write. Switching between them is one config line — no rewrite, no harness change. Per-MCP-server isolation — each MCP server runs in its own container with credentials scoped to it. Credential isolation by design — an egress gateway injects credentials at the network layer, so the LLM never sees a tool secret. Zero-trust networking — each agent gets its own cryptographic identity (OpenZiti), with access to internal services blocked unless explicitly allowed, enforced at the network rather than in the application. Stateful, serverless, horizontally scalable — agents keep state across invocations, start on message, scale out under load, shut down when idle. Ready to use — configure in Terraform, grant access from the management console, share with employees.

Where it forces a trade-off.

1. Not a framework for building agents from scratch. Agyn runs pre-built agent containers — Claude Code, Codex, and Agyn's own open-source agent ship ready to deploy. Custom agents are packaged as Docker images and integrated through Agyn's interfaces; there's no SDK for writing the agent loop inside the platform (the way Cloudflare and Vercel offer). Teams that want platform-provided agent-authoring primitives will find a different model.
2. Requires Kubernetes. Any conformant distribution works, but you need at least one cluster. Teams without Kubernetes experience should weigh the operational work.

When to choose it: teams that want to use agents rather than build them — take Claude Code, Codex, or a third-party agent and configure the operational harness around it (tools, skills, governance, monitoring) so it fits your business workflows. Especially relevant for teams looking for an on-prem solution with strong security requirements who run on Kubernetes. The closest managed alternative is AWS Bedrock AgentCore — Agyn trades AWS's managed convenience and Marketplace breadth for self-hosting on your own infrastructure, network-layer zero-trust, and MCP servers running in their own containers.

When to choose each platform

Your situation	Platform
Kubernetes team that wants to use pre-built agents (Claude Code, Codex) and configure the operational harness for their workflows; need an on-prem solution with strong security requirements	Agyn
Cloudflare-shop team ready to build a solution on TypeScript primitives (not adopt a ready-to-use platform)	Cloudflare Agents
AWS-locked enterprise; deep Bedrock + Claude integration	AWS Bedrock AgentCore
Building Claude-only agents on Anthropic-hosted infrastructure	Claude Managed Agents
Kubernetes team using Google ADK; cross-vendor A2A interop, non-regulated	Google AX
Kubernetes / SRE team; few long-lived agents in always-on workloads	kagent
Product team on Vercel building a coding-agent SaaS	Vercel Open Agents

Coming from another platform

• From AWS Bedrock AgentCore? Agyn gives you the same serverless execution model, self-hosted on your own Kubernetes, with declarative Terraform configuration that survives a move off AWS. Credentials are injected by an egress gateway at the network layer — the agent never holds a tool secret, regardless of whether the supplier supports OAuth.
• From Cloudflare Agents? You keep stateful, scale-to-zero agents and move the agent loop off Cloudflare's edge onto your own Kubernetes. Credential injection happens at the network layer for every outbound call by default — not opt-in per endpoint, and not just for the sandbox. Internal services are blocked unless explicitly allowed, per agent identity rather than per Worker.
• From Google AX? Agents are Docker containers integrated through Agyn's interfaces — no vendor gRPC contract to implement. Credential isolation and zero-trust are part of the platform, not a separate managed product.
• From Claude Managed Agents (or Claude Code Cloud)? Agyn runs Claude Code as one of many agent containers on your own infrastructure. The managed-runtime and eligibility constraints become non-issues; tool secrets are injected at the network layer for every call (not just MCP and not just git), and you're not locked to Claude as the only model.
• From kagent? You keep the Kubernetes-native, declarative-config mental model and gain serverless scale-to-zero, network-layer credential injection that keeps secrets out of the agent process, and per-agent identity with deny-by-default access to internal services.
• From Vercel Open Agents? You graduate from a fork-and-adapt template into a ready-to-use platform. Agents run as Docker containers (not hand-written TypeScript orchestration), and the whole setup — agents, models, tools, identity rules — is declared in Terraform.

Get started

• Docs and quickstart — docs.agyn.io
• Source — github.com/agynio/platform (AGPL-3.0)
• Book a demo — agyn.io/demo
• Paper — Agyn: An Open-Source Platform for AI Agents (arXiv:2605.27575)
• Architecture — github.com/agynio/architecture

Related reading: Introducing Agyn, Why isolated sandboxes are a hard requirement for AI agents, Agentic AI: from demos to durable engineering.

FAQ

What's the best open-source alternative to AWS Bedrock AgentCore? Agyn is the closest functional match: same serverless execution model, same MCP-first tool architecture, plus network-layer credential injection — self-hosted on the Kubernetes you already run, with declarative Terraform configuration that doesn't lock you into a single cloud's IaC dialect. AgentCore's Claude integration is genuinely deep (samples, Marketplace, Claude Platform on AWS), but the runtime can't leave AWS.

Can I run Claude Code on my own infrastructure? Yes — Claude Code runs as one of many agent containers inside Agyn. The local Claude Code CLI runs unchanged; Agyn provides the surrounding platform — per-MCP-server isolation, network-layer credential injection, and zero-trust networking — that the cloud product doesn't give you on-prem.

What's the difference between Agyn and kagent? Both are open-source, Kubernetes-native, and use declarative configuration (custom Kubernetes resources are kagent's strongest property, on par with Agyn's Terraform). The differences are operational: Agyn is serverless where kagent runs long-lived Pods; Agyn injects tool credentials at the network layer so the agent process never holds them, where kagent mounts API keys into the agent Pod as env vars; Agyn pairs each agent with a per-identity zero-trust network policy where kagent gives you RBAC + NetworkPolicy as building blocks.

How does Cloudflare Agents compare to Agyn? Cloudflare Agents is a platform for building agents — coding agents, MCP servers, and others — on top of Cloudflare's primitives (Durable Objects, Outbound Workers, Mesh). The primitives are rich, but credential isolation, zero-trust networking, and per-MCP-server isolation are things you build yourself, not defaults the platform enforces. The SDK requires Durable Objects, so it's also vendor-locked to Cloudflare's edge with no on-prem path. Agyn ships those security properties out of the box and runs on your own Kubernetes — choose Cloudflare if you're already on their edge and have the TypeScript bandwidth to build.

Is Google AX a viable alternative? For an open Kubernetes runtime around Google ADK with A2A interop, yes — in non-regulated workloads. For credential isolation and zero-trust, no: those live in Google's managed Gemini Enterprise Agent Platform, not in google/ax. You'd be running AX plus something else for the safety story.

Is Vercel Open Agents a platform I should evaluate? It's a template, not a platform — the canonical Vercel Labs starter for fork-and-adapt coding-agent products. Its safety primitives (AI Gateway brokering and the Sandbox firewall) are better than the "template" label suggests, but they're scoped to sandboxed tools and assume Vercel as the runtime. Fork it to build one product; choose a multi-tenant platform to operate an agent fleet.

Does Agyn support MCP? Yes, first-class — and each MCP server runs in its own container, with credentials scoped to that container. The LLM never sees a tool secret.

Does Agyn require Kubernetes? Yes. Agyn runs on any conformant Kubernetes cluster — EKS, GKE, AKS, OpenShift, on-prem, air-gapped, and kind all work. No specific distribution or cloud required.