AgentCore Gateway Solves Reachability. Shape and Reuse Are Still Yours.

wpnews.pro

AWS has built the whole tier, and built it well. Amazon Bedrock AgentCore now ships a serverless agent runtime, a managed agent loop with microVM isolation, agent identity, memory, Cedar-based policy enforcement on every tool call, a governed registry, OTel-backed observability, and a gateway that turns your existing APIs into MCP tools. If you have already invested in it, this post is about what is worth putting behind that gateway.

Start with the part that needs no help from anyone. AgentCore Gateway “converts APIs, Lambda functions, and existing services into Model Context Protocol (MCP)-compatible tools,” supports OpenAPI, Smithy and Lambda as tool input types, composes several sources behind one endpoint, and handles ingress and egress authentication in one managed service. Reachability, credential injection, protocol translation, IAM-backed identity: solved, managed, and more tightly integrated with your AWS estate than any third party could be.

So let us be precise about where Naftiko is and is not useful: if your APIs are already the right shape for an agent, and agents on AgentCore are the only thing that will ever consume them, only use Gateway. Two conditions for added value — and in most large estates, one of them matches.

The first is design. An OpenAPI document describes resources; an agent needs jobs. Gateway faithfully projects whatever shape you hand it, which is exactly what a projection should do, so deciding which tools should exist stays upstream work no generator can do for you.

The second is reuse. A Gateway target emits MCP, because MCP is what an agent runtime consumes. But the logic inside a good tool is rarely agent-specific: a portal screen, a nightly reconciliation job, a partner integration and a classification pipeline usually want the same business facts, and none of them speak MCP.

Both answers live in one artifact you author once and register with Gateway as an MCP target — so AgentCore keeps doing the ingress auth, Cedar policy and CloudWatch tracing it does better than anyone.

Projection inherits shape #

We made this argument in general terms last week: a projection that faithfully mirrors an API inherits the API’s size and shape. The document is the right input; the problem is treating it as the output. Gateway’s OpenAPI target is exactly that mechanism, offered as a managed service — which makes it faster, more reliable and better authenticated than the generators we were describing, and does not change what comes out the other end.

What comes out is resources. What an agent needs is jobs.

Anthropic states the target almost as a recipe: “Instead of implementing a list_users, list_events, and create_event tools, consider implementing a schedule_event tool which finds availability and schedules an event.” No OpenAPI document contains schedule_event. It is not an endpoint anyone forgot to tick — it is three endpoints and the decision to fuse them, and that decision lives in your product knowledge, not in the document you are projecting from.

Semantic search solves retrieval, not design #

Gateway has an answer to tool sprawl, and it is a good one: Semantic Tool Selection, which lets agents “search across available tools to find the most appropriate ones for specific contexts, allowing agents to use thousands of tools while minimizing prompt size and reducing latency.” That beats shipping 200 tool definitions every turn, and on a large projected surface you should turn it on.

But note which problem it solves. It reduces how many tool definitions reach the model. It does not reduce how many turns the task takes, it does not change what any tool returns, and it cannot invent a tool that was never in the document.

Take the concrete case. Your agent needs a customer’s plan, their unpaid invoices and their open ticket count before answering a billing question. Projected, that is three tools across two OpenAPI documents. Semantic search will find all three. Then the model still plans the sequence on every run, holds the customer ID across three round trips, joins the results in its own reasoning, and pays tokens for three full response envelopes when it needs five fields.

Retrieval found the right resources. Nobody designed the job. Retrieval does not remove curation, it relocates it — into a probabilistic model, on every turn, which is precisely the step twenty years of API curation used to do once, at design time.

What a designed surface looks like behind Gateway #

Gateway accepts MCP targets — an existing MCP server fronted through the Gateway endpoint — alongside its OpenAPI, Smithy and Lambda targets. That is the seam. Let AgentCore do the inbound auth, Cedar policy, session isolation and CloudWatch tracing. Then give it something on the other side that was designed rather than projected.

An Ikanos capability is that surface as one declarative file. Here is the same billing job as a single tool call:

ikanos: "1.0.0-beta6"

capability:
  consumes:
    - import: crm
      from: ./shared/crm.yml          # written by `ikanos import openapi`
    - import: billing
      from: ./shared/billing.yml      # a different document entirely

  aggregates:
  - display: "Support Desk"
    namespace: support
    flows:
      get-customer-context:
        description: "Everything an agent needs before a billing question"
        semantics:
          safe: true
          idempotent: true
          cacheable: true
        inputParameters:
          customer-id:
            type: string
            required: true
            description: "Customer identifier"
        steps:                          # three upstream calls, one tool call
          get-customer:
            type: call
            call: crm.get-customer
            with:
              id: "{{customer-id}}"
          list-invoices:
            type: call
            call: billing.list-invoices
            with:
              customer: "{{customer-id}}"
          list-tickets:
            type: call
            call: crm.list-open-tickets
            with:
              customer: "{{customer-id}}"
        mappings:                       # five fields, not sixty
        - target: plan
          value: "$.get-customer.subscription.plan_code"
        - target: unpaidInvoices
          value: "$.list-invoices.data[?(@.status=='open')]"
        - target: openTickets
          value: "$.list-tickets.data.length"

  exposes:
  - type: mcp
    port: 3001
    namespace: support-copilot
    description: "Support copilot tools, registered as an AgentCore Gateway MCP target"
    tools:
      get-customer-context:
        description: "Fetch a customer's plan, unpaid invoices and open ticket count"
        hints:
          readOnly: true
        ref: support.get-customer-context

Three endpoints across two documents, one tool, one turn, five fields. Register that MCP endpoint as a Gateway target and AgentCore treats it like any other tool source — Cedar policies still apply, ingress auth still applies, traces still land in CloudWatch.

Note what the file does not contain: any control flow. That is what makes it reviewable. A reader can enumerate every upstream operation the capability can reach before anything runs — which is the conversation you cannot have about a surface that only exists at runtime.

The consumer you did not plan for #

Everything above still assumes an agent is asking. That assumption costs the most, because the logic in get-customer-context — which systems to call, in what order, which five fields matter — is not agent-specific. It is a business decision that an agent happens to be one consumer of.

Ask who else wants it. A portal screen needs the same three facts. So does a nightly reconciliation job, a partner integration behind an API key, a Retool dashboard. None of those speak MCP, and none of them should have to.

In an Ikanos capability, exposes is a list, and each entry is a different door onto the same aggregates block:

  exposes:
  - type: mcp
    port: 3001
    namespace: support-copilot
    description: "Support copilot tools"
    tools:
      get-customer-context:
        description: "Fetch a customer's plan, unpaid invoices and open ticket count"
        hints:
          readOnly: true
        ref: support.get-customer-context

  - type: skill
    port: 3002
    namespace: support-skills
    description: "Support skill groups"
    skills:
      billing-triage:
        description: "Answer billing questions with full customer context"
        tools:
          get-customer-context:
            description: "Fetch a customer's plan, unpaid invoices and open tickets"
            from:
              sourceNamespace: support-copilot
              action: get-customer-context

  - type: rest
    port: 3003
    namespace: support-api
    resources:
      customer-context:
        path: "/customers/{{customer-id}}/context"
        operations:
          get-customer-context:
            method: GET
            inputParameters:
              customer-id:
                in: path
                type: string
                description: "Customer identifier"
            ref: support.get-customer-context

Same ref. Same three upstream calls, same five fields, same auth, same OTel spans, same review. Three consumers, one decision — and when billing adds a field or the CRM changes a path, it is one diff, not three. This is not hypothetical: it is step 10 of the Ikanos tutorial, where one aggregate is referenced by an MCP tool and a REST operation in the same file.

Most enterprise AI spend is still not agentic. Classification, extraction, enrichment, search, summarisation — all of it needs governed access to the same business facts, and none of it needs a tool-calling loop.

Two things that are not feature gaps #

AWS can add response shaping to Gateway. It already does protocol translation, so templating is a small step. Two properties are structural rather than roadmap items:

A capability is a file; a Gateway target is a cloud resource. The same file runs behind AgentCore, behind a Docker Agent toolset, behind n8n or Kestra, and on a laptop over stdio — because exposes picks the transport at startup and nothing above it changes. The multi-cloud posture is not aspirational: Wells Fargo’s public signals name Amazon API Gateway, ECS, Kinesis and S3 alongside Azure Active Directory and Azure Data Factory. Organisations that size rarely run one agent platform.

A capability outlives the protocol it was first exposed over. MCP is two years old and has already had breaking revisions. exposes is a declaration, not an implementation, so a protocol change is an engine upgrade rather than a rewrite — which is how capabilities rode the 2026-07-28 revision with zero edits.

This is what we said about API gateways, one tier up: capabilities sit with your gateway, not in front of it. You do not need a new platform. You need a better artifact to put behind the one you have.

One gap of our own, since we are naming structural ones: Ikanos does not implement AWS SigV4 as an authentication type — the current set is basic, apikey, bearer, digest and oauth2. If a capability needs to call an AWS service that requires a signed request, it goes through the official AWS SigV4 proxy today. That is a roadmap item, not a structural property, and a few of our older posts shipped example YAML implying otherwise — we have corrected them.

The rule #

Reachability is infrastructure. Shape is design. Reuse is architecture. AWS shipped the first one thoroughly, and inside AgentCore you should use it. The other two are decisions someone still has to make, write down, and review.

So the question is not whether AgentCore is good. It is: when the second agent runtime arrives, and when the portal team needs the same three facts over REST, do you have one artifact or four copies?