Exam-style
A customer assistant built as an agent on Bedrock AgentCore answers questions today. It now has to reschedule a delivery by calling an internal REST API, then report back to the customer. What wires that up?
Reveal the answer
E. Add the API as a gateway target so it is published to the agent as a tool, and the result feeds back into the conversation
A gateway is the supported wiring for side effects: attach the REST API as an OpenAPI target, or the Lambda behind it as a Lambda target, and the gateway publishes it to the agent as an MCP tool. The model emits a tool call, the gateway invokes the target, and the result comes back into the conversation for the next turn. Prompting the model with an API spec and parsing its reply rebuilds that orchestration by hand, without the schema validation or the return path. Retrieving the API documentation puts the spec in the model’s context; it does not give the application a way to call the API. A guardrail filters prompts and responses, so it cannot reschedule anything.
Q. Answering questions is one thing; calling an internal API is another. What wires an agent for real actions on Bedrock?
A. A gateway target on Bedrock AgentCore: attach the API or its Lambda to the gateway, which publishes it to the agent as an MCP tool. The model emits a tool call, the gateway invokes the target, and the result comes back into the conversation. Gateway outbound authorization covers the credentials. An authorization-code (three-legged) OAuth grant lets an OpenAPI target be called on the end user’s behalf. Where the code has to run in your own application, a harness inline function tool returns the call to you and waits for a result.
Why? Side-effecting actions belong behind a declared tool with a typed schema, not written into the prompt. Amazon Bedrock Agents is now Bedrock Agents Classic. It is closed to new customers, so an action group is not the route on a new build.