Exams / AIP-C01 / Study guide / Building agents (Strands Agents, AgentCore Runtime, multi-agent patterns)
Building agents (Strands Agents, AgentCore Runtime, multi-agent patterns): AIP-C01 study notes and practice questions
What to know about Building agents (Strands Agents, AgentCore Runtime, multi-agent patterns) for the AIP-C01 exam, from the Implementation and Integration domain (26% of the exam guide), then 2 free questions to test it. Part of the AIP-C01 study guide.
AIP-C01 asks how to build and host a new agent, which framework or service fits the team, and how agents should share work. For any new build, choose Amazon Bedrock AgentCore. Amazon Bedrock Agents Classic has been closed to new customers since July 30, 2026, so it is never the right answer for a new agent.
Frameworks and AgentCore Runtime
Strands Agents is the AWS open-source SDK for writing an agent in code. You give it a model, a system prompt and tools, and it runs the reasoning loop. Other frameworks, such as LangGraph and CrewAI, also run on AgentCore. The framework is your choice. Runtime is the hosting layer.
AgentCore Runtime is serverless hosting for the agent. Each session runs in its own isolated microVM, so one user’s session cannot read another session’s working state. Sessions can run up to 8 hours. Runtime supports the MCP and A2A protocols, so the same agent can use tools or be called by other agents.
Multi-agent patterns
Supervisor and workers: one supervisor agent reads the request, delegates subtasks to specialist worker agents (for example billing, search or policy lookup), and combines their answers. Each worker gets a narrow tool set, which keeps prompts short and permissions small.
Agent-to-agent (A2A): when different teams own different agents, each team hosts its agent on Runtime and exposes it over A2A. Teams call each other’s agents without sharing code or internal tools.
Keep the two ideas apart. A2A connects agents to each other. MCP connects an agent to tools.
Managed harness or code-defined agent
AgentCore offers a managed harness for config-based agents. You describe the model, tools and instructions, and AWS runs the loop. Choose it for a standard agent that needs little custom logic. Write the agent in code, with Strands or another framework, when you need custom control flow, special state handling or unusual tool logic.
How to choose
Scenario wording
Choose
“New agent, managed runtime, any framework”
AgentCore Runtime with Strands Agents
“Each user’s session must be isolated”
AgentCore Runtime (one microVM per session)
“Specialist agents coordinated by one agent”
Supervisor and worker pattern
“Another team’s agent must be called”
A2A protocol between agents on Runtime
“Standard agent, minimal code”
AgentCore managed harness
“Custom control logic or special state”
Code-defined agent with Strands
“Remember user preferences across sessions”
AgentCore Memory
Common traps
Bedrock Agents Classic for a new build. It is closed to new customers, so choose AgentCore.
One large agent with dozens of tools. Splitting by specialty keeps tool choice accurate and permissions narrow.
Reusing one session for many users, which breaks isolation. Give each user conversation its own session.
Using A2A for tool calls. Tools come through MCP servers or AgentCore Gateway.
Building your own session isolation when Runtime already provides a microVM per session.
A tax preparation software company has built a conversational agent with the open-source Strands Agents SDK. The agent calls a model on Amazon Bedrock and three internal tools, and each user session can hold personal tax documents.
The company wants to move the agent off a shared container and into a managed runtime. Each user session must run in its own isolated environment, so that one customer's files and in-memory state can never be read by another session. Sessions can last several hours, and the team does not want to manage clusters or patch hosts.
Which deployment meets these requirements with the LEAST operational overhead?
Choose one answer.
AA. Rewrite the agent as an AWS Lambda function behind Amazon API Gateway, and store each user's session state under a separate prefix in a DynamoDB table.
BB. Deploy the agent on an Amazon EKS cluster with one namespace for each customer and network policies that block traffic between namespaces.
CC. Run the agent on an Amazon EC2 Auto Scaling group that starts one instance per active user session, with a user data script that installs the agent.
DD. Deploy the Strands agent to Amazon Bedrock AgentCore Runtime, which runs each user session in its own isolated microVM and needs no clusters or hosts.
Show the answer and explanation
Answer: D
A. Wrong: Lambda handles short requests well, but its 15-minute limit makes multi-hour sessions awkward. Isolation then depends on application code that filters keys, not on a per-session boundary the platform enforces.
B. Wrong: Namespaces separate resources logically, but pods from different customers still share nodes and a kernel. The platform team would also run cluster upgrades, node patching and scaling, which the company wants to avoid.
C. Wrong: A dedicated instance per session gives strong isolation, but instances take minutes to start and cost money while idle. The team would still manage AMIs, patching and scaling policies for the fleet.
D. Right: AgentCore Runtime is a serverless host for agents built with frameworks such as Strands Agents, so the team manages no clusters or hosts. It meets the session isolation rule by design, which removes the need for custom isolation code. Learn more: Overview of Amazon Bedrock AgentCore (opens in a new tab)
Explanation
AgentCore Runtime hosts agents built with any framework, including Strands Agents, and gives each session its own isolated microVM with no infrastructure for the team to run. Lambda, EKS namespaces and per-session EC2 instances each leave either a weaker isolation boundary or more infrastructure to operate.
A travel company's booking assistant helps customers plan trips that can span several weeks. Within one conversation, the assistant tracks the current trip's flights, hotels and dates. Customers also return days later and expect the assistant to remember durable preferences, such as seat type and dietary needs.
The company's requirements are three. Trip details must persist for the length of each conversation, preferences must be remembered for each customer across conversations, and no customer's preferences may ever appear in another customer's session. The team wants to write as little custom storage code as possible.
Which approach meets these requirements with the LEAST custom code?
Choose one answer.
AA. Use Amazon Bedrock AgentCore Memory, with short-term memory for each session's trip events and a long-term preference strategy in a per-customer namespace.
BB. Send the full chat transcript with every model call and trim the oldest messages once the transcript passes 4,000 words, so the model always sees recent context.
CC. Save each customer's preferences in one shared Amazon DynamoDB table keyed by trip ID, and scan the table at the start of each session to find matching records.
DD. Keep each customer's preferences in the memory of the Lambda function that handles the session, so that the function reads them on every turn without a database.
Show the answer and explanation
Answer: A
A. Right: Short-term memory holds the events of each session, and a long-term strategy stores preferences that persist across sessions. Namespaces per customer keep one customer's preferences out of another customer's sessions. Learn more: Amazon Bedrock AgentCore Memory (opens in a new tab)
B. Wrong: Trimming removes old messages, so preferences stated weeks earlier disappear. Transcripts also do not carry over to new conversations, which misses the cross-session requirement.
C. Wrong: Keying by trip rather than customer means preferences do not follow the customer to a new trip. Scanning a shared table also risks returning another customer's records, which breaks the isolation rule.
D. Wrong: Lambda memory is discarded when the execution environment is recycled, so preferences disappear unpredictably. Environments are also shared across requests, so the isolation rule is not guaranteed.
Explanation
AgentCore Memory separates short-term session events from long-term memory strategies, so trip details last for the conversation and preferences last across conversations. Namespaces per customer keep the preferences isolated, and the team writes little storage code. Transcripts, trip-keyed tables and in-process memory each fail one of the three requirements.
Want more on Building agents (Strands Agents, AgentCore Runtime, multi-agent patterns)? The 5 full-length practice sets have 6 more Building agents (Strands Agents, AgentCore Runtime, multi-agent patterns) questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Building agents (Strands Agents, AgentCore Runtime, multi-agent patterns)