Conversation memory and clarification flows: AIP-C01 study notes and practice questions
What to know about Conversation memory and clarification flows for the AIP-C01 exam, from the Foundation Model Integration, Data Management, and Compliance domain (31% of the exam guide), then 1 free question to test it. Part of the AIP-C01 study guide.
AIP-C01 asks how to store and trim conversation history, how to keep memory separate per user, and how to ask a clarifying question instead of guessing.
Storing history
A custom application can keep turns in Amazon DynamoDB, keyed by session or user, and set a time to live (TTL) so old conversations expire automatically. Load only the recent turns that fit the prompt. For long sessions, summarize older turns into one short message and keep the recent turns verbatim.
Amazon Bedrock AgentCore Memory handles this for agents without custom storage:
Memory type
Holds
Use it for
Short-term
Events within one session
Remembering what was said earlier in this conversation
Long-term
Facts, summaries and preferences extracted across sessions
Remembering a user’s preferences next week
Long-term memory is organized into namespaces, typically per user or per session, so one user’s memory is never returned to another.
Summarizing to fit the window
Summarization trades detail for space. It works for chat history, but it can drop a specific number, date or code the user later needs. Keep exact values for the current task, and summarize only background turns.
Clarification flows
When intent is unclear, the workflow should ask a question instead of guessing. A common pattern is an AWS Step Functions workflow that classifies intent with a model or Amazon Comprehend, then, if confidence is low, pauses with a task token callback (waitForTaskToken) until the user replies. The task token is sent back when the answer arrives, so the workflow resumes without polling.
How to choose
Scenario wording
Choose
“Keep chat history for 30 days, then delete it automatically”
DynamoDB with TTL
“Agent remembers preferences across sessions”
AgentCore Memory long-term memory
“Chat grows beyond the context limit”
Summarize old turns, keep recent turns
“Ask the user to clarify before acting, without polling”
Step Functions with task token callback
“Users must never see each other’s memory”
Per-user namespaces and access checks
Common traps
Sending the full history every turn, which raises cost and latency and can overflow the window.
Summarizing away exact values the next question depends on.
A shared memory key such as a global session name, which mixes users’ data.
No TTL on stored history, which keeps personal data longer than needed.
Guessing intent on ambiguous requests instead of asking.
Polling a database for the user’s reply when a task token callback is simpler.
A mobile carrier runs a support chatbot on AWS Lambda behind Amazon API Gateway. Each conversation needs the last 20 turns sent to the model, so that follow-up questions make sense.
The bot handles bursts of thousands of chats during outages, and any instance of the Lambda function may serve any customer's next message. Each message must be deleted automatically seven days after it is sent, and the team has no capacity to run scheduled cleanup jobs.
History reads must return in a few milliseconds.
Which design meets these requirements with the LEAST operational overhead?
Choose one answer.
AA. Store each conversation as one Amazon S3 object, rewrite the whole object on every turn, and run a nightly Lambda function that deletes objects whose last-modified date is older than seven days.
BB. Keep the conversation history in a global variable of the Lambda function, so that it persists between invocations in the same execution environment and needs no database.
CC. Store each message as a row in an Aurora PostgreSQL cluster, read the last 20 rows for each request, and schedule a job that deletes rows older than seven days.
DD. Store each message as an Amazon DynamoDB item keyed by conversation ID and turn number, set a Time to Live attribute seven days ahead, and query the latest 20 items.
Show the answer and explanation
Answer: D
A. Wrong: Rewriting the whole object on every turn adds latency as conversations grow, and the nightly deletion job is exactly the cleanup the team cannot run. This misses the latency and operations requirements.
B. Wrong: A global variable lives only in one execution environment, and any environment may serve the customer's next message. Environments are also created and recycled during bursts, so the history would be missing or lost, which fails the reliability requirement.
C. Wrong: Aurora can store this data, but the team would manage the cluster, database connections from thousands of concurrent functions and the scheduled purge job. The team has no capacity for scheduled cleanup, so the approach misses the operations requirement.
D. Right: DynamoDB serves single-digit millisecond reads at any burst size, and the TTL attribute removes old messages with no cleanup job. The table is fully managed, so it meets every requirement with the least operations. Learn more: Using time to live (TTL) in DynamoDB (opens in a new tab)
Explanation
A DynamoDB table keyed by conversation and turn returns recent history in milliseconds, scales through bursts without servers, and deletes expired items with TTL. Object rewrites, per-environment memory and a self-managed database each fail one requirement: latency, reliability or cleanup effort.
Want more on Conversation memory and clarification flows? The 5 full-length practice sets have 6 more Conversation memory and clarification flows questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →