Visual overview
Bedrock supplies model/agent capabilities, API Gateway or a managed agent gateway controls tool exposure, and Lambda executes narrowly scoped application actions.
Technical reference
Agentic systems combine probabilistic decisions with deterministic execution. The exam expects you to know where to enforce protocol, identity, validation, and stopping controls.
Repeat until a terminal condition, step limit, time budget, or error policy ends the run.
Clear schemas improve tool selection and argument generation; validate generated arguments before execution.
A standardized client/server protocol can expose tools, prompts, and resources without binding agent logic to bespoke integrations.
Managed gateway translates and composes tool targets while supporting inbound and outbound authorization patterns.
Make every agent run finite and prevent a failing tool or repeated model plan from consuming unlimited resources.
Place deterministic approval before high-impact execution such as payment, deletion, or privileged change.
Service limits and capabilities can change. Values shown here reflect the current AWS documentation; use the linked official sources below as the source of truth.
An agent is a controlled decision loop
An agentic application repeatedly observes context, asks a model to decide what to do next, invokes an allowed tool when required, incorporates the result, and stops when a completion condition is met. ReAct-style patterns interleave reasoning and action, but production systems must make the loop bounded. Maximum steps, timeouts, tool-specific deadlines, retry policy, token budget, and explicit terminal conditions prevent an ambiguous task or failing tool from creating an unbounded workflow.
The model proposes actions; deterministic code and AWS authorization execute them. A tool schema describes a name, purpose, arguments, and expected result shape so the model can choose and populate the call. The execution layer must still validate arguments, authorize the caller and resource, protect secrets, handle idempotency, and reject unsafe operations. Never treat a tool call emitted by a model as implicitly trusted.
MCP standardizes discovery and invocation of agent resources
Model Context Protocol (MCP) provides a standard interface through which clients can discover and use tools and other server-provided capabilities. Amazon Bedrock AgentCore Gateway can expose APIs, Lambda functions, and other targets through an MCP-compatible gateway, giving agents a single controlled entry point rather than bespoke integration code for every tool. AWS currently documents MCP operations including tool listing/calling and supported prompt/resource operations for AgentCore Gateway.
A protocol does not eliminate security design. Gateway inbound authorization establishes who can reach the gateway; outbound authorization and credential handling determine how a tool is called on the user's or agent's behalf. Tool discovery should reveal only capabilities an identity can legitimately use. When hundreds or thousands of tools exist, semantic tool selection can reduce the number of tool descriptions injected into a prompt, improving both context efficiency and selection quality.
AgentCore supplies production infrastructure; Strands supplies an agent SDK
AWS positions Amazon Bedrock AgentCore as infrastructure for deploying and operating agents and AgentCore Gateway as a managed connectivity layer across tools, agents, and models. Strands Agents is an SDK for implementing model-driven agents and can connect to MCP clients and Bedrock models. Keep the layers distinct: an SDK expresses the agent loop and tool use; a gateway standardizes secured connectivity; runtime, identity, memory, observability, and policy services supply production controls around it.
This distinction matters when choosing between a lightweight Lambda-hosted MCP server, a longer-lived ECS service, and a managed AgentCore path. Short stateless tool handlers can fit Lambda; servers with long-lived connections, custom dependencies, or continuous processes may fit containers. The exam tests the requirement-to-service mapping rather than a rule that every agent must use one framework.
Multi-agent systems add coordination failure modes
A multi-agent architecture usually assigns a supervisor or router to specialist agents. It can improve modularity when domains and tool sets are genuinely distinct, but it also adds model calls, latency, state transfer, routing errors, and harder debugging. Define non-overlapping roles, a task contract between agents, ownership of shared state, and what happens when a collaborator fails. Parallelize only independent work; serial dependencies must preserve ordering and state.
Tracing is essential because the final answer may hide the path that produced it. Record agent/session IDs, selected model, tool name and arguments after redaction, timing, result status, handoffs, retrieval calls, and stop reason. Human augmentation belongs at high-impact or ambiguous transitions: an approval step should gate the irreversible action itself, not merely ask a model whether approval seems necessary.
Key takeaways
- 01
Agent loops need explicit step, time, token, retry, and stop boundaries.
- 02
Tool schemas help models choose actions; deterministic authorization and validation still control execution.
- 03
MCP standardizes agent-to-tool/resource interactions, while AgentCore Gateway adds managed connectivity and security controls around those interactions.
- 04
Strands Agents is an agent SDK; AgentCore is production infrastructure. They solve different layers and can be used together.
- 05
Multi-agent designs are justified by real specialization and parallelism, not by agent count; they require deeper tracing and failure handling.
Official AWS sources
Use these primary AWS resources for the source material behind this article and for deeper reference.