Task 2.1: Implement agentic AI solutions and tool integrations.

• ACreate an Amazon EKS namespace for each customer and schedule the agent pods with network policies between namespaces

  Incorrect

  Namespaces with network policies can separate tenants, but the team would operate the cluster, and isolation is per customer rather than per conversation.

• BHost the agent on Amazon Bedrock AgentCore Runtime and give each customer conversation its own runtimeSessionId

  Correct

  Each AgentCore Runtime session runs in a dedicated microVM with isolated CPU, memory and filesystem, keeps context across invocations for up to 8 hours, and is sanitized when it ends. It is serverless.

• CRun the agent as an Amazon ECS service on AWS Fargate and keep each conversation's state in the memory of the running tasks

  Incorrect

  Tasks in one service serve many customers at once, so in-memory state and files from different conversations share the same task, which breaks the isolation requirement.

• DRun the agent as one AWS Lambda function and keep each conversation's files in the shared /tmp directory between invocations

  Incorrect

  Lambda is serverless, but an execution environment can be reused by different callers, so shared /tmp storage gives no per-customer isolation, and an invocation is limited to 15 minutes.

Agents differ from stateless functions: they keep state for a long time and perform privileged actions with user credentials. AgentCore Runtime gives every session its own microVM and terminates and sanitizes it at the end, which is the isolation boundary this scenario needs. The application must still map users to session IDs, because AgentCore does not enforce that mapping.

• ARecord turns as AgentCore Memory events and add a user preference strategy whose namespace includes the actor ID

  Correct

  Short-term memory stores raw events for a session, and a long-term strategy extracts preferences asynchronously into memory records under a namespace that includes the actor ID, so the agent retrieves only what is relevant for that shopper.

• BIngest the chat transcripts into an Amazon Bedrock knowledge base and retrieve the most similar transcripts for each new message

  Incorrect

  A knowledge base answers what authoritative sources say. Without per-shopper scoping, similar transcripts from other shoppers could be retrieved, and preferences are not extracted.

• CKeep the conversation and the preferences in the AgentCore Runtime session so that the microVM holds them between visits

  Incorrect

  Runtime session state is ephemeral and lasts only as long as the session's microVM, so preferences would be lost between visits.

• DStore the full message history of every shopper in an Amazon DynamoDB table and send the complete history with each request

  Incorrect

  DynamoDB is a good store for conversation history, but sending the complete history every time makes token cost grow with each shopper's past, which the requirements forbid.

Agent memory has two layers. Short-term memory replays the current conversation; long-term memory strategies extract durable facts, such as user preferences, and namespaces scoped by actor keep each user's records separate. Retrieving only relevant records keeps prompts small.

• AAttach a policy engine to the gateway with a Cedar policy that forbids the refund tool when context.input.amount exceeds 500

  Correct

  Policy in AgentCore evaluates every tool call at the gateway, outside the agent's code, and Cedar conditions can test tool arguments such as the refund amount, so no prompt can bypass it.

• BSet maxIterations to 20 and timeoutSeconds to 600 in the harness configuration

  Correct

  The harness limits cap reasoning and action cycles per invocation and the wall-clock time of a single invocation, which stops runaway loops.

• CAdd a denied topic called refunds to an Amazon Bedrock guardrail that is applied to the agent's model

  Incorrect

  A denied topic would block conversations about refunds altogether, and it evaluates text, not the arguments of a tool call.

• DAdd a sentence to the system prompt that forbids refunds above 500 USD under any circumstances

  Incorrect

  Prompt instructions are part of what the attacker manipulated. They are not deterministic enforcement.

• ESet reserved concurrency on the Lambda function behind the refund tool to limit how many refunds can run

  Incorrect

  Reserved concurrency limits parallel executions, not the amount of a refund or the length of an agent loop.

Controlled autonomy needs boundaries that the model cannot talk its way around. Business limits on tool arguments belong in a policy evaluated at the gateway (default deny, forbid wins), and runaway behavior is stopped by hard limits on iterations, time and tokens.

• ARun all thirteen tools in one container on a single Amazon EC2 instance and connect the agents to it directly

  Incorrect

  A single instance is a single point of failure that the team must patch and scale, and bypassing the gateway loses its central authorization and tool catalog.

• BImplement all thirteen tools as Lambda functions and add each one to the gateway as a Lambda target

  Incorrect

  A new Lambda execution environment would reload the 2 GB index, which takes minutes, and database connections would be opened and closed repeatedly.

• CDeploy each of the thirteen tools as its own AgentCore Runtime agent and route agents to them through HTTP targets on the gateway

  Incorrect

  HTTP targets are proxied without aggregation, so the tools would not appear in one MCP tool list, and running simple lookups as separate agents adds needless overhead.

• DAdd the simple tools as Lambda targets, and run the index tool as an MCP server on Amazon ECS added as an MCP target

  Correct

  Stateless, short tools fit Lambda targets that the gateway turns into MCP tools. A long-running container keeps the large index loaded and its connections open, and the gateway can aggregate it as an MCP server target.

Match the tool's runtime profile to its host: lightweight stateless tools on Lambda behind the gateway, heavyweight stateful tools in long-running containers exposed as MCP servers. The gateway aggregates MCP targets into one virtual MCP server so agents see a single catalog.

• AFine-tune the best-performing model on past labeled claims and use its label alone

  Incorrect

  Fine-tuning on labeled examples suits teaching one model a specific task. The single model's remaining blind spots would still decide every claim.

• BHave one model label each claim and send only the claims it labels high to an investigator

  Incorrect

  Reviewing only high labels fits when false alarms are the main concern. A wrong "low" label, the costly error here, would never be reviewed.

• CAsk three models from different providers and send any disagreement to an investigator

  Correct

  Running independent model calls in parallel and aggregating the outputs programmatically is a documented way to add robustness, and a disagreement between models with different blind spots marks an uncertain case for the human.

• DCall one model three times at a high temperature and take the majority label

  Incorrect

  Repeated sampling smooths out random variation in one model's answers. All three samples share that model's systematic blind spots.

A model ensemble is worth its cost when single-model errors are expensive and uncorrelated across models. Use agreement as the gate and route disagreement to a person.

• AAdd the functions as Lambda targets of an AgentCore gateway

  Correct

  Gateway turns Lambda targets into tools that agents reach through one MCP endpoint.

• BPaste each function's code into the agent's system prompt

  Incorrect

  The model cannot execute code from a prompt, and secrets could leak.

• CRewrite each function as an MCP server on Amazon ECS

  Incorrect

  This is the rewrite the team wants to avoid.

• DCall the functions from the client and send their results as user messages

  Incorrect

  This bypasses the agent's tool choice and needs custom code for every function.

Gateway targets wrap existing services as tools. Lambda targets are the fastest path for functions you already run.

• ACreate a custom AgentCore Browser with session recording to the company's S3 bucket

  Correct

  AgentCore Browser runs isolated browser sessions in a managed environment. Session recording, available for custom browsers, captures user actions, DOM changes and network events, stores them in your S3 bucket and supports replay.

• BGive the agent AgentCore Code Interpreter to send HTTP requests to the carrier sites

  Incorrect

  Code Interpreter runs code in a sandbox, which suits calculations and data analysis. It does not drive web pages the way a browser does.

• CUse the AWS managed browser and rely on AWS CloudTrail for the audit trail

  Incorrect

  The managed browser gives the quickest setup, but session recording is available for custom browsers, and CloudTrail records API calls rather than the actions inside a web page.

• DDrive the sessions through the Automation endpoint with a library such as Playwright

  Correct

  The Automation endpoint lets the agent navigate, click and fill in forms in the session, and libraries such as Playwright simplify these actions.

• ERun headless Chromium in a Lambda function attached to the company's VPC

  Incorrect

  A self-built headless browser suits simple scraping. The company would run it itself, it has no built-in replay, and it would put web activity inside the company network.

Agents that must use websites without APIs need a managed, isolated browser. Pick the custom browser when the audit needs recordings in your own bucket.

• ASet toolChoice to any on the first call of each conversation

  Incorrect

  With any, the model must request at least one tool and generates no text, but it may still pick get_balance or another tool first.

• BName verify_customer in toolChoice on the first call of each conversation

  Correct

  A specific tool in toolChoice makes the model request that tool, and Amazon Nova models support it. Later calls keep the default auto, so the model chooses freely once the customer is verified.

• CRestate the verification rule in the system prompt and set temperature to 0

  Incorrect

  Firmer wording and a low temperature make responses more consistent, but under the default auto the model still decides whether and which tool to call, so the rule is not guaranteed.

• DName verify_customer in toolChoice on every call of the conversation

  Incorrect

  Forcing the tool on every call makes each response request verify_customer again, so the model could never move on to the other tools after verification.

Use toolChoice per call: force a specific tool only where a step is mandatory, and let the model choose everywhere else.

• AA Lambda target whose function calls the service with the AWS SDK

  Incorrect

  Lambda targets run custom code that implements each tool, described by a tool schema. The team would have to write and maintain that function.

• BAn OpenAPI target described for the API, signed with SigV4 by the role

  Incorrect

  OpenAPI targets turn MCP calls into HTTP requests defined by an OpenAPI specification of the API. Writing or converting that description is the work the team has ruled out.

• CAn MCP server target for a server on AgentCore Runtime that wraps the API

  Incorrect

  MCP server targets connect the gateway to an existing MCP server. The team would have to write that server and deploy it.

• DA Smithy model target built from the service's model, using the role

  Correct

  Smithy model targets suit AWS services: the gateway turns MCP requests into calls to the API that the model defines, and built-in models exist for common AWS services. REST-JSON is the supported protocol, and the gateway service role is a supported outbound authorization.

Match the gateway target to what already exists: AWS service APIs come with Smithy models, so a Smithy target needs no code and no hand-written API description.