Kong AI Gateway or Bedrock AgentCore? You're Asking the Wrong Question

How to think about the agentic stack when both layers claim the word "gateway"

Every second conversation I have with a platform team right now goes something like this:

"We're standing up our first production agent on AWS. AgentCore gives us runtime, memory, identity, tool access, observability — the lot. Why would we put another gateway in front of it?"

It's a fair question, and the honest answer is not "because Kong is better than AgentCore." The two things solve different problems that happen to share vocabulary. The interesting question isn't which one — it's where does the control point live, and who has to move when something changes.

Let me make that concrete.

The scenario

You're building a claims triage agent for a mid-size insurer. It reads a claim, pulls policy details from an internal API, checks a fraud-scoring service, summarises, and recommends an action. Multi-step, tool-calling, running in a loop until it's done.

You have two broad architectures available.

Path A: AgentCore end to end

AgentCore has matured fast. As of mid-2026 you get Runtime for serverless execution with session isolation and eight-hour windows, Memory for short and long-term state, Identity for inbound and outbound auth, Gateway to turn your APIs and Lambdas into MCP tools, Policy to gate tool access, and — since June — Harness, a config-driven agent loop that removes orchestration code entirely.

This is genuinely good. If your entire world is AWS, you can go from laptop to production remarkably quickly, and you're not maintaining a scrap of infrastructure.

You're also making a decision you may not have noticed making: your AI governance now lives in a control plane that is separate from the one governing the rest of your API estate, and is scoped to one cloud.

Path B: Kong in front, AgentCore behind

The alternative isn't replacing AgentCore. It's putting a provider-neutral connectivity layer between your agents and everything they talk to — models, tools, and other agents — while AgentCore keeps doing what it's good at: running the thing.

This isn't a hypothetical. Kong's own AWS reference architecture is built exactly this way, with AgentCore described as the managed execution layer for agents and MCP servers, and Kong sitting across the data path as the governance layer.

So what does that actually buy you?

What changes for developers

One API shape, forever.

Kong's AI Proxy Advanced plugin accepts requests in OpenAI format and translates to whatever the target provider speaks. Your agent code opens an OpenAI-compatible client, points it at a Kong route, and stops caring what's behind it:

_format_version: "3.0"
plugins:
- name: ai-proxy-advanced
  route: claims-agent-llm
  config:
    balancer:
      algorithm: priority
    targets:
    - route_type: llm/v1/chat
      weight: 100
      model:
        provider: bedrock
        name: anthropic.claude-sonnet-4-5-v1:0
        options:
          bedrock:
            aws_region: ap-southeast-2
      auth:
        allow_override: false
    - route_type: llm/v1/chat
      weight: 0          # standby
      model:
        provider: azure
        name: gpt-4o
      auth:
        header_name: Authorization
        header_value: Bearer ${{ env "key" }}

Swapping the primary model, adding a fallback in a different cloud, or shifting weight during an incident is a config change reviewed in a pull request. No application redeploy. No SDK swap. No "which team owns the agent repo again?"

Credentials leave your application entirely.

The agent holds a consumer key. Kong holds — or better, assumes an IAM role to obtain — the actual provider credentials. Rotation is a platform operation, not a coordinated release across every agent that talks to a model.

Local dev looks like production.

Kong runs DB-less in a container on a laptop with the same declarative config that runs in your cluster. Developers test against real policy — the same prompt guards, the same rate limits — rather than discovering in staging that governance breaks their happy path.

What changes for platform and DevOps

This is where the argument actually gets won, so let me be specific rather than hand-wavy.

Policy as code, in the pipeline you already have. decK turns your AI policy into declarative YAML that diffs, reviews, and syncs. If you've already built APIOps for your APIs, LLM and MCP governance drops into the same pipeline — same Git workflow, same approvals, same drift detection. Not a second discipline for a second control plane.

Cost control that survives an agentic loop. A chat app makes one call. An agent makes forty, and a badly behaved one makes four hundred. Token-based rate limiting per consumer, semantic caching backed by MemoryDB or Redis, and per-team usage attribution are the difference between a surprise invoice and a budget. Semantic caching in particular pays for itself fast in loops, where agents re-ask near-identical questions across iterations.

One place to answer "what did our AI actually do?" Kong emits OpenTelemetry spans for AI, MCP, and A2A traffic into your existing observability stack. AgentCore's observability is excellent — and lands in CloudWatch. If your SRE team lives in Datadog or Grafana, that's either an integration project or a blind spot.

A kill switch that doesn't need a deploy. Compromised agent, runaway spend, prompt injection incident — revoke the consumer at the gateway. It stops immediately, and it stops for every model and tool that agent can reach, regardless of who wrote the agent or which framework it uses.

Governance that outlives the platform decision. This is the one I'd put in front of an architecture board. If your organisation adds Azure OpenAI next year, or brings a model in-house for data residency, or acquires a company running on GCP — with Kong, the governance layer doesn't move. Your policies, your consumers, your audit trail, your cost attribution all stay put. Without it, you're rebuilding the control plane per cloud.

The naming collision, addressed directly

Both products use "gateway" for genuinely different scopes, and this causes real confusion in design reviews. Worth being precise:

That last row matters. Kong doesn't host agents, doesn't manage memory, doesn't sandbox code execution. If you're evaluating Kong as an AgentCore replacement, you'll find a large hole where the runtime should be. That's not a gap in the product; it's a different product.

Where this argument doesn't hold

I'd rather you trust the rest of this post, so here's the honest counterweight.

If you're all-in on AWS and intend to stay there, AgentCore alone is a reasonable answer. Single cloud, Bedrock-only, one team, no significant existing API estate — adding Kong buys you optionality you may never exercise, at the cost of an extra network hop and another runtime to operate. Optionality isn't free, and "we might go multi-cloud" is not a requirement.

A gateway only governs what traverses it. This is the failure mode I see most often. If your agent calls a tool whose response comes back through a path that doesn't pass the proxy — a direct SDK call, an SDK-level MCP client, a callback — that content is ungoverned no matter what your gateway config says. Indirect prompt injection lives precisely in those gaps. Map your actual data paths before you claim coverage; a north-south control point is not the same as full coverage.

Latency is real. An extra proxy hop is milliseconds, which is noise against LLM inference time — but in a forty-step agentic loop, milliseconds compound. Measure it rather than assuming it's free.

Two control planes need clear ownership. If AgentCore Policy and Kong plugins both gate tool access and nobody has decided which is authoritative, you've built a debugging nightmare rather than a governance layer. Pick: identity and runtime isolation in AgentCore, traffic policy and cost governance in Kong, and write it down.

The shape I'd recommend

For most enterprises I talk to — particularly regulated ones — the sane architecture is boring:

• AgentCore runs the agent. Runtime, session isolation, memory, code interpreter. Let AWS operate that.
• AgentCore Identity handles workload identity. It's tightly integrated and it's good.
• Kong governs the data path. Every model call, every MCP tool invocation, every A2A hop crosses a policy point you control, that reports to your observability stack, and that doesn't belong to a single vendor.

The pitch isn't "Kong instead of AgentCore." It's that the layer deciding what your agents are allowed to talk to should not be the same layer that a single cloud provider also controls — because the day you want to change something, that's the layer you'll need to be free to move.

Build on AgentCore. Just don't let it be the only place your policy lives.

Kong's reference architecture for this pattern on EKS — including Bedrock, AgentCore, MemoryDB-backed semantic caching, and Kong Identity — is published at Kong/guidance-for-kong-genai-mcp-and-a2a-gateways-on-aws.