Implementation and Integration practice questions

AgentCore Memory has short-term memory (raw events per session) and long-term memory (records extracted by strategies across sessions).

Short-term memory keeps the turn-by-turn events of a session, which is why the agent follows each trip well. Long-term memory needs at least one strategy on the memory resource; without one, no long-term records are extracted. A user preference strategy extracts preferences from the events, and the agent retrieves them for the actor at the start of a new session. Longer event expiry, a reused session ID or pasting old events into the prompt all rely on replaying transcripts instead of extracting the fact.

1. Separate within-session context (working) from cross-session recall (failing).
2. Recall that long-term records come only from configured memory strategies.
3. Choose the built-in strategy that targets preferences.
4. Reject options that replay raw transcripts, which the requirement forbids.

Exam tip: No memory strategy means no long-term memory: events alone only give an agent short-term context.

Long-running agents need two controls: how history is condensed (conversation manager) and how much each tool result adds (tool design).

The default sliding window manager evicts the oldest messages, which is exactly where the agreements live. A summarizing conversation manager keeps their content in a summary while preserving recent messages. The second cause is the size of each observation, which is best bounded in the tool itself by returning an excerpt and a pointer to the full output. A null manager makes overflow worse, a smaller window evicts sooner, and output tokens do not enlarge the input context.

1. Identify the two causes: oldest-first eviction and oversized tool results.
2. Keep early facts by summarising instead of discarding history.
3. Shrink observations at the source by returning excerpts and a pointer.
4. Reject settings that remove history faster or affect only output length.

Exam tip: Summarise history you must keep, and keep tool results small; a sliding window forgets the beginning first.

Strands multi-agent patterns differ in who decides the execution path: the developer (workflow, graph) or the agents (swarm, agents as tools).

The requirements describe a fixed, repeatable pipeline with a parallel stage and dependency-scoped inputs. That is the Strands workflow pattern: a fixed task graph with no cycles, deterministic execution, parallel independent tasks, and each task receiving a summary of its dependencies' results. A swarm and agents-as-tools let models choose the path, and a graph is aimed at conditional routing that this process does not need.

1. List the requirements: fixed order, parallel checks, dependency-scoped inputs.
2. Ask who decides the path in each pattern.
3. Pick the pattern where the developer fixes an acyclic task graph.
4. Reject patterns where model choices shape the sequence.

Exam tip: Fixed, repeatable pipeline: workflow. Conditional routing: graph. Emergent collaboration: swarm. Simple delegation: agents as tools.

AWS Agent Squad is an open-source framework that classifies each user message and routes it to the most suitable registered agent.

The company wants routing over existing heterogeneous assistants with minimal effort. Agent Squad provides pre-built agent types for Bedrock, Lex and Lambda, and its classifier uses each agent's description plus the conversation history to choose the agent for every turn. Rebuilding as a swarm is heavy, keyword routing is brittle custom code, and Bedrock prompt routing chooses models, not agents.

1. Note that the assistants already exist on three different technologies.
2. Look for a framework that routes between agents, not models.
3. Match it to Agent Squad's classifier and built-in agent types.
4. Reject rebuilds and custom keyword logic as higher effort.

Exam tip: Agent Squad routes each turn to the best-fit agent; intelligent prompt routing picks between models.

Strands Swarm stops runaway collaboration with handoff and iteration limits, timeouts and repetitive-handoff (ping-pong) detection.

The problem is a cycle between two agents, not the length of a chain or the time one agent takes. Swarm's repetitive handoff detection looks at a window of recent handoffs and stops the run when they involve fewer unique agents than the configured minimum, which is exactly the ping-pong case. A lower handoff cap or execution timeout also cuts the legitimate long chains, and a node timeout measures each agent's own duration.

1. Characterise the failure: a back-and-forth between two agents.
2. Note the constraint: chains of six or seven different agents must still complete.
3. Choose the control that measures agent diversity in recent handoffs.
4. Reject blunt caps and timeouts that also hit legitimate runs.

Exam tip: To stop agent ping-pong without capping long chains, detect repeated handoffs among too few unique agents.

In a ReAct loop the model alternates reasoning with actions; with Converse the action request is signalled by stopReason tool_use.

Converse returns stopReason tool_use with toolUse blocks when the model wants a tool. The workflow runs that tool, appends the assistant message and a user message containing a toolResult with the same toolUseId, and calls the model again. When the stop reason is anything else (normally end_turn), the model has answered and the loop ends. Retry is for failures, end_turn is the finish signal, and running every tool ignores the model's request.

1. Recall how Converse signals a tool request: stopReason tool_use with toolUse blocks.
2. Route on that value with a Choice state.
3. Return the observation as a toolResult tied to the toolUseId.
4. End the loop on any other stop reason.

Exam tip: ReAct with Converse: loop while stopReason is tool_use, returning each observation as a toolResult.