Part 24: Build 5a — AWS: tools via AgentCore Gateway and Lambda

Part 24 · One Agent, Five Platforms

The last build. MuleSoft, Boomi, SAP and Azure have all hosted the nine tools. Now it's AWS's turn, with its own pieces: AgentCore Gateway in front, and Lambda and APIs behind it.

Like the other builds, this is documentation-only. Everything below comes from the Amazon Bedrock AgentCore and AWS Step Functions documentation as I read it on 12 November 2026, linked in the text. This part covers only the tools. The runtime, identity, memory, the approval and AWS's scores come in Part 25.

The pieces

The AgentCore overview lists a dozen components. Four matter for the build:

• Runtime: a serverless runtime for agents and tools. The page says it supports MCP and A2A.
• Gateway: "a secure way to convert your APIs, Lambda functions, and existing services" into MCP tools.
• Identity: the agent identity and credential service from Part 23.
• Policy: deterministic rules on what agents can do with tools.

Memory, Observability and Evaluations are covered in Part 25.

One gateway, one MCP server

This is the main difference from Azure. In Part 21, the agent saw three MCP servers behind API Management. On AWS, the Gateway core concepts page says a gateway with MCP targets acts as one virtual MCP server: clients get "one consolidated tools/list response" across all targets.

MCP targets can be Lambda functions, API Gateway REST APIs, OpenAPI specifications, Smithy models, existing MCP servers and built-in connectors. The gateway can also proxy HTTP targets, such as other agents over A2A, and route model traffic. That's Part 25's territory.

Inbound, a gateway needs an authorizer: a JWT from your identity provider, IAM (SigV4), or none for testing. Outbound, Lambda and Smithy targets use the gateway's service role. OpenAPI and MCP server targets use a credential provider from AgentCore Identity: an API key, OAuth or SigV4.

Mapping the nine tools

From the contract in Part 7, split the same way as on Azure: APIs, rules and workflows.

• OpenAPI target (five tools): get_invoice, get_purchase_order, get_goods_receipt, get_supplier_history and post_invoice_adjustment. These are the process APIs from Part 3, with the Part 19 checks behind the posting.
• Lambda target (four tools): check_duplicate_invoice and run_three_way_match are rules in code. request_approval and notify_supplier are small Lambda functions that hand off to a workflow and to email.

Why a Lambda for request_approval, not Step Functions directly? The Step Functions callback pattern is built for waiting on "a human approval": a task pauses until someone calls SendTaskSuccess or SendTaskFailure with its token, for up to the one-year execution limit. But that's far longer than any tool call should wait. So request_approval starts the workflow and returns at once, and the approval comes back as an approval_id, as in Part 6. The workflow itself is Part 25.

Schemas

Both target types are strict, which suits the Part 7 contract:

• OpenAPI targets need OpenAPI 3.0 or 3.1, and an operationId for every operation, which becomes the tool name. The OpenAPI target page lists oneOf, anyOf and allOf as unsupported, along with spec-level security schemes. That matches the advice from Azure in Part 21: keep schemas flat.
• Lambda targets take a tool schema with a name, a description and an inputSchema whose top level must be an object, with an optional outputSchema. The Lambda target page shows the required list, so required fields stay required.

One naming detail matters more than it looks. The tool naming page says tools appear as ${target_name}___${tool_name}, with three underscores. So get_invoice reaches the agent as something like invoice-api___get_invoice. That affects:

• the allow-lists from Part 9, which name tools;
• the expected tool calls in the golden set from Part 10;
• every Lambda function, which receives the prefixed name and has to strip it.

Choose short, stable target names, and don't rename them casually.

Errors

The same open question as on every other platform. The Lambda target page says the function "must return a valid JSON response" and suggests error handling "to provide meaningful error messages to the client". Neither the Lambda nor the OpenAPI target page says how a failure becomes an MCP result, or whether isError is set.

So, as before, the Part 8 errors such as GR_MISSING and APPROVAL_MISSING come from the process layer as structured results, whichever target type runs the tool.

IAM and Policy

IAM. The gateway permissions page gives the gateway service role lambda:InvokeFunction on named function ARNs, not all functions. Its trust policy should be limited to your account and gateway with aws:SourceAccount and aws:SourceArn. The page says you can leave those conditions out at first, but add them once the gateway exists.

Policy. This is the piece I'd watch most. Policy in AgentCore "intercepts all agent traffic" through a gateway and checks each tool call against rules written in Cedar, or described in plain English and turned into Cedar. AWS announced it as generally available in March 2026.

For the invoice agent, that means rules such as "this agent may only call post_invoice_adjustment below a set amount" can be enforced at the gateway, outside the agent's code. It doesn't replace the approval_id check in the process API. It adds a second, deterministic gate in front of it.

What this sets up for Part 25

AWS's tool story is the most consolidated so far: one gateway, one MCP server, strict schemas, and a policy engine at the same point. The trade-offs are the tool name prefix, which leaks into allow-lists and tests, and unconfirmed error handling.

Part 25 runs the agent in AgentCore Runtime, adds identity and memory, puts the approval in Step Functions, and gives AWS its provisional scores.

AgentCore or your own runtime?

---

This series describes a reference build on a fictional company. This part is based only on AWS documentation as of 12 November 2026; no hands-on build has been run yet. Views are my own. Check current docs before you build.