Bedrock AgentCore Gateway Server-Side Tools (2026): Skip the Client Orchestration Loop

On February 2026, Amazon Bedrock added server-side tool execution with AgentCore Gateway: pass a Gateway ARN as a tool connector on the Responses API, and Bedrock discovers tools, selects them during inference, and executes calls server-side — no customer-maintained client orchestration loop (What’s New, server-side tool use). January 2026 also introduced server-side custom Lambda tools on Responses for a smaller set of models (custom tools What’s New).

This post is the architecture + ops decision for Gateway server-side tools. It is not a remake of AgentCore production or the AgentCore vs Amazon Q buyer guide.

Artifacts: decision matrix, Responses Gateway sketch, architecture diagram (draw.io).

First-party benchmark silhouette — B2B CRM assistant, 12 Gateway tools (OpenAPI + 2 Lambdas), ~8k chat turns/day. Client-loop design had median tool round-trip ~180 ms (app ↔ Bedrock ↔ tool ↔ Bedrock). After Gateway server-side: median ~95 ms on the same tools (CloudWatch custom metric around tool complete events over 5 weekdays). Absolute times depend on target latency; the win was removing one WAN hop.

Server-side vs client-side — one diagram

Client-side:  App ⇄ Bedrock ⇄ App ⇄ Tool ⇄ App ⇄ Bedrock
Server-side:  App ⇄ Bedrock ⇄ AgentCore Gateway ⇄ Lambda / OpenAPI / Smithy

Bedrock presents tools to the model, executes selected calls through Gateway, and streams results back. Multiple tool calls in one conversation turn are supported.

Figure: application calls Responses API; Bedrock invokes AgentCore Gateway; Gateway translates to Lambda / OpenAPI targets under OAuth/IAM. Open draw.io

Why Gateway — beyond “fewer lines of code”

From AgentCore Gateway capabilities:

• Translation — MCP ↔ REST / Lambda without owning protocol versions
• Composition — many targets behind one MCP endpoint
• Security Guard — OAuth so only valid users/agents reach tools
• Semantic Tool Selection — x_amz_bedrock_agentcore_search for natural-language tool discovery when catalogs get large

Opinionated take: prefer Gateway server-side once you cross ~10 tools or need shared OAuth SaaS integrations. Prefer client-side or a single Lambda tool when the tool surface is small and product wants an explicit human confirmation step between model intent and execution.

IAM and permissions

Server-side execution runs in a trusted backend path. Align IAM so the caller identity Bedrock uses can invoke Gateway / targets — do not bounce long-lived SaaS tokens through the browser just to “keep control.” Gateway still centralizes authorization; your app still owns conversation UX.

Failure modes

What broke — Pilot week. Catalog of 87 tools registered on one Gateway with semantic search off. Model selected near-duplicate CRM update tools and wrote duplicate notes on 3% of tested turns. Fix: enable semantic search, tag tools by domain, shrink default tool list, add idempotency keys on write tools. Lesson: Gateway removes the loop; it does not remove catalog hygiene.

Cutover checklist

1. Inventory tools — Lambda ARNs, OpenAPI specs, Smithy models.
2. Create Gateway targets; enable OAuth scopes matching least privilege.
3. Confirm Responses-compatible models in your region via Models API.
4. Feature-flag: 10% of traffic on server-side Gateway; compare error rate and p50/p95 tool latency.
5. Retire client loop code paths once idempotent writes are verified.

Reproduce this — Use responses-gateway-snippet.py as a dry-run shape, then wire the request to the current Responses / bedrock-mantle SDK fields for your SDK version. Score fit with server-side-vs-client-side-matrix.md.

What to Do This Week

1. Count production tools and whether OAuth or API keys live in the app today.
2. If count ≥10 or ≥2 teams contribute tools, draft a Gateway target map.
3. Measure client-loop tool RTT (start → result) for one week as a baseline.
4. Run a 10% server-side canary; keep classic Agents Classic traffic separate if still present.
5. Review AgentCore pricing components so Gateway line items are expected, not surprises.

What This Post Doesn’t Cover

• AgentCore Runtime / Memory / Harness product selection — see production and Q2 roundup posts
• Knowledge Bases / RAG chunking — separate retrieval path
• Full MCP client sample with streaming elicitation — Gateway feature table only
• EU AI Act classification for autonomous tool writes — compliance follow-up

We have not validated every mantle model × region for Gateway connectors on the same day — always confirm with the Models API before a hard cutover.

Related: Bedrock services · Generative AI on AWS · Architecture review